Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms

When Apple launched OS X 10.7 (Lion) to the public in July, most of the media focus was on the user-facing changes, such as the iOS-like Launchpad, or trackpad scrolling direction. In Lion, Apple also made a number of under-the-hood changes in their security model that may start affecting Mac App Store customers in the near future.


Amongst the many new features in Lion, Apple included a more robust sandboxing system that can prevent 3rd party applications from causing unintended damage. In their Lion review, ArsTechnica explains how sandboxing works in general:

Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.

Developers of these sandboxed applications must take special measures to break up their application into individual processes that only are able to do exactly what they need. Apple still allows user initiated actions to perform as expected and override the sandbox, but app-initiated actions in sandboxed applications will be restricted. This means that system wide file access and inter-app scripting and interactions will not be allowed.

Apple had originally told developers that sandboxing would become a requirement for Mac App Store apps as of November, 2011. Tonight, however, Apple emailed developers that the Sandboxing requirement will now go into effect on March 1, 2012.

As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing.

While sandboxing will increase the security of Mac App Store apps, there have been concerns that the restrictions will stifle features and innovation on the Mac platform.


Mac Apps that may be affected: TextExpander, CoverSutra, Transmit, Fantastical
In October, Macworld published a pair of articles from Jason Snell and Andy Ihnatko expressing their concerns about the new restrictions.

Snell reported that he had heard that some Mac developers will be removing features from their apps or reducing their functionality to fit them in Apple's sandbox.

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.

Examples of Mac Apps that will be affected include iTunes controllers (Tagalicious, CoverSutra), inter-app communication (Fantastical), apps that browse the file system (Transmit), system-wide keyboard shortcut utilities (TextExpander), file syncing, and backups utilities.

While Apple is offering developers some short term exceptions to get around sandboxing, the company promises that those exceptions will be temporary. Some developers have said there is a lot of uncertainty around how long Apple will allow these apps in the Mac App Store after the deadline. With the new delay until March, some developers are holding out hope that Apple may be trying to come up with a better solution than simply pulling these apps off the Mac App Store.

As Snell points out, developers can choose to distribute their non-sandboxed apps outside the Mac App Store, but those developers would be giving up a huge distribution point.