App Store Entitlements, and the Crippling of an App

By · Published · apple, objective-c, xcode, mac, osx

A few months ago, I decided I wanted to try exploring the Mac App Store ecosystem as a developer. I've been writing little Objective-C apps for myself for awhile, and I decided I wanted to see what it was like from the other side.

So I wrote this little app called Airplane Setting. It was a stupid simple little app that made it easy to turn off your radios with a single action. I wrote the app and paid my $99 admission fee. And after a month of back and fourth with Apple and a couple of rejections for what I consider to be dubious reasons as best (especially seeing as how I could point out existing apps in the store that broke the "rule" they said my app was breaking, but whatever, their store, their rules...), my little App was finally approved for sale. It did moderately well, passing 1,000 downloads with virtually no advertising from me.

I had big dreams for this little app. Plugins, global hotkey support, localization, Applescript support, and more potential functionality. But all that was dashed by "Entitlements" and Apple's requirement that all apps must be sandboxed.

Look, in theory, the idea of sandboxing an app is not bad. The problem here is Apple's all-or-nothing approach to sandboxing. The selection of entitlements are just so limited as to be nearly useless for anyone creating a unique, new or complex app - especially one that requires hardware access. Your choice is either to sandbox your app, choosing from the available selection of entitlements, or not sandbox it and not be in the Mac App Store at all starting in March. There's no reason to only provide such a limited subset of functionality that a developer must choose from. Would it not be better to provide us a wider set of entitlements and allow us to justify our reasons for needing them when we submit our app?

The reason Apple gives for requiring sandboxing is to prevent "rogue apps" from destabilizing the system. But when you consider that the App Store itself is curated, this requirement makes even less sense. If Apple is curating the store, how does a "rogue app" end up in the App Store?

I'm a huge Apple fanboy. I have almost all Apple hardware in my house, from my iMac to my Macbook Pros, to my iPad and iPhone and my wife's iPod Touch. I had AppleTVs before they were cool (and there's one on every one of my TVs now). I love Apple. But as an developer ... I [expletive] hate Apple for this "innovation" that crippled my once-promising little app.

So, at this point, my options are:

  1. Leave Airplane Setting in the App Store. Doing so will mean no further updates so I'll likely cease development.

  2. Remove Airplane Setting from the App Store and start distributing it exclusively from the website.

My original intent with Airplane Setting was to explore what it was like to be an App Store developer. I guess ... now I know what it's like to be an App Store developer, and living in constant fear of Apple as a sword of damocles hanging over your head.

( Comments )

Did something I wrote help you out?

That's great! I don't earn any money from this site - I run no ads, sell no products and participate in no affiliate programs. I do this solely because it's fun; I enjoy writing and sharing what I learn.

All the same, if you found this article helpful and want to show your appreciation, here's my Amazon.com wishlist.


Related Posts

The Right Way to Create an iCloud-enabled Mac App in Xcode

Xcode 4


comments powered by Disqus