It’s now been over a month since Apple began enforcing its sandboxing policies for the Mac App Store. With the dust beginning to settle, what can we conclude?
We certainly can say that the “chicken littles” among the prognosticators have not been vindicated. At least not so far. I haven’t seen hordes of Mac users, pitchforks in hand, storming the gates of Cupertino, demanding that Apple release third-party software from its shackles. In fact, I haven’t seen much in the way of user complaints at all.
On the other hand, there are numerous instances of developers struggling to meet the newly imposed requirements. And there are valuable app features being lost in the shuffle. Here are a few examples:
• BareBones is currently unable to offer iCloud support in Yojimbo. This is especially a problem for people who had been syncing Yojimbo via the now-shut-off MobileMe. Even when BareBones comes up with a solution (and they will), it will require that users who had been using the stand-alone version of Yojimbo purchase a new version from the Mac App Store. This will impose an unintended payment penalty to the existing users — because the Mac App Store does not support separate prices for new and upgrade purchases. BareBones has plans for a way around this, but it won’t be pretty. [Note: This is not directly a sandbox issue, but is related as it requires that the app move to the App Store and thus meet sandboxing restrictions.]
• The Mac App Store versions of BareBones’ TextWrangler and BBEdit lose features. In order to comply with Apple’s submission guidelines, BareBones had to remove the “authenticated save” option (the ability to save changes to files that you do not own) and command-line tools from the Mac App Store versions of these text-editing apps. Personally, the “authenticated save” option has saved my bacon on several occasions; I would miss not having it.
• Rogue Amoeba states that “Apple’s restrictions prevent most of our software from being sold in their Mac App Store.” Piezo is the lone exception.
• Smile announced last month that the new version 4 of its popular TextExpander will not be available from the Mac App Store because it cannot comply with Apple’s sandboxing requirements.
• In order to qualify for admission to the Mac App Store and avoid sandboxing prohibitions, all anti-virus software will have to eliminate their important automatic scanning features.
• The developer of SourceTree announced that sandboxing “will disallow important SourceTree functionality that was previously acceptable under store rules.” As a result, the Mac App Store version of their software will no longer be updated.
• The developer of Alfred explains the unwelcome compromises he had to make in order for his app to be permitted in the Mac App Store.
• The developer of MarsEdit explains the difficulties he faced allowing existing Mac App Store customers to access beta versions of his software. This is more of a general Mac App Store policy issue than a sandboxing one, but it’s close enough that I’m including it here.
• Topher Kessler, writing for my old MacFixIt site, more generally warns that, with sandboxing enforced, developers are likely to lose “the ability to schedule tasks using the system’s launch daemons, or build programs that piggy-back on others. Some such programs include the popular Evernote citation manager for various word-processing suites, or the MoneyWorks financial reporting features that the program appends to Excel or Numbers.”
Jonathan Rentzsch, writing for Macworld, assessed the pros and cons of sandboxing and concluded that the balance of the scales have clearly tipped in one direction: “The bottom line is that sandboxing has effectively collapsed the ambiguity and customers should now purchase their apps directly instead of through the Mac App Store.” That assumes that such a choice exists for a particular app.
I found all of these examples within a few minutes of searching the web. I’m sure there are more.
Point and counterpoint
Not everyone shares the just cited viewpoints. At the opposite end of the spectrum, John Welch (writing here at TMO) argues that all of these worries about sandboxing amount to (and I’m paraphrasing here a bit) whining by people too ignorant to understand what sandboxing is all about: critical security enhancements. Further, while admitting that sandboxing blocks some apps from the Mac App Store, he dismisses this issue because, by his measure, it only affects a very few apps. And even in cases where apps are blocked, users can easily get the software from outside the App Store.
Based on the list of apps I cited above, I believe the number of apps affected by the new policies is significant. In any case, one must consider both the quantity and significance of the affected apps. Even if only five apps were affected, this could be a big deal if those were five of a user’s most frequently accessed mission-critical apps and features. The jury is still out on this. It remains to be seen how much of a big deal rejected apps turns out to be.
As for the alternative of buying software outside of the Mac App Store, this presents at least two problems.
First, I believe such alternatives will decrease over time — as financial concerns increasingly persuade developers (especially smaller ones) to focus only on App Store versions (although if the Bodega App Store becomes a success, this could change the dynamics). Rich Mogull, writing for TidBITS, after acknowledging the clear security benefits to Apple’s policies, similarly cautioned: “Is there a downside to mandating sandboxing? Absolutely…Some apps will never be able to be sold in the Mac App Store. This is a problem since, as more users go to the Mac App Store for their apps, it may become economically difficult for those developers to reach a large enough audience.”
In fact, the concerns regarding current software may turn out to be just the proverbial tip of the iceberg. A larger issue, largely hidden from view, are useful features that may never show up in future software — due to developers tailoring their software to meet Mac App Store acceptance (a matter I covered more in a previous column).
Andy Ihnatko made a similar point when he compared the “App Store vs. externally-sold apps” situation to cable vs. network television shows. Network shows are constrained by numerous regulations in order to qualify for network airing. Cable shows, especially those on premium channels such as HBO, have no such restrictions. By most criteria, the result has been that most of the best shows on television are on premium channels. Andy concludes: “Under the new rules, there’s the risk that Mac software might occasionally be as good as ‘The West Wing’ but it could never be as great as ‘Boardwalk Empire.’ [For the time being], there will be some very real limitations on how good a Mac app can be.”
Second, I expect non-App-Store apps will increasingly be unable to access an assortment of desirable OS X features. This is happening already with apps and iCloud: Apple bars apps sold outside the App Store from syncing data to iCloud. This includes the Documents in the Cloud feature coming in Mountain Lion.
Security
Finally, what about the security advantages of sandboxing? These advantages have been effectively summarized both by Rich Mogull and John Welch. Mr. Welch concluded that “sandboxing is an important part of overall improved security. [It] is something that protects people who don’t know how this stuff works or why.”
I agree. However, I also believe that there can be too much security, especially for people who do know how stuff works. Otherwise, borrowing a phrase from Mr. Mogull’s article, you can wind up sacrificing too much usability in exchange for security.
Can there really be such a thing as “too much” security? Yes. As an analogy, imagine that a public library wanted to reduce its number of lost, stolen and damaged books. To do so, they institute a new set of security procedures. These include metal detectors, background checks, and retinal scans (to confirm your identity each time you want to borrow an item).
Does all of this succeed in reducing theft and damage? Absolutely. But is it worth the cost? My guess would be no. Patrons would rebel at such intrusions; they would rather accept a greater security risk.
The library analogy is not perfect. For one thing, the library’s checks are more onerous than sandboxing on a Mac. However, in the library example, the city is attempting to protect property it owns — as a benefit to the entire community. With sandboxing, Apple is attempting to limit features of the software you install on your Mac for your own personal use. To me, that gives Apple less latitude (although I am well aware that this is a hotly-contested debate).
It would be great if Apple could find a way to allow “advanced” users to optionally bypass sandboxing restrictions, such as via expanded Gatekeeper settings. However, this might wind up trading one set of problems (too much security) for another (too little security). In any case, as Apple has shown zero inclination to do anything like this on iOS devices, I doubt they have any plans in this direction for the Mac. So I’m not going to waste my time contemplating this possibility.
In the end, my best hope is that things will improve over time — as everyone adjusts to the new world order. After seeing how things work, and after assessing developer feedback, Apple may relax some if its policies. At the other end, developers may find better ways to maintain their apps’ features and still live within sandboxing’s constraints. Where no middle ground can be found, users will be content with the minor sacrifices that result. A year or two from now, we may look back and wonder why we ever made such a fuss about this in the first place. That’s my best hope. I should warn you, however, that my best hopes are rarely realized.