It is said that from November 2011 on all apps on the Mac App Store will have to implement Application Sandboxing. Basically, this mean that an app will run inside its private little sandbox and has only limited access to the world outside the sandbox (see this Apple documentation for more details). While it needs only one click in Xcode to turn on sandboxing for an app, I expect the effects of mandatory app sandboxing on the Mac App Store ecosystem to be quite measurable.
Until now it seems that all new apps submitted from November on will have to implement sandboxing but the same may be true for apps already available on the Mac App Store, e.g. if they are to be updated. So it is likely that in the long time no app on the Mac App Store will be able to avoid sandboxing.
Inside the Sandbox
A sandbox is like a virtual container for data an app uses. An app can store user data, preference data or anything else inside its sandbox and it‘ll work just fine. The sandbox files are stored in a container folder in the user‘s library folder.
Connecting to the Outside World
However, as soon as an app wants to connect to the world outside the sandbox, according to Apple‘s concept of sandboxing it needs to be entitled to do so. Entitlements are available only for a limited number of types of interactions and have to be set by the developer while designing the app. Interactions for which there are no entitlements are just not possible. As a workaround there are temporary exception entitlements allowing for some more allowed behaviour of apps, but as temporary denotes these entitlements are only available until further notice. To let the fun begin, let‘s see how that is intended to work and how it will affect developers. The following list is in part based on my own tests.
Internet and Networking Access
This should work, there are entitlements for incoming and outgoing network connections and some iCloud entitlements.
This should more or less work for standard peripherals and is unsure to work for non-standard peripherals. There are entitlements for camera, microphone, USB and printer access.
Keyboard and Screen Access
As long as an app has the focus, of course keyboard and mouse events will be routed to that app. In addition, it seems that hotkeys will continue to work without any entitlements, which I‘ve tested with the Carbon RegisterEventHotKey function. A tough sandboxing concept probably shouldn‘t allow that. The same is true for screen capturing with CGWindowListCreateImage still working so that an sandboxed app may capture the whole screen including the window contents of other apps without (non-existing) entitlements for that.
User Data Access
Apple provides entitlements for accessing address book data, calendar data and to determine the computer‘s location, all by using the appropriate APIs.
File System Access
A tricky one. By default, a sandboxed app has no access at all to user files outside its sandbox container. Some folders may be accessed by using specific entitlements, this is available for the Downloads, Movies, Music and Pictures folders. In addition, an app may be entitled to allow users to open and save specific files, though this only covers situations in which the user is presented a file dialog panel.
At the moment there are some temporary entitlements available that allow for read and write access of files and folders anywhere on the local disk, but they work in a way that the developer has to determine the file or folder path already at design time. So there is no possibility to access arbitrary files whose paths are not hard-coded in the app. This also means that many methods of NSWorkspace and NSFileManager are likely not to work anymore because they implicitly would violate the sandboxing rules.
At the same time it is still possible for a sandboxed app to read-access non-user files and folders, for example the /Application and /System folders (including subfolders), without needing an entitlement.
Many apps need to communicate with other apps or with the operating system. Be it that an app wants to open a new Finder window, use an email client, receive the title of the song currently played by iTunes, get a list of recently opened files from the system and so on. This will either be impossible at all with a sandboxed app or possible only under very strict conditions. Apple allows sandboxed apps to receive Apple events from other applications but doesn‘t foresee a sandboxed app to send Apple events or other kind of information.
However, there are temporary entitlements for sending Apple events and for connecting to certain system services. I found that nonetheless the Accessibility framework is not working and that NSMetadataQuery has problems to return any data. If inter-application communication is limited like this and data of other apps are really capsuled, a lot of tools won‘t work from inside a sandbox.
A Very Small Intersecting Set
I don‘t argue that application sandboxing is not a nice idea. Indeed, the concept Apple is likely to introduce is a coherent one and will protect users from malicious code. Nonetheless quite a number of apps will have to leave the Mac App Store. I‘m afraid that my own apps will be among them.
Though Apple is still working on details of how application sandboxing will be implemented and there are some inconsistencies at the moment I write this, it is unlikely that the basic concept will be changed. Using temporary exception entitlements will work for many apps, but only as long as the temporary entitlements continue to be available.
The long term effect of mandatory sandboxing will further increase iOSification of the Mac and accelerate the trend Marco Arment predicted a year ago: A very small intersecting set of today‘s Mac apps and tomorrow‘s Mac App Store apps. Of course developers will continue to write apps without sandboxing and distribute them outside the Mac App Store, but at least some of them will decide not to write such kind of apps anymore. For myself I haven‘t decided yet.