Mac App Store | publicspace.net blog

As many of you know, Apple has decreed that all new Mac App Store submissions must comply with their new requirement for using the Mac OS X Lion “Sandbox”.

This is a security mechanism that restricts what applications can do. By default applications can do almost nothing other than bring up a window and respond to mouse clicks; there’s no access to your files, the internet, etc. This limits the damage that a crashing or virus-infected application can do. If the application, for instance, cannot access the internet or the file system, it can’t steal your data and it can’t transfer it anywhere.

It is then up to the developer to define which “entitlements” their application requires (e.g. I need access to user files, I need to be able to open a web browser on the product homepage, etc.) and up to Apple to grant or reject such entitlements. Obviously the fewer entitlements Apple grants the higher the security.

This is how iPhone and iPad apps have always worked: can’t do much, Apple decides what they can do.

It’s also the exact opposite of how Mac or PC or any other applications have traditionally worked. Mac applications by default have access to everything on your machine and the internet. The only restrictions are based on the file system permissions, so you can’t look at or change the files of another user unless you are a system administrator.

In principle, sandboxing does increase security and that is a good thing.

Unfortunately in practice, Apple have made a dog’s breakfast of both the technical implementation and the policies around the sandboxing.

While it is possible to define “entitlements” to cover almost every aspect of what an application could possibly want to do, Apple have not allowed third party developers access to these entitlements. For many things there are no “third party accessible” entitlements and for many other things, Apple is unlikely to grant those entitlements anyway. The mechanisms that are available do not allow for all existing features of existing applications to be preserved when that application is sandboxed.

I have spent considerable time adopting the Lion sandbox for the Mac App Store versions of my products, as I want to continue to update them in order to bring you the latest (and hopefully greatest) features.

Vitamin-R is the first of these sandboxed versions that I have submitted and now after two rejections it seems that it will finally be accepted.

In order to comply with the Sandboxing rules and Apple’s rejection of my request for several entitlements, the following features had to be removed:

Support for the Neurosky Mindwave headset was removed
The ability to quit applications in the “eliminate distractions” screen was removed.
The ability to automatically close Finder windows in the “eliminate distractions” screen was removed
Growl support was removed

Other changes include:

If you use the Dropbox integration on Mac OS X 10.7.0, 10.7.1 and 10.7.2, you will be prompted to locate your dropbox folder every time you launch the application. (Upgrading to the latest Mac OS X Lion version will fix this).
The download now includes the Noise Machine soundscapes files and is therefore much larger
Many other minor and hopefully invisible changes

I understand that many of you will be upset to lose these features and all I can say is that “it wasn’t my idea”.

When I mentioned that these features had to be removed because of the sandbox requirement in the “What’s new” section of the Vitamin-R Mac App Store page, my “meta-data” was promptly rejected and I was asked to remove any mention of Apple policies.

In other words, I’m not allowed to use Apple’s Mac App Store to inform Mac App Store customers of what is going on, because that would make Apple look bad. Apple prefers its customers to be mad at me for complying with their rules rather than to put up their hand and say “it was us and we’re not sorry because we think we are right”.

Well, I’m gutted about the whole thing.

If accepted in its current form, Vitamin-R will have survived its migration to the sandbox relatively intact. Many of the features that had to be cut were minor and won’t be missed too much by most users.

In any event, if you have bought Vitamin-R on the Mac App Store and you are missing a feature you need, please just contact us at support@publicspace.net and we’ll issue you with an unlock code for the “full” version.

Please don’t vent on the Mac App Store because this penalizes developers for something that they have absolutely no choice about. It also does not allow developers to respond to criticism as they cannot post replies and do not have any idea of who you are and how to contact you to resolve the problem.

Unfortunately, the new Mac App Store sandbox requirement means that henceforward there will be two versions of most Mac applications: a sandboxed one that misses features and a full one that is only available directly from the developer. You can basically choose between greater convenience and greater freedom. Usually it is convenience that wins out.

It is finally happening. Apple have made good on their promise/ threat of requiring all applications on the Mac App Store to adopt the Lion Sandbox technology by June 1st.

You may already have heard many Mac developers moan about this, while others are trying to see the bright side or are at least putting on a brave face. It’s all true and it’s all a lie.

First off, sandboxing does improve security. The idea is that every application that is launched by the operating system works in its own “sandbox”. It can do anything it wants within its sandbox, but when it tries to interact with the rest of your system by accessing files, connecting to the internet, talk to other applications, etc.. it is restricted by its “entitlements”. All this so that even if your application is infected by a virus or is deliberately “naughty” (aka malware), it can only do so much damage.

The kinds of entitlements that exist are defined by Apple and while it is the developers who decide which entitlements they believe their application needs, it is Apple that grants or rejects each entitlement.

The basic equation is this: the less your application is allowed to do, the less damage it can do. So if Apple is serious about the security aspect of the sandbox, it will grant what it deems to be the minimal entitlements required by the application.

Even though it means more work for developers, the sandbox in itself is not a bad idea. Security is good, right?

The rub lies in the fact that unlike iPad and iPhone applications which effectively take over your whole device, most Mac applications live in an eco-system together with other applications. They share files, they interact with other applications and the system to deliver an integrated user experience.

The sandbox gets into the way of all this. Sandboxed applications can only access files on your disk after you have opened them in the “Open…” or “Save…” dialog. They can only interact with other application via AppleScript if they have a specific entitlement for that specific application and that means that Apple has to grant that specific entitlement during the review process. Worse yet, there are no entitlements for a whole range of things that a powerful app could potentially want to do.

For many applications, this will mean that existing application features that have existed for a long time will need to be removed in order to comply with Sandboxing rules.

I have finished sandboxing Vitamin-R and I have managed to keep most of its features alive and well.

Some features, however, did not make the cut. So I have removed the following features from the Mac App Store version of Vitamin-R:

the ability to quit other applications from the “Eliminate Distractions” screen
the integration with NeuroSky’s MindWave brain computer interface

(There are entitlements for either of these things).

Other features require “temporary entitlements” that Apple may or may not grant.

The features “at risk” are:

Things integration
Things beta integration (new if accepted)
OmniFocus integration
Growl integration
The Hit List Integration

There is no rational reason for doubting that Apple will grant these entitlements, but the MAS review process is notoriously capricious. The term “temporary” also does not fill one with great confidence, so these features may well disappear somewhere down the line even if accepted now.

I will be submitting Vitamin-R 1.81 to the Mac App Store as soon as version 1.80 is released next week and if everything goes smoothly and Apple isn’t backlogged, it should be available within a fortnight.

On a personal note: I do not want to remove a single feature from any of my applications. Apple is forcing my hand and I’m doing what I can to preserve functionality. The versions of my software distributed via my own website will remain outside of the sandbox and thus unaffected.

I’m also looking into ways of allowing users who have purchased via the Mac App Store to download and use the “full” version of Vitamin-R from my website for free. This is made more difficult by the fact that Apple does not share customer data with third party developers and I thus have no idea of who buys my software on the Mac App Store.

I hope to have a simple solution ready sometime in June, but this again depends on whether the Mac App Store review team accept the solution.

If you are upset about losing features, the best idea is to let Apple know about it. We developers have already done all we can. There’s a “Support” link in the “Quick Links” section of the Mac App Store front page and of course there are Apple Stores all over the world.