iPhone, Apple, and private API calls: Round 2

John Gruber tackles private APIs again on Daring Fireball, noting that even some homegrown solutions to mimic iPhone private API calls has been banned inexplicably by Apple.

The API in question is Cover Flow. Most internal Apple applications have access to the coverflow system but when a coder decided to mimic the system, his product was banned for using a private API. In fact, Apple has been timebombing some of the APIs, allowing folks to use them and then pulling the plug on them down the line.

Again, this is inside baseball but it’s interesting to see an API grow and mutate over time and see the problems with keeping things closed in general. Sure, you get great quality software 90% of the time –

There is no real technical barrier, at least in Cocoa and Cocoa Touch, that prevents third party software from calling private APIs. The public/private distinction is a social barrier, not a technical one. The difference, from a developer’s point of view, is that public APIs are more than just a list of what works now; they constitute a promise, a commitment, from the platform provider of what will continue to work in the future.

A private API call is subject to change or vanish in the future. There is some reason why a private API is private. Could be that it is here to stay, that the platform vendor simply hasn’t gotten around to documenting it yet. But it could just as easily be a stopgap that the vendor intends to completely replace. And when the platform vendor in question is an opaque entity such as Apple, you just don’t know.

crunchgear.com