Chris Foresman:
Sandboxing is designed to prevent apps from doing things that users do not intend—e.g., an exploited app taking over the network and being used for a denial-of-service attack. “Where this runs into trouble, though, is the case of ‘implicit user intent,’ in which there are things that the user does want to do, but they didn’t directly request action,” Siegel explained. Bare Bones’ BBEdit editor, if sandboxed, would not be able to do a multifile search and replace, show live folder views of complete programming projects, or integrate with version control systems.
[…]
The problem, as many see it, is that developers will either be forced to remove functionality that users have come to rely on or simply not sell their software via the Mac App Store. “The choice that you’re given, as a developer, is a Hobson’s choice,” Siegel said. “The answer seems to be not selling through the Mac App Store, which really isn’t an answer at all, because not being in the Mac App Store is not an option unless you’re willing to walk away from a majority of your audience. And no sane businessperson would do such a thing.”
Here’s a simple way to look at it: if BBEdit and Transmit, two of the most popular and respected Mac apps, can’t work with the sandbox, the problem doesn’t lie with the apps.
I disagree, however, with Jonathan Zdziarski’s points at the end of the article. I think the sandbox is basically a good idea, but with an incomplete design/implementation and very poor policy and communication. Apple’s Ivan Krstić seems to be listening, but I’m sure he already heard plenty at WWDC, no changes are in evidence, and he’s unable to talk specifics.
Mac Sandboxing
Pauli Olavi Ojala (via Peter Maurer):
It’s important to note that these entitlements are granted by Apple, not by the user herself. App developers must provide justification for their entitlement requests when submitting an app to the App Store. If the Apple curator thinks that your app is not deserving of accessing the Pictures folder or interacting with USB devices, she has every right to turn down your request without additional justifications. (We’ve seen many Beckettian variations of this scenario played out on the iOS App Store over the past years.)
[…]
One side-effect of the sandbox model which makes me particularly sad and nostalgic is that it kills the notion of plugins. This will also affect many of Apple’s own pro apps on the App Store.
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.
Apple waited until the night of November 2 to state that the November deadline had been changed to March, and nothing of substance has changed. The policies still haven’t been clarified. The bugs and limitations still haven’t been fixed. There has been no indication of when or if they will be. At this point, the best-case scenario is that Mac OS X 10.7.3 is seeded to developers soon, ships sometime between now and March, and fixes the problems. Then developers could potentially build apps that work on Snow Leopard and 10.7.3+, but they wouldn’t work (or would crash or misbehave) on 10.7 through 10.7.2. There’s not a lot of time between now and then, especially considering the upcoming holiday season.
Mac Mac App Store Mac OS X 10.7 Lion Sandboxing
Nick Bradbury:
I wrote the first version of HomeSite back in 1994, and seventeen years later I can still run it on the latest version of Windows.
I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I’ve relied on.
