I’ve explained this point many times on the forums, so I figured I’d write it up properly once and for all.
If you have questions or comments, start a new thread in Privacy & Security > General and add the App Sandbox tag. That way I’ll be sure to see it.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
The Case for Sandboxing a Directly Distributed App
Many folks consider the App Sandbox to be a binary choice:
-
“My app ships in the Mac App Store, so I must sandbox it.”
-
“I directly distribute my app, so I’ll ignore the App Sandbox.”
However, those are not your only options. In many cases it makes sense to sandbox a directly distributed app. Sandboxing your app has at least three benefits:
-
It enables app container protection. See Trusted Execution Resources for a link to more info on that.
-
If your app includes any app extensions, it simplifies your development experience because your app and its extensions run in a similar environment.
-
It improves your app’s security (although the actual benefits vary based on the specifics of your app).
Sandboxing some apps can be tricky because of the additional security limits applied by the sandbox. However, in a directly distributed app you have access to two techniques that are not available to Mac App Store apps:
-
Temporary exception entitlements
-
Non-sandboxed XPC services
Temporary exception entitlements
Use temporary exception entitlements to selectively disable specific sandbox security limits.
Imagine, for example, that you’re creating a simple document-based app that’s generally compatible with the sandbox. However, that app needs to send an Apple event to Music to create a playlist. That Apple event is blocked by the sandbox. You don’t need to disable the entire App Sandbox just to get around this security limit. Instead, use the com.apple.security.temporary-exception.apple-events entitlement to open a small hole in the sandbox.
There are temporary exception entitlements to disable most sandbox security limits. For more information about them, follow the link in App Sandbox Resources.
IMPORTANT Don’t be alarmed by the temporary in temporary exception entitlements. That word makes sense when you view this from the Mac App Store perspective. Back in the early days of the Mac App Store, some apps were allowed to use temporary exception entitlements because of limitations in the App Sandbox. Once App Sandbox was sufficiently enhanced, these temporary exception entitlements were no longer allowed in the Mac App Store. However, there’s nothing temporary about the implementation of these entitlements. They work today and are expected to continue working in the future. Using them in a directly distributed app is not a problem.
Non-sandboxed XPC services
Not all sandbox security limits have a corresponding temporary exception entitlement. For example, the sandbox prevents you from sending a Unix signal to other processes, and there’s no temporary exception entitlement to allow that.
If you run into such a limit, move that code to a non-sandboxed XPC service, then have the main app request that the XPC service perform the operation on its behalf.
An XPC service can be useful even when there is a temporary exception entitlement to disable a specific sandbox security limit. Continuing the Apple event example from above, if you put the code that sends the Apple event into an XPC service, you only need to apply the temporary exception entitlement to that service, not to your app as a whole.
Conclusion
If you directly distribute your app, consider enabling the App Sandbox. It has some important benefits, and it might be more feasible than you think.