Apple has stated that as of June 1st this year apps being submitted to the Mac App Store (MAS) must be sandboxed. Developers embracing sandboxing may face major problems to preserve their app’s functionality especially when supporting different OS X versions.

This is because Apple’s whole concept of sandboxing/entitlements is not complete and different OS X versions have different suppport for sandboxing.

Let’s take a closer look at different scenarios.

Supporting 10.6.x

There is no concept of app sandboxing in 10.6.x. A sandboxed app should run as if not sandboxed. Yet Developers must ensure not to apply sandbox related API (this is developer best practice).

Supporting 10.7 upto Current OS X Version

There currently seem to be two main feasible strategies to adopt sandboxing:

1. Strategy: “Early Feedback” (more predictability, more work)

   • Sandbox your app and give it as broad temporary entitlements as you need
   • File a radar (bug report) to Apple justifying your app’s need to use these temporary entitlements
   • Submit your app as early as possible to MAS (referring to that bug report) to get early authoritative feedback from Apple
   • As Apple provides more powerful and reliable sandbox related API adapt your app to those APIs and revoke entitlements you no longer need (before Apple does)

   BTW: I have not found any recent evidence that Apple would rather grant your app some temporary entitlement if that entitlement was isolated in a single purpose XPC Service. All questions about this being asked in Apple’s developer forum went unanswered (to my knowledge).

   This approach is viable only if the following conditions are met:

   • your app’s needs can be resolved by the available entitlements (either temporary or non temporary) in the OS X version(s) you want to support
   • Sandbox related or sandbox affected Apple APIs you need to use are already mature in the OS X version(s) you want to support
   • Apple will provide appropriate APIs to substitute your app’s temporary entitlements prior to revoking those entitlements from your app
   • Apple will provide some sort of “versioned entitlement mechanism” allowing you to use broader entitlements in OS X versions that do not yet support APIs that are meant to substitute for revoked entitlements

2. Strategy: “Wait and Wonder” (less work, less predictability)

   • Do not sandbox your app (immediately)
   • Only submit bugfix releases to MAS
   • Once Apple provides sufficiently powerful entitlements and/or reliable APIs to suit your sandboxed app submit it sandboxed to MAS

   Here, the following conditions must be met:

   • Your non-sandboxed app entered MAS before June 1st.
   • For some hard to figure out period you are willing to refrain from submitting new versions of your app that add additional functionality (only bugfix releases permitted)
   • Apple will provide entitlements or APIs you need to sandbox your app before your customers abandon your app for lack of evolution
   • Apple will provide some sort of “versioned sandbox mechanism” entitling your app to be sandboxed starting only with a specific OS X version. Otherwise you would have to have two different versions of the same app in MAS (one sandoxed, one not) to support ‘older’ OS X versions.

You will have noticed that either strategy is somewhat depending on versioned sandboxing / versioned entitlements like

• Don’t sandbox me if I am running on OS X upto version X.Y.Z (because Apple has not provided enough entitlements/API upto X.Y.Z to support my app)
• Give me a temporary entitlement X upto OS X version X.Y.Z and beginning with X.Y.Z+1 revoke X (since Apple has given me some API so I don’t need X anymore)

Apple has not provided such mechanism yet.

If you are an affected developer or you sympathize with an affected developer you should (should I say must?) file a bug report regarding this omission to Apple (e.g. like Daniel Jalkut did). This will encourage Apple to provide such means with high priority.