Depending upon whom you ask, Friday, June 1 is the best or worst thing to come to the Mac App Store since it opened its doors in 2011. As of now, new and significantly updated apps submitted to Apple’s Mac App Store must implement sandboxing.
As a quick review: Sandboxing refers to compartmentalizing what data and features a specific app is granted access to; apps each can metaphorically play exclusively in their own sandbox, accessing only that data which Apple has granted that app entitlements to see.
Originally, Apple told Mac App Store developers that their apps would need to implement sandboxing by November 2011. In November, that deadline was extended to March 2012; in February, Apple extended that deadline again until June 1. And as iCal will tell you, that day has come; we’ve finally entered the sandboxed era.
The plus side of sandboxing is that it means, in theory, that your apps will become safer and more trustworthy: Your Mac prevents them from accessing files they shouldn’t access. But that security comes with a price, at least in some cases. Some developers say that sandboxing will force them to remove features from their apps—or, in some cases, to pull them from the Mac App Store entirely. For example, the sandbox generally prohibits actions like simulating key presses (like a typing expander tool might perform) or accessing root-level privileges (like executing certain command line scripts).
Apple’s view
It’s easy to see why the sandboxing requirement makes sense from Apple’s perspective: For one thing, it’s worked great on the iOS App Store. From day one, apps for the iPhone (and later iPad) were sharply limited as to what features and data they could access on those devices, and the result has been an impressive track record for iOS security.
While there was that address book kerfuffle and an occasional WebKit security exploit that needed patching, those were the security exceptions that proved the need for tight sandboxing requirements. Clamping down on what data apps could access from the get-go ensured that iOS would remain far less vulnerable to security threats than Android.
Clamping down on the data that Mac App Store apps can access empowers Apple to assure its customers that the third-party software they install is safe and won’t compromise their Macs. And Apple certainly wants to reassure its users that Macs are supremely safe, especially after the disappointing blemish left by the Flashback Trojan horse. If Apple sees its alternative as waiting for the day a rogue Mac App Store title maliciously starts abusing user data, the sandboxing requirement seems like a no-brainer.
User and developer outlook
Apple hopes—and likely expects—that most Mac App Store customers won’t notice anything has changed as they start installing sandboxed apps from the store. For many niche or narrowly-focused apps that don’t need access to any extras (think games, todo list managers, and the like), that should indeed be the case; sandboxing those apps shouldn’t have any tangible impact on the user experience.
But in other cases, developers may be forced to sacrifice features large and small to comply with Apple’s security requirements. Flying Meat Software’s popular image editor Acorn, for example, offers a clever shortcut for power users: When saving an image, merely changing the filename’s extension automatically tells the app to adjust what format you’re saving the file in. The sandboxed Mac App Store version of the app won’t support that feature, Flying Meat’s Gus Mueller told Macworld, because—he believes—of under-the-hood changes related to how Save dialog boxes work within the sandbox. Mueller stressed that he’s not certain precisely why the feature doesn’t work in the sandboxed version of Acorn, but he’s been devoting his time to figuring out other, more pressing sandboxing issues, like getting the app’s AppleScripts to work.
On the plus side, while Mueller had feared last November that Apple’s sandboxing approach would break other Acorn features, like plug-in and screenshot support, “it looks like Apple built in some smarts that look for user intent with regards to” features like those.
Rich Siegel of Bare Bones Software spoke to Macworld about his concerns regarding sandboxing Last November too, rattling off a long list of features in the company’s popular text editor BBEdit that he feared might not be allowed going forward: multi-file search and replace; text factory applications; multi-application automation using AppleScript or Automator; Open File by Name; disk browsers; live folder views in projects; SCM integration; bulk HTML tools operations (syntax check, site update); and lots of behind-the-scenes stuff such as scanning directories for ctags data. Back then, Siegel said he literally wasn’t sure which features BBEdit would be able to continue to support once sandboxed. And now that sandboxing is here, Siegel still isn’t sure:
“The question really remains wide open,” he wrote in an email to Macworld. “With a technology like sandboxing, any feature changes are dictated by the underlying system; so we can’t really know whether a given feature or behavior is going to work until we test it in the sandboxed environment.” While Bare Bones knows that BBEdit features like its Unix command line tools and privilege escalation when saving over root-owned files will never work in the sandbox, “there’s a lot of testing to do” with other features in the software. And, of course, once Bare Bones identifies issues that don’t work, Siegel says, “we have to decide whether to neuter the feature entirely, or agitate with Apple for changes to the system to enable it to work.” He concludes: “In the end, though, only time will tell what the final sandboxed product looks like.”
Also back in November, Rob Griffiths—a former Macworld senior editor and now part of Many Tricks—expressed concern that several of the company’s apps ( Moom, Witch, and Time Sink) would simply need to get pulled from the Mac App Store entirely once the sandboxing deadline arrived. All three of those apps leverage something called the Accessibility APIs, which lets them simulate various user interactions to work their magic.
Griffiths confirmed to Macworld that indeed, Apple has offered no new entitlements for developers to to use the Accessibility APIs in a sandboxed environment. That means Many Tricks can’t release any new features to those apps in the Mac App Store, only bug fixes. For major new releases, Many Tricks will return to relying upon direct sales from its website instead.
For some developers, making their apps conform with the Mac App Store’s sandboxing requirements would simply hamper their software too much. The developers of the popular keyboard launcher Alfred posted on their blog Friday that “Apple’s new Gatekeeper paves the way for us to keep Alfred as productive as possible without having to work within the limitations of a sandbox.” The company adds further: “You’ll continue to find the free version of Alfred in the MAS, as Apple allows existing apps to remain in the store and receive bug fixes. However, if you’re looking for the big juicy new features, your best bet is to download Alfred from our website.”
Looking ahead
Some fear that our brave new sandboxed Mac App Store world might erode the Mac’s identity. It will certainly, in both the short and long terms, make life harder for developers as they continue to improve upon their apps, while simultaneously explaining to novice users why certain features go missing.
Surely, the sandboxing rule isn’t one Apple set lightly or uninformed. That the company postponed the compliance deadline multiple times suggests that it remains aware of the concerns developers have, and that the company’s goal isn’t to leave customers worse off.
For now, then, most users will need to take a wait and see approach. If certain Mac App Store software you own gets updated with features you rely upon removed, talk to the developer—and ideally talk to Apple too. Remember that the iPhone launched with no App Store at all, but user and developer interest spawned Apple to make what turned out to be one of its best business decisions ever in opening the platform up to third parties. If sandboxing truly hampers the Mac experience for the average Mac user, Apple will adjust how it works.
In the meantime, though, developers do have an out—of sorts. Falling back to direct website sales means forfeiting the exposure that the Mac App Store offers. But Mac developers made that work for decades before the Mac App Store existed, and odds are good that they can make it work again.