With the March 1st start date approaching when sandboxing becomes a requirement for submissions to the Mac App Store, I’ve been considering my options.
I have 2 products, one of which was easy to sandbox and the other, well, not so much. When I say “easy to sandbox”, I mean it fit neatly in the “permanent” entitlements and doesn’t need any files migrated into the sandbox, besides it’s preferences, which is done automatically for you.

Now, my sandbox technical challenges are not DOA. Some apps and classes of app are in effect outlawed by the sandbox rules. I feel for the developers of those apps, but fortunately for me, I’m not facing that.

My challenges fall more the “a few features may need rethinking and rewriting” category. At first I expected to have a long hiatus between updates while I worked on these features. But instead, I’m easing this transition by implementing sandboxing in 2 phases.

1. Add sandboxing to the MAS build of my app. Use temporary entitlements where necessary to maintain functionality. Make minor adjustments to run inside the sandbox. Submit an update to test the approval process.
2. Begin the rethinking and rewriting of sandbox-incompliant features.

Advantages I can see to this approach:

• I can continue to fix bugs, and issue updates beyond March 1st without a long hiatus.
• Development on my app does not appear quiescent.
• By submitting early, I’m not testing approval when trying to push out a needed bug fix.
• By using temporary entitlements, I signal to Apple that these are needed and useful.
• I buy more time to rethink and rewrite.

Sandboxing is a great leap in application security but every app has a different story when it comes to the implementation details. I encourage bug reporting. It’s important to explain to the Apple engineers what we developers need. And I hope that some of the thoughts here help you navigate the challenges.