I wrote a draft of this post a few weeks ago, before Mac OS X Mountain Lion was announced. It was pretty critical of Apple’s aggressive approach to sandboxing, and I’ve kept most of that, but the new Gatekeeper feature for Mountain Lion at least gives me a way out. I don’t think Apple would have created Gatekeeper if they planned to abandon apps sold outside of the Mac App Store.
For the next release of my app Clipstart, I will be removing it from the Mac App Store and only selling directly from my web site. With Gatekeeper I hope to have some confidence that my customers will still be able to run the app on future versions of the OS.
But let’s take a step back, to a good blog post from Craig Hockenberry on moving xScope to use sandboxing. One of the most important things to keep in mind is that what works for one app may be unsuitable for another. Craig touches on this with an example from Panic’s Transmit:
"Of course there are some applications that have a harder time than others: primarily if those apps require access to all or part of the filesystem (think about syncing data with Transmit, for example.)"
Clipstart also falls into the same “needs to access the whole file system” category as Transmit. It’s not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don’t see a clear path forward for existing customers to move into such a restrictive environment.
Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.
Atlassian has made a similar decision for their app SourceTree. On the sandboxing restrictions:
"The trouble is, the sandboxing implementation currently in place on Mac OS X Lion doesn't allow for all the behaviours that real Mac applications do _right now_, behaviours which are not at all contentious, are approved in the Mac App Store already, and indeed are very much appreciated by users."
Daniel Jalkut continues this argument, saying that sandboxing could be good for developers, if only the current entitlements weren’t so very incomplete. That’s true. But we can only make decisions based on what entitlements and APIs are there today, and today it’s not enough.
I will try to make this casualty of sandboxing as painless as possible for Clipstart customers. I will honor Mac App Store receipt files so that everyone can migrate to new versions of the app. And I’ll provide extra serial numbers to anyone who asks, for fresh installs on machines that never had the Mac App Store version.
Clipstart has turned out to not be a very good fit for the Mac App Store anyway. It’s the kind of app that you need to download and try out before committing your whole video library to it. Sandboxing is just the latest and most significant in a series of frustrations with the MAS.
For my customers, sandboxing isn’t actually a feature; it’s a bottleneck to getting work done. I can’t justify spending any time on it. I already have a product and platform (Tweet Library for iOS) where I can play the app review game. I want my Mac app to be a break from that, with a total focus on making the app better and a release schedule and feature set that I control.
So it was a relief to hear about Gatekeeper. I don’t want pulling Clipstart from the MAS to automatically doom the product, and now I don’t think it will. Instead of shying away from features that won’t work in the sandbox, I can even embrace them as a competitive advantage. I’m more excited than ever to get back to Mac development without this decision and chilling effect hanging over my head.
