Understanding The Debate Over Apple’s Mac App Store Sandbox

| Ted Landau's User Friendly View

Sandboxing was very much in the news last week. I tripped over a half-dozen articles on the topic without even searching.

No, I’m not talking about play areas for toddlers. I’m talking about an OS X feature that Apple will require all apps sold in the Mac App Store to implement.


At its core, sandboxing is a security enhancement. A sandboxed application is confined to its own container (i.e., sandbox), unable to access any resources or perform any actions that would necessitate going beyond its walls. Most especially, this prevents one application from affecting another one in some malicious way. Without such protections, for example, an application could theoretically issue UNIX commands to delete files on your drive without your knowledge or intent. Or it might attempt to extract passwords from other applications and send them to a pirate server. The sandbox restrictions similarly protect you from unintended non-malicious conflicts that may occur between applications.

This all sounds great except that many applications need at least some outside access to carry out their primary functions. A photo editing app, to take one obvious example, would be useless if it were blocked from accessing the photos in your iPhoto Library. To solve this conundrum, Apple has created a list of explicit “entitlements” that an app can request when it is submitted for approval to the Mac App Store. Entitlements include actions such as read-only or read/write access to user folders (Music, Pictures, etc.), interaction with USB devices, and ability to print. Apple decides whether or not to approve the requested entitlements for each app.

In addition to increasing security, Apple believes that sandboxing will simplify the user experience in the same way that fences can “simplify” interactions between neighbors. This is important as Macs move more and more toward being “consumer” devices. If all this sounds vaguely familiar, it’s because it is very much how things already work for iOS devices. Sandboxing on the Mac is yet another example of Apple’s iOS-ification of OS X. 

Apple made it clear months ago that sandboxing was coming to the Mac App Store. In fact, some apps in OS X Lion (notably Preview and TextEdit) are already fully sandboxed.

[Pro tip: To see whether a particular app/process is currently sandboxed, launch Activity Monitor and select Columns > Sandbox from the View menu. A new column will indicate Yes or No for each open process.]

So why the recent flurry of activity on this topic? Because Apple sent an email to developers last week, postponing the looming deadline for mandatory implementation of sandboxing from this month to March 2012. Writers (including myself as of this article) took this as an occasion to reconsider the pros and cons of sandboxing.

Before I offer my opinions, I want to give you an sense of what all those other writers have been saying. The overriding point in almost every article is that the advantages of sandboxing come with a cost. The big question is whether or not the trade-off is worth it.

Everybody’s talking

Pauli Olavi Ojala [Naming Things] warns: “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.” Further, “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.”

As noted by several articles, Apple’s own apps (Final Cut Pro X, Motion and Aperture) currently support plug-ins — something not permitted with sandboxing. Will Apple continue to allow its own apps to violate the rules come March? Apple isn’t saying yet.

Andy Ihnatko [Macworld] worries that one “impact of sandboxing on automation is that apps that want to control other apps via AppleScript are kind of hosed.”

Wil Shipley [Call Me Fishmealargues “One problem with entitlements is that there are still many actions for which their is no entitlement available as yet. And it’s not a perfect security system anyway. [Sandboxing] has no effect on non-App Store apps or apps that disguise the reason they are asking for entitlements.”

Wil would prefer that, instead of focusing on sandboxing, Apple use certificates (another security mechanism that already exists in both iOS and OS X). Apple should “allow each developer to sign her applications with the certificates Apple provides. Lion should only run applications with Apple-provided certificates, and Lion should have a control panel that says, ‘Here’s a list of applications you (the user) will allow to be run that don’t have trusted certificates from Apple.’”

Chris Foresman [ars technica] talked to several developers, most of whom offered positive assessments of sandboxing. For example, “Agile Bits was quick to add sandboxing support to its popular password locker app 1Password in anticipation of the original November deadline. While it took some work on the company’s end, including a removal of some functionality and flexibility from the software, Agile Bits believes it was the right way to go.”

This loss of functionality to meet the demands of sandboxing was a concern echoed several times: “The problem, as many see it, is that developers will either be forced to remove functionality that users have come to rely on or simply not sell their software via the Mac App Store.” Bare Bones Software’s Rich Siegel added: “[Bypassing the Mac App Store] really isn’t an answer at all, because not being in the Mac App Store is not an option unless you’re willing to walk away from a majority of your audience.” [ars technica]

Lex Friedman [Macworldsimilarly noted that “customers will be surprised and confused if their Mac App Store purchases get updates that remove prior functionality to comply with sandboxing rules.” Peter Maurer and Rob Griffiths (of Many Tricks) added: “As of now, entitlements for the core features of many of our apps don’t even exist, which means we cannot make them compliant at all.” While sandboxing can help keep Macs safer, they compare it to “saying that by keeping your laptop plugged in at all times, you’ll never run out of battery charge: It’s true, but it doesn’t mention the tradeoffs involved.”

Still, several postings (as well as numerous readers comments) stressed that developers can choose to market their apps outside the Mac App Store — thereby avoiding sandbox concerns. Apple does not have an absolute requirement for sandboxing in OS X. At least not yet. “The obvious counterargument is that it’s Apple’s store, they make the rules, and nobody forces developers to submit their apps.” [Naming Things]

While acknowledging potential problems with sandboxing, Topher Kessler [C|Net] concluded: “To an extent, it may be best to view Apple’s sandboxing requirement similar to a mandatory helmet law — some may be concerned about Apple enforcing the use of it, but overall despite its burdens its purpose is to ensure safety and stability.”

My turn

When I first heard about sandboxing coming to OS X, my reaction was a resigned sigh. I was not surprised by the move but I did not look forward to the change.

I don’t have any anti-virus installed on my Mac. I use only minimal firewall protection. I regularly download software from the web. Maybe I’m flirting with disaster, but (despite my laxity) I have not had a single security-related problem of any sort in over a decade. In fact, I can’t recall ever being the victim of a malicious attack that sandboxing would have prevented. Based on conversations I’ve had with others, I believe my experience is fairly typical. Yes, sandboxing will make things safer. But, given the overall safety of the Mac, the likely minimal benefits don’t seem worth the cost to me. If we really need to do something beyond the status quo, perhaps Wil Shipley’s idea of using Apple-approved certificates would work better.

In any case, sandboxing does not mean the end of trouble for users. Sandboxing can lead to problems of its own. For example, as covered in a MacFixIt article, if Mail’s option to “mail a selected PDF document,” stops working, the recommended fix is to delete likely corrupt files in a sandbox-related folder in the now-hidden-in-Lion Library folder of your Home directory.

Yes, if you want to avoid sandboxed apps, you still have the option of going outside the Mac App Store. But I believe this will be a less and less viable option over time, as the Mac App Store becomes the dominant source of all Mac software. Eventually, Apple may prohibit non-App Store software from loading on a Mac. That’s the way things are now on iOS devices. Apple has to be at least thinking in this direction for the Mac as well.

I concede that there is value to sandboxing. Without doubt, sandboxing offers increased security. That’s always a good thing. From a business perspective, sandboxing may almost be required for Apple. When users buy software from an Apple App Store, there is a sense in which users believe that Apple has put its “stamp of approval” on the app. Indeed, it has. Apple has reviewed the app prior to accepting it into the Store. If things go maliciously wrong with an approved app, Apple will (rightly so) bear part of the blame. Sandboxing is one way Apple can protect itself here.

Still, I keep coming back to the trade-offs not being worth it. If nothing changes between now and March, and sandboxing is implemented as is, I believe there will be more complaints than kudos from the Mac community (although I suspect the majority of Mac users will hardly notice the change and say nothing).

All of that said, I believe there is reason for hope — hope that things will change between now and March. The fact that Apple has delayed the implementation of sandboxing by four months tells me that, at the very least, Apple recognizes that the technology is not yet fully baked. It may also mean that Apple wants more time to listen to feedback from developers, possibly resulting in concessions that loosen the present restrictions.

In the end, sandboxing, in whatever form it ultimately takes, is just the proverbial tip of the iceberg. It’s one piece of Apple’s overall plan for the iOS-ification of OS X. This is a major strategy shift that will play out in a variety of contexts over the next few years. For better or worse, I don’t see Apple backing away from this shift. Users and developers had better get on board or get left at the station. There’s no other choice.

Popular TMO Stories



Ted, I knew you would come to this topic with your good eye. Your clarity is always dead centre. Always.

Bosco (Brad Hutchings)

Ted, why don’t you think that competitive feedback will have any effect on Apple’s plans and execution?

Consider an app that is available for both Windows and Mac, just as there are many apps available for both iOS and Android. What if the Mac version is less capable than the Windows version? Or it gets updated less often? Or it’s held in app purgatory longer? We’ve seen that play out with, for example, the Facebook app on iOS after the Android version basically leap-frogged it a little more than a year ago.

Do you think that Apple-imposed speed bumps make Apple devices less competitive? Do you think that Apple has to consider that, or do its customers just blindly accept that Apple is right to impose additional costs on software developers?


Great survey of the varied opinions on sandboxing. I hadn’t read any substantive description of what Mac OS X’s sandboxing feature was, and I’m a little surprised how restrictive it is.

Eventually, Apple may prohibit non-App Store software from loading on a Mac.

This is the only thing I really fear. While the one-store works fine for iOS, I don’t want Mac OS X to have to develop a “jailbreak” community just to run other software. I’m encouraged that there are already other reputable stores where Mac users can pay for and download software, such as Steam, Amazon and Bodega. I would like to see disenfranchised utility makers like Many Tricks rally around a reputable non-Apple app store and have it become big enough that Apple can’t prohibit non-App Store software without a major user revolt.


I guess I’ll be staying on Snow Leopard a loooong time!


Very good article Ted.  Made for a great read.

As a developer, I can understand the concerns that the sandboxing restrictions will cause.  However, as a user I think this is long overdue.

We’ve been brainwashed for decades and accepted the headaches of rogue applications and horribly-dfesigned software crippling/corrupting systems as the status quo.

In many ways, the blame all comes down to developers and the quality of their work.  Apple wants to make their systems as foolproof as possible so users no longer have to worry about their systems getting messed up.  Yes, it will involve growing pains and I’m sure it’s not going to be 100% perfect when it begins.  Apple and the community will just have to work their way through it.

It will evolve.


horribly-dfesigned software crippling/corrupting systems

Interesting; you seem to be saying that sandboxing will make the platform more stable, not just more secure. Like Ted, I see sandboxing as solving a problem I don’t have (malware), but freezes, crashes and the like are problems most users have seen. If sandboxing reduces such things significantly (though I doubt it will) more power to it. Even so, I hope I always have the option to trade some of that stability for the flexibility to run anything I choose.


OK, I’m a bit concerned, especially if Apple starts at some point to require that all Mac apps must go through the app store.

I realize that the list of entitlements will most likely expand or change, but there sure aren’t many right now. I’m the lone Mac in a small business (architecture) that accesses all my files on a Windows network. Any work-related files need to reside on the server where they can be accessed by everyone and are arranged in directories organized by projects. I can’t have files residing in sandboxes on my machine.

So will the ability to organize files in a way that makes sense to me be gone? What if I need to send a client a .jpg file, a .pdf file, a .doc file and an AutoCAD file? Do I really need to send four separate emails from within each of the four apps involved? That’s craziness. Also, there are file name repetitions from project to project. Even if I were a one man business with one Mac, I would have to have huge file names to keep files unique in the absence of a folder hierarchy. For example, I’m sure there are hundreds of “floorplan.dwg” files on our server. Am I supposed to name a file “projectnameX preliminary rejectedversion floorplan.dwg” to keep it apart from “projectnameY final floorplan.dwg”? And do that in every app?

I need to organize my files by client and project, and I need to work from a Windows server. No two ways about it. It works just fine right now. (Still using Snow Leopard.)

What about multi-app workflows that many of us pros use? I have company charts created and edited in Illustrator but saved as .pdf files so that no one else needs a copy of Illustrator just to open them and so that I’m the one controlling the changes. Or, I might take an AutoCAD floor plan, import the .dwg file into Illustrator to tweak line weights and make other adjustments, export the file to .psd where I use Photoshop to create an artistic color rendering, and finally save it as a .jpg for the client or for presentations in PowerPoint.

What if I create a design sketch in SketchBook Pro and Save As to .psd? Where’s the file? With the app that created it or with the app whose file format I’ve saved it to? Have Autodesk and Adobe worked together to allow ‘Open In’ going in both directions?

How does all this fit into the sandboxed future? Am I going to be forced back to Windows? Can someone put my mind at ease?

I’m having a hard time believing Apple is really willing to leave all but those with just very basic computing needs behind. Jobs said years ago when asked what he’d do if he were back at Apple something like milking the Mac for all it’s got left and then moving on to the next thing. Are we there?


Even if I were a one man business with one Mac, I would have to have huge file names to keep files unique in the absence of a folder hierarchy

You are conflating iOS file management with sandboxing.  That’s not how it works on Lion, you can open files from multiple locations in your folder hierarchy in Mail all at the same time.


Sandboxing is a feature originally specced for the OLPC XO operating system, as part of then security chief Ivan Krstic’s Bitfrost specification (http://wiki.laptop.org/go/Bitfrost).

Krstic now works for…

Apple. (http://radian.org/notebook/2009-05-11)


I use a Sandbox feature from Super Duper. In simplest observation, it creates a bootable system which is isolated from my usual system. It is supposed to protect me from having to reconstruct my OS, if i should crash because of an update (That never happened anyway). It contains the cloned system and aliases to the applications and etc. on my “usual system”.

Why must Apple complicate things? Is this a way to force us to spend more money in some way? I too will probably stay with Snow Leopard.

Log in to comment (TMO, Twitter or Facebook) or Register for a TMO account