The case of the evolving sandbox guidelines 

Speaking of the sandbox guidelines, many developers are frustrated by the way Apple has kept changing the guidelines for sandboxing.

Keith Blout from Literature & Latte told us: “One technical challenge is that because sandboxing has been consistently evolving over the past few months, it works differently on different versions of Lion. For that reason, our sandboxed App Store version will only be able to run properly on versions of Lion from 10.7.3 and above (it will still run on Snow Leopard, which will ignore sandboxing, but not 10.7.0 - 10.7.2). This is because earlier versions of Lion were missing several entitlements and features in sandboxing that are crucial to Scrivener's usability.”

Blout suggested that it would have been wise for Apple to “drop sandboxing from Lion altogether and only start enforcing it, fully formed, in 10.8”. Apple has already moved the deadline for Sandboxing back, initially the transition was supposed to happen in March.

Rozen also noted the moving deadline: “Apple has pushed sandboxing enforcement deadline several times - so they understand that this feature was not implemented well enough. They mean business this time, but there hasn't been significant changes in Sandboxing since its announcement - so it looks like Apple is just trying to force the issue, without real attempt to solve the problem, which is unfortunate.”

Blout outlined the following issues with the process: “There are still certain things that are up in the air - there are several entitlements that are labelled by Apple as ‘temporary’, and developers currently have no idea whether these will one day be revoked or not. We don't know what the future for some features will be until Apple clarifies what this means. Are ‘temporary entitlements’ temporary in that they are there to give developers time to find some other way of doing these things (in which case we have no control over the integration requirements of third party products), or are they temporary in that Apple is looking for a better way of properly sandboxing difficult features such as Apple Events?”

However, Blout admitted: “Fortunately, Apple seems to have worked hard over the past few months to iron out many of the issues with sandboxing.”

One developer, who asked to remain anonymous, was less forgiving: “Sandboxing is a mess. Apple's approach to it was to disallow everything and then figure out what doesn't work anymore. I have no problem with how they do things internally, I couldn't care less. The problem is that they force us (all developers) to be their testers. Therefore, they simply make changes without even thinking about the implications and then they wait for bug reports from us. My approach to sandboxing is to refuse to be Apple's beta tester. My idea of development does not include writing bug reports to Apple to help them do their job.”

He added: “A check of the Apple developer forums shows issues even with simple stuff like opening the standard Open/Save panel. Furthermore, they fixed and tuned sandboxing incrementally. So, sandboxing in 10.7.3 is different from 10.7.4, and sandboxing and some things that work in 10.7.4, do no longer work in Mountain Lion. They have no idea what they're doing.”

Another developer, who wished to remain anonymous told us: “Sandboxing is a lot of work and most seasoned developers realize that there's little security benefit. The API is buggy, badly documented and incomplete.”

Page 1: Confusion and concerns And why isn’t Apple listening?
Page 2: What is sandboxing? And will it work? 
Page 3: Is there really a Mac security threat? And will Sandboxing remove it?
Page 4: The case of the evolving sandbox guidelines And how Apple needs to get its act together