Private APIs and Apple’s role as the iPhone policeman

John Gruber has posted one of his usual thoughtful pieces on the role and usage of “private” APIs in the iPhone – APIs which exist, but are not part of the public frameworks which developers are supposed to use. John makes many good reasons not to use such APIs – the most important of which is simply that they’re likely to go “bye-bye” at any moment, breaking your app completely.

However, John – perhaps wisely – doesn’t step into the bigger question: Why should Apple be the arbiter of good programming on the iPhone at all?

The most often-cited reason is that a phone is not a computer, in the sense that it’s vital that it keeps working. Given the iPhone’s abysmal battery life, this seems to be something which Apple itself is happy to ignore when it suits. My iPhone is more likely to be out of battery when I want to make an emergency call, rather than constantly crashing.

There’s a second reason why this argument is a red herring: no third party application can run in the background, which makes it much harder for an app to lock-up your phone to the extent of being unable to place or receive calls.

So why is Apple keen to keep private APIs private? I think it’s simply a misguided attempt to protect users from bad programming. But the problem with this approach is that it’s a slippery slope: at what point do you stop trying to protect users from bad programmers? Do you reject applications on aesthetic grounds? Because they’re memory hogs? Because you simply don’t like them, and don’t see a need for them?

Restricting the market for applications, even with the best of intentions, inevitably leads to a stale marketplace. Sooner or later, Apple will either open its market up, or miss out on the next generation of truly-useful apps.