Private API’s, the other side

The iPhone approval process is getting stricter about private API use. Most of the press about this change seems positive.

For example the latest DaringFireball says:

“Fuller had done the right thing: he wrote his own Cover Flow implementation from scratch, without the use of any private APIs”

“Right thing” and “from scratch” in the same sentence hurts my programmer’s brain.

I think “Don’t use private APIs” is a good rule. But it’s not the only rule, and I sometimes think it make sense to break it to serve a higher goal—create the best possible user experience. Here’s the other side of the argument.

Why is it bad to rewrite a private API?

First it breaks the most important rule of software development, don’t duplicate code. When you rewrite you introduce bugs. When you rewrite you create different looks and behaviors. Users of an app that has rewritten a private API are more likely to experience new bugs, and are likely to see inconsistencies between the apps.

Second there are always better things that a developer can be doing. Rewriting existing code can sometimes be fun, but it’s almost never the best use of the developers time. Developers should spend their time creating new solutions, not rewriting existing code that already works.

Yes, using private APIs can and will break things occasionally. But it’s not a right or wrong decision, it’s a tradeoff. Use private API to create perfect software, that might need to be fixed later. Rewrite private APIs to create safer software that’s less likely to need a fix in the future, but also less likely to delight users today.

Using private APIs has always been a useful tool in my toolkit. I’m sorry to see it go, it’s no fun to spend my time duplicating code that someone else has already written and tested. In my mind it’s one more step down the road of Apple’s Mistake.