Sandboxing... climbdown?
November 03, 2011

So, Apple have announced the deadline for developers to have their Mac App store apps work with sandboxing, and suddenly it’s March 2012, and not the November 2011 date that was widely understood amongst the developer community.

I guess I should be grateful, since the current sandboxing is distinctly half-baked as a plan. The only problem is, working on the assumption that we had to have sandboxing implemented by November, I’ve now got a relatively major update to Neu which uses it, and is waiting on just one sandboxing bug to be sorted out. Having removed the November deadline from developers, Apple have also conveniently removed the urgent need to fix the bug that’s holding me up.

So now I have to decide whether to hold back the Neu update - potentially for four months - whilst I wait for the bug fix (not a particularly attractive option), or to do more work turning sandboxing off again in Neu and splitting out the sandboxing-inspired changes from those that can ship regardless.


As I’ve said before, I’m broadly in favour of sandboxing, or at least the the motivation behind it. Anything we can do to protect users from malicious software is fine by me, as long as it doesn’t detract from what users actually want to do.

The way Apple have gone about implementing it though, has left a lot to be desired, and smacks of a certain hubris. They told us, rather than asked us, what we needed. Perhaps more worryingly, they got the answer quite substantially wrong. It’s good that they’ve seen sense and delayed it, but by announcing a new date they are still holding up a hostage to fortune, since we don’t have a fully working system yet.

Personally I think that they made a fundamental error in even considering using a metaphorical stick to force developers to adopt it. It would have been far better to use a carrot. If the Mac App store showed a subtle badge on sandboxed apps, with supporting material explaining that apps with the badge had “enhanced security” or some such phrase, it would create a positive incentive for developers which ought to translate directly into increased sales.

Using an application with “enhanced security” is going to be attractive to most users, regardless of exactly how much they understand about what the “enhancement” actually represents - but it leaves the choice in the hands of the user.

Whilst I’m not normally a great fan of marketing bullshit, or of overloading users with more information than they need, I think that this is a situation where presenting a simplified (but accurate) picture of the benefits of sandboxed apps is far preferable to forcing all apps to be sandboxed.