With a notice posted on the Mac Dev Center’s App Sandboxing webpage, Apple has informed developers that the sandboxing deadline, previously delayed to March 1, has been extended to June 1.

Starting June 1, all apps submitted to the Mac App Store must implement sandboxing. Take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

We have extended the deadline for sandboxing your apps on the Mac App Store from March 1st to June 1st to provide you with enough time to take advantage of new sandboxing entitlements available in OS X 10.7.3 and new APIs in Xcode 4.3.

Starting June 1, if you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates without sandboxing your app. In addition, if you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra – utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) – couldn’t get past the sandboxing requirement for the Mac App Store.

Since the release of Lion last summer, Apple has been touting the advantages of sandboxing as a way to increase security on OS X, whilst third-party developers began asking for more clarity from Apple in regards to the list of entitlements made available to them. For instance, sandboxing has been heavily criticized in the past months as it would theoretically prevent apps that rely on system-level technologies such as AppleScript from working, as they would require an entitlement that Apple isn’t providing. Similarly, apps that would require access to an entire user’s filesystem would be problematic with sandboxing fully enforced (think backup utilities such as SuperDuper).

Sandboxing recently became a topic of discussion again as Apple announced the next version of OS X, Mountain Lion, featuring a new security measure called Gatekeeper, while claiming that sandboxing would still be enforced starting March 1. With Gatekeeper and Sandboxing seemingly aimed at fixing different problems with OS X security, a number of third-party developers asked Apple (again) to reconsider the list of entitlements for the sandbox and figure out a way to work with longtime Mac developers to keep their apps in the Mac App Store.

Notably, Daniel Jalkut of Red Sweater Software wrote:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out. Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished. Apple can turn that around so that sandboxing is a worthy counterpart to Gatekeeper, and a technology that any developer in his or her right mind would feel foolish not to incorporate.

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps.

As a result of the uncertainty surrounding the sandboxing deadline prior to today’s announcement, some developers have decided to stop supporting the Mac App Store, keeping their applications available for purchase on their website – something that Mountain Lion will continue to support thanks to Gatekeeper. A notable example is Riverfold’s Manton Reece, who wrote a blog post explaining the reasons behind his decision to remove Clipstart from the Mac App Store:

Clipstart also falls into the same “needs to access the whole file system” category as Transmit. It’s not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don’t see a clear path forward for existing customers to move into such a restrictive environment.

Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.

Following today’s notice sent to developers, Reece told us: “The delay is great news for developers who have been scrambling to meet the deadline. With brand new sandboxing APIs in 10.7.3, it just wasn’t realistic to expect developers to be ready. And for some apps, there are still areas where the current entitlements fall short.” As for Clipstart, Reece says he’s still planning to remove his app from Apple’s storefront: “I still expect to transition away from the Mac App Store. These delays show that Apple is listening, but also that sandboxing isn’t a stable environment yet. I want to focus my time on adding new features for users instead.”

With Apple extending the Sandboxing deadline, the company will hopefully have time to come up with a broader selection of entitlements developers can use in their apps. As a side note, Apple is expected to hold its annual WWDC in June, and Mountain Lion is set to become available this summer on the Mac App Store. Apple seems to be very flexible with the new June 1 deadline, too, promising developers that they will be able to submit bug fixes without implementing sandboxing, and asking them to “get in touch” if technical issues are preventing them from implementing the new technology.