Apple announced today that, starting in March 2012, all apps on the Mac App Store will be required to run in the so-called “App Sandbox”.
The sandbox is an environment that locks down the Mac in ways that match (and exceed) the limitations found on iOS. A sandboxed app doesn’t have direct access to any files or frameworks on the system. It can’t access the network or any devices.
For the app, nothing else exists on the system except for those files and APIs that the operating system explicitly makes accessible to it:
By default, the sandboxed app doesn’t really have anything of its own. Even files in its own Application Support subfolder may be deleted by the operating system if it wants to e.g. reclaim some disk space. The sandbox analogy is quite fitting indeed — inside it, an app’s data has all the permanence of a sand castle.
Do you feel entitled, punk?
Since the Mac isn’t a phone, most apps need to do something more persistent than e.g. rendering a nice image of a collapsing sand castle. To enable these apps to perform their job, Apple has created a list of permitted capabilities called “entitlements”.
Here is the complete list of available entitlements:
- Read-only access to the user’s Movies folder and iTunes movies
- Read/write access to the user’s Movies folder and iTunes movies
- Read-only access to the user’s Music folder
- Read/write access to the user’s Music folder
- Read-only access to the user’s Pictures folder
- Read/write access to the user’s Pictures folder
- Capture of movies and still images using the built-in camera, if available
- Recording of audio using the built-in microphone, if available
- Interaction with USB devices
- Read/write access to the user’s Downloads folder
- Read-only access to files the user has selected using an Open or Save dialog
- Read/write access to files the user has selected using an Open or Save dialog
- Child process inheritance of the parent’s sandbox
- Outgoing network socket for connecting to other machines
- Incoming network socket for listening for requests from other machines
- Read/write access to contacts in the user’s address book
- Read/write access to the user’s calendars
- Use of the Core Location framework for determining the computer’s geographical location
That’s it. (There are also a couple of temporary exception entitlements that will be going away. If your app uses Apple Events or Mach ports, Apple may grant you a temporary license to keep doing so, if you can make your case convincingly.)
Need to access hardware using something else than USB, for example Thunderbolt, FireWire or Bluetooth? Tough luck. (Just because these interfaces are on your Mac doesn’t mean Apple wants anyone to use them via 3rd party software.)
Need to communicate with processes that your app didn’t directly start,
or perhaps take screenshots? Not going to happen.
Update: Gus Mueller, author of the Acorn app to which I linked, reports that screenshots are allowed in the sandbox. My apologies for the mistake. (Taking screenshots essentially means an app can read the contents of other applications’ windows. This is clearly a security risk in the same vein as opening arbitrary files, so I had assumed that screen capture is disabled in the sandbox.)
Maybe you’d like to read and write files in a known location on a network disk? Not possible, unless you pop up the Open/Save dialog for every file.
It’s important to note that these entitlements are granted by Apple, not by the user herself. App developers must provide justification for their entitlement requests when submitting an app to the App Store. If the Apple curator thinks that your app is not deserving of accessing the Pictures folder or interacting with USB devices, she has every right to turn down your request without additional justifications. (We’ve seen many Beckettian variations of this scenario played out on the iOS App Store over the past years.)
One side-effect of the sandbox model which makes me particularly sad and nostalgic is that it kills the notion of plugins. This will also affect many of Apple’s own pro apps on the App Store.
Traditional plugins are binaries that are installed into a known shared location. On startup, a host app that supports plugins will look for them in the shared folder, and if they’re deemed compatible will make the plugins available within the app. Typical plugin scenarios are image and video filters, file format import/export, and providing direct interfaces to web services.
Many professional apps have a thriving plugin ecosystem. Adobe Photoshop started the boom back in the mid-’90s. Photoshop plugins have faded in popularity since those days, but plugins continue to be important for video and visual effects work, where users tend to have very specific and complex needs that the host app developers can’t possibly anticipate. Plugins are also great for apps like Aperture that focus on workflow management rather than editing tools, allowing 3rd parties to “fill the holes”.
In the brave new sandbox, this is not going to be possible. For starters, sandboxed apps can’t see the shared locations where plugins are traditionally installed.
Even if the app could see the plugins, it wouldn’t be able to load the code because sandboxed apps are code-signed. The sandboxed app binary contains an encryption signature inserted by Apple that tells Mac OS X that this code is safe to execute. Third party plugins wouldn’t have this signature, so they wouldn’t run.
I’m curious to know what will happen to Apple’s own applications that support plugins, including Final Cut Pro X, Motion and Aperture. These apps are only available on the Mac App Store. There is no way to even get a temporary exception entitlement that would allow plugins (at least for 3rd party developers).
If Apple were to keep plugin support in these apps, it would make it obvious that they don’t need to play in the same sandbox as everyone else. I don’t think they would want such a blatant example of two sets of rules on the App Store. Hence, I’m afraid that the days of plugins in Apple pro apps are numbered.
The obvious counterargument is that it’s Apple’s store, they make the rules, and nobody forces developers to submit their apps. This of course remains true. Mac apps installed outside the App Store will continue to run and enjoy the access privileges that, by and large, have allowed these apps to exist in the first place. (Think of a Mac app that you’ve loved over the years. I’m 99% sure that it does something that is not covered by the App Store entitlements.)
However, the Mac App Store is increasingly the place where Mac users discover apps. Apple’s big push with making Lion and the pro apps exclusive to the App Store has guaranteed this. Since Apple now considers the App Store such an integral part of the Mac platform, they can’t simply pretend that the other stakeholders in this ecosystem don’t exist.
Furthermore, the necessity of requesting entitlements from the App Store curators for basic things like Open/Save dialogs has got me slightly queasy. Until now, I’ve always thought of the Mac as a platform that has enabled me to excel as a developer and make a living. I’m extremely grateful to Apple for building Mac OS X into such a great software environment.
Yet now I feel worried to even speak up about this. If someone at Apple decided they didn’t like me, they can soon take away my ability to show file dialogs. I know I’m just being paranoid… But that’s how people start to behave in situations where they feel they don’t have any power over what’s being done to them.
Is this a shadow of what it felt like to be a sharecropper? I’m reminded of this 3-year old blog post by Tim Bray:
“I don’t want to write code for a platform where there’s someone else who gets to decide whether I get to play and what I’m allowed to sell, and who can flip my you’re-out-of-business-switch any time it furthers their business goals.”