Last November, we reported on Apple's plan to require all Mac App Store apps to be sandboxed, a move that would increase security by preventing apps from overstepping their bounds should they be affected by malware but which could hamper the functionality of certain apps. The requirement had been scheduled to go into effect in November but was pushed back to a March 1 implementation date as apparently sought to give developers more time to digest and prepare for the change.
With the implementation date now just a few weeks away, The Wall Street Journal again takes a look at the impact of the changes.
Sandboxing is fairly common in the mobile world, where Apple, Google Inc.'s Android and others have long required it as a safety measure to prevent an app from compromising other parts of the system. But some developers say sandboxing could cripple desktop software, which is often more sophisticated.
Mac developer Mark Munz, of Vancouver, Wash., says to comply with Apple's new rules, he has to remove key features of his text-reformatting app TextSoap that integrate with other programs.
As a workaround, he's working on a "helper app" that Mac App Store users could download separately to restore the extra functionality. "It sort of defeats the purpose of what sandboxing is about," says Mr. Munz, who is president of Unmarked Software LLC.
The report also cites Flexibits co-founder Kent Sutherland, whose Fantastical calendaring app would be subject to sandboxing limitations on its ability to sync and import data from other applications. Apple's position that it will allow access to certain features only on a "temporary" basis leaves developers such as Sutherland uncertain about whether their apps will be able to continue to function in the future.
Apple notes that it is continuing to work with developers to increase the security of their applications under the new sandboxing requirements, with a source noting that "most" apps will not require any changes to meet the new policy. But as we noted in our earlier report, a number of high-profile apps that provide systemwide functionality may have to jump through new hoops to obtain approval for their continued functionality, and developers report that they are still finding bugs in the sandboxing procedures that leave uncertainty about just what is going to happen come March 1.
Top Rated Comments
You don't get it do you..? Sandboxing is currently a half baked idea riddled with bugs that makes it difficult, if not impossible to implement features that a lot of people consider essential to their apps.
Apps I use every day like Transmit from Panic and BBEdit from Barebones can't work to their full extent in a sandbox and are therefore blocked from the Mac App Store.
By way of an example, FTP apps are impossible under the sandboxing rules because apps can't browse the file system arbitrarily.
All kind of apps that need to send mouse movements or mouseclicks to the system are not sandboxable.
All kind of apps that need to control arbitrary applications in some way are not sandboxable.
All kind of apps that need to send keyboard shortcuts (e.g. for pasting text or s.th. like this) are not sandboxable.
Apps that make use of the media keys on the keyboard are not sandboxable (or will lose this functionality)
This list can be continued for quite a while... you see sandboxing will eliminate many applications from the Mac App Store. Especially utilities. Those apps probably won't be pulled from the store, but their old, possibly insecure versions will stay there and the developers won't be able to update them, even if they'd like to. Hundreds of thousands or even millions of users will be affected by this. Also Apple provides no way to migrate App Store customers to non - App Store versions.
Also the licenses only allow the use of iCloud for App Store apps like nuckinfutz said. This creates a real two class system and I think it'll hurt the mac platform...
I refuse to buy MAS applications.
Why?
Because restrictions such as this "sandboxing" that are really just half-assed implementations by Apple hurt applications more then they improve them. You can't seriously tell me with a straight face that I should accept limited and broken applications over their unhindered and free counterparts sold directly from the vendor.
There is NO REASON why Xcode shouldn't come with an "entitlements" editor that allows you to pick and chose what system resources you need and how. This should get baked into the *.app bundle, and when a developer submits an application to Apple, the reviewers can decide if the application really needs what the developer said it does and if not- they can further discuss the issues with the developer prior to approval (for example, there's no reason why a game would need access to everything in ~/, but a search utility might).
Really, there's a thousand different ways Apple could have gone about this. The above is just off the top of my head.
But no, they decide to lock everyone into a strict set of granular choices, most of which are so restricting they're virtually useless. Ring a bell with iOS multitasking anyone?
I'm sure I'll have hoards of people running to Apple's defence here saying that the limited and crippled entitlement system Apple is forcing on everyone is "for your own protection".
The truth here is that there is NO REASON why we can't have a Sandboxing implementation that works well, is secure, and can handle anything developers might need. Except for Apple's own laziness and arrogance regarding their own decisions these days.
-SC
Developers can file bugreports / feature requests but often you just get the answer that the technology you need for your application is theoretically able to workaround the purpose of the sandbox and so they won't allow it....
http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/9#sandboxing