Mac OS X developers have been given a few extra months to accept the Mac App Store app sandboxing requirements… or to forget about selling their apps through Apple’s store altogether.
Originally, the deadline was November 1st, but Apple has since uncharacteristically extended the deadline to March 1, 2012. After that, all apps sold in the Mac App Store must use Mac OS X Lion’s new sandboxing framework. That framework is another thing Lion had adopted from iOS and is meant to increase security on the Mac.
With the deadline extended, developers now have about four months to decide on whether they will support sandboxing in their apps. The problem? If they do, some apps will become just shadows of their former selves.
Although many developers have already prepared for the deadline this month, I’ve spoken to many others who either still weren’t ready or just didn’t like the concept at all. Some developers see the imposition of sandboxing as something that will limit or severely reduce the functionality of their apps. In addition, sandboxing means customers might suddenly discover some of their apps’ favorite features just stop working come March 1st.
It seems clear Apple is trying to fundamentally change the way developers write software for the Mac, and the extended deadline means a lot of developers are fighting the change. It’s easy to understand why. There was already a trade-off between the need for an app to be secure and developers’ need to be free to write the software they wanted, and Apple is making the trade even tighter than it was before.
What Is App Sandboxing?
Sandboxing apps isn’t new. In fact, it’s required for all apps running under iOS on the iPhone, iPod touch and iPad. What ‘sandboxing’ means is that an app runs partitioned off from the operating system and the other apps running on the same device. When apps are sandboxed, they cannot mess up other apps or the operating system running on that device. In other words, if something goes wrong with an app, then it can only ruin its own sandbox. It can’t bring the whole system crashing to a halt along with it.
In addition, sandboxing has great benefits when it comes to protecting a system from being compromised by malware, in that the only damage malware can do to a running program has to happen within the confines of the sandbox.
But that security comes with a price. Any app running in a sandbox can’t access OS X’s entire file system, communicate with other apps and so on. On the Mac especially, where the app ecosystem has been allowed to flourish for a decade without having to worry about sandboxing, that means features many users take for granted will have to be abandoned in order to comply with Apple’s Mac App Store rules. Here are some examples:
BBEdit and TextWrangler
BBEdit and TextWrangler from Bare Bones Software, Inc. are apps that offer different features depending on where you buy them. If you buy directly from Bare Bones Software, Inc. you’ll have the full-featured BBedit or TextWrangler we all know and love. If you buy them from the Mac App Store, you lose functionality. Here’s how Bare Bones describes the changes:
Are there any differences between the Mac App Store versions of your software and the versions available directly from your web site?
In BBEdit and TextWrangler, authenticated saves (the ability to save changes to files that you do not own) and the command-line tools are not available in the Mac App Store versions, in order to comply with Apple’s submission guidelines.
Authenticated saves are not possible in versions of BBEdit or TextWrangler obtained from the Mac App Store. If you desire this capability, please purchase BBEdit directly from us or download TextWrangler directly from us.
If you have already purchased BBEdit from the Mac App store and need support for authenticated saves, please contact our customer service department for assistance. We will require proof of purchase from the Mac App Store in order to assist you; if you include that information when you write us, doing so will speed the process.
Command-line tools: Any customer who has purchased BBEdit or TextWrangler from the Mac App Store may use the following packages [downloaded from Bare Bones Software website] to install the command-line tools on their system. (These packages are only for use with the Mac App Store versions of BBEdit or TextWrangler, and are not suitable for use otherwise.)
The authenticated saves issue might be a big deal for power users who use BBEdit for a range of high level support or development issues on Macs. Personally, I could not use the Mac App Store version of BBEdit for this very reason, since I often find myself editing many different files on my Macs (see this report). I also find the command-line tools useful, and although you can get them for the sandboxed versions of BBEdit, it is a lot easier just to get them when you buy and download BBEdit from Bare Bones Software directly.
Rich Siegel, founder and CEO of Bare Bones Software, Inc. had this to say about sandboxing:
Sandboxing is a set of measures designed to ensure security. When carried to a rigorous or logical conclusion, however, sandboxing is inherently inimical to applications serving the creative, power user and developer markets. Some middle ground and flexibility, taking into account implicit and explicit user intent, would empower the security without sacrificing the productivity. We hope these issues can be worked out.
AirDisplay
There are some apps that won’t just lose functionality if they come to the App Store. Some apps can never come to the Mac App Store, since they will never be able to meet Apple’s sandboxing requirements. One example is AirDisplay from Avatron, a small self-contained app that doesn’t access outside files. However, according to Dave Howell at Avatron:
The host software [for AirDisplay], with its kernel extensions and other low-level components, would never qualify for app store distribution anyway, so no sandbox issue there (at least unless Apple finally shuts down support for third party drivers completely, heaven forfend!).
In this case, we’ll be okay as long as we are able to buy software from outside the Mac App Store, which so far is possible, but might not be forever. There are very clear business reasons why Apple wants all apps to go through the Mac App Store, because software sold on any other platform doesn’t give them a 30% cut. If Apple ever makes the Mac App Store the exclusive software platform for OS X, software like AirDisplay will just go away.
Other Application Examples
The breadth of apps negatively impacted by sandboxing is huge and almost definitely includes an app you use yourself every day.
As pointed out by MacRumors, there are other apps that will be negatively impacted by sandboxing:
• iTunes controllers (Tagalicious, CoverSutra)
• Inter-app communication apps (Fantastical)
• Apps that browse the file system (Transmit)
• System-wide keyboard shortcut utilities (TextExpander)
• File syncing, and backup utilities (SuperDuper! and Carbon Copy Cloner)
• Applications that capture system sound and reroute it (Audio Hijack Pro and WireTap Studio).
This is not an isolated issue. It’s one that affects a huge chunk of developers and a sizable number of the best apps available on the Mac.
Bottom Line
Apple is currently offering short-term exceptions developers can use to get around the sandboxing requirements, but in typical Apple fashion, these exceptions are only temporary. There is no telling when the apps that were accepted into the Mac App Store with these exceptions will suddenly get booted out. Many developers are hoping Apple will come up with a better solution than just eliminating these apps from the Mac App Store, but if Cupertino has another plan, they are being tight-lipped about it.
This isn’t just a problem affecting developers, though. End users also need to consider the impact this will have on them. It could be significant, as Jason Snell rightly points out over at Macworld:
Not only does this approach risk turning the Mac App Store into a wasteland of arcade games and one-trick-pony apps, it risks dumbing down the Mac app ecosystem as a whole. While developers can always opt out of the Mac App Store, they’re reluctant to do so.
The other question to ask yourself is whether or not sandboxing is even worth the trade-offs. Is it really going to make security better on the Mac? According to computer forensics and security expert Jonathan Zdziarski, probably not:
I don’t think this will benefit security. Apple already has a fairly decent security implementation incorporating FileVault 2, address space layout randomization (ASLR), and of course all of the security that’s found in the Unix operating environment that’s worked just fine for the past 30 years.
Ars Technica concludes:
The ultimate downside, then, could be complete Apple control over which applications can be run on your system. “Sandboxing will severely limit the functionality of Mac applications, and may even make some applications impossible to use,” Zdziarski warned. “The question really is, whether this has to do with security, or Apple’s intent to exert control over what’s installed on the desktop. This paves the path to lock down desktop machines in the same way that the iPhone or iPad are locked down, essentially eradicating any development that isn’t sanctioned by Apple.”
I don’t know about you, but I’m not interested in owning a dumb computer or one-trick-pony apps. I’d prefer the freedom to build or use the apps I’ve known and loved for years versus an app that is watered down, locked down, and ultimately controlled by Apple. I know security is important, but I’d rather be free to use or build the apps the way I want.
This is the ultimate frontier of computer freedom we are talking about here. For good or ill, the computer is a great tool practically anyone can use to build the next best thing. Should Apple really be deciding what the next best thing you build on your computer is going to be? Or is that a decision developers should be able to make for themselves?
