I toss all my Mac app ideas that require more than the default sandboxing rules — no matter how cool the idea is.

The sandbox has a chilling effect on at least one developer. I’d be surprised if it were just me.

I wrote a draft of this post a few weeks ago, before Mac OS X Mountain Lion was announced. It was pretty critical of Apple's aggressive approach to sandboxing, and I've kept most of that, but the new Gatekeeper feature for Mountain Lion at least gives me a way out. I don't think Apple would have created Gatekeeper if they planned to abandon apps sold outside of the Mac App Store.

For the next release of my app Clipstart, I will be removing it from the Mac App Store and only selling directly from my web site. With Gatekeeper I hope to have some confidence that my customers will still be able to run the app on future versions of the OS.

The Broken Sandbox

At its best sandboxing is a means for app developers to faithfully state their intentions in a manner that can be evaluated by users, and also be reliably enforced by the operating system. So if your new “Fun on Facebook” app declares its intention is to connect to the web, you might judiciously allow it. If it says it needs to write files to the root of the filesystem, you’d be wise to search for another app.

Sandboxing on the Mac works by providing developers with a standardized list of “entitlements” which are clear descriptions of things it would like to do on your Mac. Examples include: access the internet, read files from your Pictures folder, print things on your printer.

The number one broken thing about sandboxing as it stands today, is the list of entitlements is simply too limited. Many apps on the App Store, including my own, will need to have their functionality considerably diminished, or in some cases made outright useless, in order to accommodate the available list of entitlements that sandboxing offers.

Sandboxing is a great idea. But if too few developers can use it, most users will never be able to run a sandboxed-apps-only setup, removing much of the purpose of sandboxing in the first place.

And if Mac users perpetually remain accustomed to looking outside the App Store for robust software, it hinders everyone in the App Store ecosystem, including Apple.

On March 1st, Apple will change the rules of the Mac App Store to require all applications to run inside of a ‘sandbox’. Unfortunately, this will disallow important SourceTree functionality that was previously acceptable under store rules. Complying with the sandboxing rules would force us to change SourceTree in ways that would remove features, damage the usability of the app, and hurt our users; therefore, we will no longer submit SourceTree updates to the Mac App Store after March 1st, 2012. New updates will be available, for free, directly from sourcetreeapp.com (and via the in-app update). We will continue to monitor the situation in case Apple improve their sandboxing implementation or revise their rules. Note that we will still be signing SourceTree with our Apple developer certificate so SourceTree should work fine with the default settings of Mac OS X 10.8 Mountain Lion when it’s released.

For the full story of what forced us to take this disappointing decision, keep reading.

Speaking of Radar, we encountered a fairly nasty problem after launching xScope. Many of our customers are designers and developers who love SSDs. It’s common to use a symlink in your Home folder to put big datasets like Pictures, Music and Movies on a separate hard drive. When you do this, folder access in the application sandbox container breaks. A small number of users who use symlinks are also getting crashes after launching the app that was downloaded from the Mac App Store:

xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The file couldn’t be opened.

Next, consider a program like Phone Amego which doesn't download media from untrusted web sites. Its reason for being is to provide Mac to phone integration by working with many other tools. It wants to integrate with Apple's Address Book, Daylite, Contactizer Pro, Launch Bar, Finder, Dropbox, FileMaker, EagleFiler, and be scriptable. Forcing an application like Phone Amego to be sandboxed puts the developer in the awkward position of choosing between dumbing down the application by removing features, or abandoning the Mac App Store version including the thousands of customers who have already paid for the application and expect future updates and support.

Again, I must emphasize that many apps that are already in the store cannot be sandboxed at all, even with entitlements, without severely reducing their functionality. Many more would need to rely on temporary entitlements, which Apple emphasizes are “granted on a short-term basis and will be phased out over time.” And, secondly, there is the fear that Apple will withhold iCloud and other future APIs from apps that are not in the store, effectively making sandboxing mandatory.

The Mac App Store and Sandboxing

The Mac App Store is currently in transition. From March 2012, all new submissions / updates need to be sandboxed.

Sandboxing is a way of protecting users from malicious or naughty software by severely restricting the access an application has to underlying resources. It also makes the app approval process easier for Apple as sandboxed apps simply cannot do things outside their own resources. While this works remarkably well on iOS (I am personally happy to be in the “walled garden” on my phone), it really changes the landscape for OS X applications.

As you know, Alfred isn’t a self-contained application like a game, graphics package or todo list. Many of the things Alfred does are to do with OS X itself… he searches, navigates and opens files and apps on your Mac, he runs AppleScript to interact with other applications, he even allows you to create and run lower-level shell or AppleScript extensions… he is basically your quick interface into the heart of OS X. This is where Alfred starts to throw his toys out of the [sand]box.

The Mac needs to be as secure as the iPhone. The good news is Apple already has the tools. The bad news is they are forcing developers to use the wrong ones.

There are three primary ways Apple increases security of applications running on the Mac and the iPhone: Sandboxing, Code Auditing, and Certification. While all these are incrementally valuable, none is perfect on its own.

The problem Mac developers are facing is that the two that Apple is enforcing on the Mac App Store (Sandboxing and Code Auditing) are implemented currently to be actively bad for developers and not particularly good for users. And the method that would provide the most benefit for developers and users (Certification) isn’t enforced broadly enough to be useful.

Change is coming to the Mac App Store. On Wednesday Apple announced that as of March 1, 2012, all apps submitted to the Mac App Store will have to implement a security system called sandboxing in order to gain approval. The result will be safer apps, but some developers fear that sandboxing may force them to strip out certain features.

Wednesday’s announcement to developers is actually a reprieve: When Apple first unveiled the sandboxing requirement at June’s Worldwide Developer Conference, it was supposed to go into effect this month.

Sandboxing is a security system that regulates the power individual apps can wield on your Mac. More technically, “sandboxing” means limiting an individual application’s access to your computer; rather than allowing it full access to, say, your Mac’s memory or file structure, a sandboxed app is instead confined to its own dedicated space.