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.
Gus Mueller of Flying Meat Software compares it to the playground sandbox from which the computing concept takes its name. “We were handed a couple of toys, and if we wanted out of the box, or wanted to [use] something not given to us by our parents, then that’s too bad,” he told Macworld.
That ensures an application “does only what the user allows and expects it to do in response to the user’s wishes, and no more,” Rich Siegel of Bare Bones Software explained via email. Requiring apps to employ sandboxing ensures that those apps can’t act too maliciously. If an app can’t get at other data on your Mac, it’s much harder for that app to perform evil tasks without your permission.
When developers submit apps that adhere to Apple’s sandboxing restrictions, they can request specific “entitlements” for their apps, like read/write access to the user’s Music, Downloads, or Pictures folders, interaction with USB devices, printing, access to the built-in microphone, and others. Unlike other platforms (including Windows and Android), which display a list of features that apps will be able to access and ask for a user’s approval, Apple will determine whether an app should be granted the entitlements the developer requests as part of the Mac App Store approval process.
You already encounter sandboxing on a daily basis—if you use an iPhone, iPad, or iPod touch. iOS apps can’t see other apps’ documents, can’t adjust your device’s settings, and essentially can control only themselves. It’s an approach Apple wants to bring to the Mac App Store side of things.
Apple’s sandboxing rule, as currently outlined, affects only new apps and updates to existing apps submitted on or after March 1 of next year. But that puts some developers in a tough spot. Some will have to make changes to their apps in order to continue offering existing features. Others fear that some features may simply not be allowed in the sandbox and might have to be removed entirely.
Take Alfred developer Andrew Pepperrell, who wrote on his blog about how he’s hesitant to release a version of Alfred Powerpack to the Mac App Store that complies with the current rules (the ones that do not mandate sandboxing). Were he to do so, come March, any subsequent updates to the app would necessitate stripping out various features that customers would have already paid for.
Pepperrell rightly points out that customers still have a choice; you can buy his app outside the Mac App Store and avoid the sandboxing question completely.
Mueller’s key concern is simple: Customers will be surprised and confused if their Mac App Store purchases get updates that remove prior functionality to comply with sandboxing rules. “And they are going to be mad at developers, not Apple,” he added.
Mueller said that he’s hasn’t “completely decided” just what he’ll do with his apps once the March 1 deadline rolls around, though he added, “I’ll probably offer less-restricted versions outside the App Store.”
Bare Bones’s Siegel faces a similar problem: “Our products will need to change in order to comply with the sandboxing rules,” he wrote. He pointed out a slew of features in BBEdit that may not be allowed once the sandboxing restrictions are in place—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. “Customers are expecting all of this to work, even in a sandboxed environment, so there are some real challenges there,” Siegel said. An open question is which of those features will be allowed by Apple (but with extra work required on Bare Bones’s part) and which will simply not fit within Apple’s vision of what an application should be allowed to do.
What’s more, for many developers, “not selling through the Mac App Store… isn’t really an answer at all,” according to Siegel. “Unless you’re willing to walk away from a majority of your audience. And no sane businessperson would do such a thing.”
The Many Tricks team—Peter Maurer and former Macworld senior editor Rob Griffiths—is also concerned. “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,” the developers said in an email interview. “In fact, these entitlements may never exist, as Apple appears to be in the process of redefining the fundamental concept of what third-party software is supposed to be capable of doing on the Mac.” Many Tricks says that several of its apps—Moom, Witch, and Time Sink—“rely on the Accessibility API and inter-application communication to do what they do, and these features will not be available to us” unless Apple modifies its restrictions. Right now, the developers expect they’ll need to pull all three apps from the store and rely on selling from their website instead.
The Many Tricks developers point out that many current Mac App Store apps—including apps that control iTunes playback, apps that use AppleScript to send commands to other apps, and apps that capture keystrokes for text expansion—simply can’t comply with the sandboxing rules as currently stated. “In short, there are a slew of useful utilities that, if things don’t change, won’t exist in the sandboxed world of the future,” they told Macworld.
How much work is sandboxing for developers?
Apple told developers that turning on “the default sandbox environment is as simple as checking [the right] checkbox” when they code their apps.
Enabling sandboxing is certainly that simple, Siegel said. “However, whether an application still works after sandboxing entitlements have been enabled is another matter entirely. The more broadly scoped and deeply functional a product is, the more engineering and testing are going to be required for it to function correctly when sandboxing entitlements are enforced.
Mueller questions Apple’s timing for introducing the sandboxing restriction. “It’s being introduced in the middle of an OS cycle,” he wrote. “I could see Apple turning it on with the release of 10.8, but forcing the sandbox on developers with a 10.7.x update? That’s crazy.”
Marco Tabini, an occasional Macworld contributor and the developer of Mac App Store apps like Tunesque, notes that while respecting the sandboxing rules will likely be simpler for smaller apps, apps “aimed at power users are going to have a harder time, because [they] often interface with the operating system at a very deep level, and sandboxing makes that very difficult, or outright impossible.”
Will sandboxing make us safer?
Apple suggests that the sandboxing restriction will keep Macs safer.
The Many Tricks developers concede that’s true—with a caveat: 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.”
Beyond the obvious tradeoff of potentially limiting some apps’ functionality, sandboxing really only makes you safer if you exclusively run Mac App Store apps. As Tabini explains, “If you download or acquire software from other sources, sandboxing is still optional… Since the majority of malware comes from untrusted sources, in the short term sandboxing is probably not going to make a huge difference.”
Mueller agrees: “People are still going to download apps off the Internet,” he wrote. “The only way to keep folks even remotely safe from malware is to only allow applications that Apple allows you to run,” he added. That’s precisely how iOS works; you can only install apps from the App Store, unless you jailbreak your device.
Mueller predicts that one day Apple may employ the same restrictions on the Mac—that you’ll only be able to install apps from the Mac App Store. “Why wouldn’t they? What’s the downside [to Apple]?” he wrote.
What’s Apple’s goal?
While many of the developers we spoke to are understandably concerned, it’s clear that many apps, across many categories, will be minimally affected by the sandboxing policy change. And there’s considerable evidence that Apple’s working to figure sandboxing out in way that works for as many developers as possible:
First, there’s the delay on implementing the rule change from by an additional four months, from November to March—which gives developers more time to understand the rules and comply, and gives Apple more time to listen to developers and adapt the rules accordingly. Apple’s developer website includes a section devoted to sandboxing, and a prominent feedback form on the page is labeled: “Your feedback is valuable, and helps inform the direction of our sandbox API development.”
What minimal public comments Apple employees have made are similarly promising. Apple engineer for core OS security Ivan Krsti? continues to engage with developers via Twitter, encouraging them to file bugs with Apple if they are worried about sandboxing’s impact on their apps. Krsti? assured one developer that “We understand the need for your use case”; he told another that filing bugs is necessary because it will “give us feedback that we can turn into fixes.”
On three major platforms—the Mac, the iPhone, and the iPad—Apple clearly owes a portion of its tremendous success to its developers. “There’s an app for that” exists only because of the successful developer ecosystem Apple created for iOS; that many iOS developers are embracing the Mac App Store is a wonderful thing for Apple. One hopes that the developers who spoke with Macworld and the security engineers at Apple can work together to come up with smart, secure solutions that keep the apps we love as feature-packed as they already are.