macOS Entitlements audio-input vs. microphone

com.apple.security.device.microphone is a sandbox entitlement. If you want to use the microphone in a sandboxed app, you will need to enable it,

com.apple.security.device.audio-input is a hardened runtime entitlement. If you want to use the microphone in an app built with the hardened runtime, you will need to enable it.

If your app is both sandboxed and hardened, you will want to enable both.

Sandboxing and hardening provide overlapping protections in this case.

In a sandboxed app, if you don't have the com.apple.security.device.microphone entitlement, your app will not be able to access the microphone.

In a hardened app, if you don't have the com.apple.security.device.audio-input entitlement, your app will not be able to access the microphone or any audio input using Core Audio,

This provides a good explanation of the relationship between sandboxing and hardening.

We can see in Xcode 10 that the Resource Access section of the Hardened Runtime shows a great deal of overlap with the App Sandbox, while the Runtime Exceptions section has functionality unique to the hardened runtime. What's the reason for the overlap? The sandbox was designed mainly for the App Store, while the hardened runtime was designed mainly for Developer ID. I've just explained in detail how the two technologies can apply to the same app and don't depend on the distribution method, but in the near future the majority of apps will probably use at most one of the two: sandboxing for Mac App Store apps and hardening for notarized Developer ID apps. This is why duplicate entitlements exist.

Recommended topics

Hot tags