Mac App Store's sandboxing requirement kicks in, frustrating developers

The new requirement limits the features that developers can implement even as it makes applications more secure

Depending on whom you ask, Friday, June 1 was 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, which compartmentalizes what data and features a specific app is granted access to. Apps each can metaphorically play exclusively in their own sandbox, accessing only the data that 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. That day has come; we've finally entered the sandboxed era.

[ For tips and tools for managing an enterprise Mac fleet, download InfoWorld's free "Business Mac" Deep Dive PDF special report today. | Discover what's new in business applications with InfoWorld's Technology: Applications newsletter. ]

The plus side of sandboxing is that it means, in theory, that 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.

Although 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 that anything has changed as they start installing sandboxed apps from the Mac App Store. For many niche apps that don't need access to any extras (think games and to-do list managers), 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: multifile 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 tool operations (such as syntax check and site update), and lots of behind-the-scenes stuff such as scanning directories for ctags data. Back then, Siegel said he 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."

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 use 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 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 on 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 that "Apple's new Gatekeeper [the OS X Mountain Lion feature that prevents unsigned apps from running] 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 Mac App Store, 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."

This story, "Mac App Store's sandboxing requirement kicks in, frustrating developers" was originally published by Macworld.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies