The Sandboxing Disaster Continued
Posted on:February 22 2012
I just wanted to take another shot to start implementing the sandboxing feature required for Mac OS X Apps on the Mac App Store starting with March 1. Sandboxing basically means that your application is prevented to access files on the hard disk, communicate with other apps, access the Internet and similar, if the user didn't grant the application access manually (by for example choosing the file the app wants to access using a file dialog). This sounds great at first, but unfortunately, the way Apple implemented this absolutely sucks. Sandboxed apps are for example no longer able to open files typed in by hand, or files referenced by other files, which is for example usual in HTML files, or any 3D model file in the case of my apps. Meaning my applications simply won't work anymore as the user expects them to.
Apple received a lot of criticism for this, but didn't really answer to the complaints. In reaction to this, I simply didn't update my apps at all to support this absurdity, it would not make sense to provide users with a crippled version of my software just because Apple made some weired decision.
Today, 8 days before the sandbox deadline kicks in, I received a mail from Apple, stating that the Sandboxing Deadline is now extended to June 1. This is the second extension of that deadline, which was originally set to November 1st, 2011. Nice. What does that mean? I guess Apple received too much criticism. But I also guess that other developers also did what I did: Simply not implementing that broken sandboxing feature. Apple probably noticed that not many developers implemented it and now is forced to do this. Very nice.
Digging a bit deeper, they also added a notice that non-sandboxed apps submitted to the App store before that deadline may continue to be updated, non-sandboxed.
Which is a big change for me and the users of my Apps. This basically means that all users of WebsitePainter and CopperCube who bought that software on the Mac App Store do not have to fear that they will receive an update to that software which will cripple it so that it is no longer usable. I'm not sure if this also means that Apple will also allow updates with new features to these versions. But for now, this is great news.
Who knows, maybe Apple will will also someday remove that ridiculous Sandbox option at all. They now introduced that Gatekeeper thing now anyway.
Apple received a lot of criticism for this, but didn't really answer to the complaints. In reaction to this, I simply didn't update my apps at all to support this absurdity, it would not make sense to provide users with a crippled version of my software just because Apple made some weired decision.
Today, 8 days before the sandbox deadline kicks in, I received a mail from Apple, stating that the Sandboxing Deadline is now extended to June 1. This is the second extension of that deadline, which was originally set to November 1st, 2011. Nice. What does that mean? I guess Apple received too much criticism. But I also guess that other developers also did what I did: Simply not implementing that broken sandboxing feature. Apple probably noticed that not many developers implemented it and now is forced to do this. Very nice.
Digging a bit deeper, they also added a notice that non-sandboxed apps submitted to the App store before that deadline may continue to be updated, non-sandboxed.
Which is a big change for me and the users of my Apps. This basically means that all users of WebsitePainter and CopperCube who bought that software on the Mac App Store do not have to fear that they will receive an update to that software which will cripple it so that it is no longer usable. I'm not sure if this also means that Apple will also allow updates with new features to these versions. But for now, this is great news.
Who knows, maybe Apple will will also someday remove that ridiculous Sandbox option at all. They now introduced that Gatekeeper thing now anyway.
Comments:
how will steve answer to this non-sense? security over user-experience?
ron
Quote2012-02-22 09:21:00
he's likely going to turn about 90 degrees.
xaos
Quote2012-02-22 13:37:00
Nikolaus, seems like a better approach might be for Apple to allow users to give permission for an app to read/write a directory (and all subdirectories). Would that work for CopperCube?
Steven Shaw
Quote2012-02-23 22:57:00
Yes, but it wouldn't be very user friendly. If you want to import for example a .3ds file referencing a few textures on the disk, you as user want to select the .3ds file, not additionally the directory, right?
niko
Quote2012-02-24 07:53:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |