Regarding Apple's use of private API in iBooks

Marco Arment raised a flag on the iPad App Store field today and called foul over Apple using private APIs in their first-party iBooks app.

Private APIs are meant to be exclusive to Apple's OS and built-in apps (like Safari, Mail, iPod, etc.) because they're experimental, transitional, or otherwise not something that developers should count on being there in the same form in the next OS update. They're still works in progress. Public APIs on the other hand are an agreement between Apple and developers that they can be used to build apps safely and confidently because they won't be changed in a future update (Apple won't break existing apps).

Up until now, Apple has played by their own rules and all of the apps they've not built into the iPhone (Remote, Keynote Remote, MobileMe Gallery, etc.) have been based on public, no private APIs. Reportedly Pages, Keynote, and Numbers were careful to stick to public APIs as well. That's only fair. If Apple could do things in the App Store that competitors like QuickOffice or Documents to Go couldn't, developers could rightly call it unfair, and that could lead to trouble.

However, according to Arment and backed up by oldmanuk, iBooks does make use of private APIs for functions like the in-app brightness control, a feature that would get a competitor like Amazon's Kindle app rejected from the App Store.

Developers are understandably upset about this seeming break in Apple's policy.

Thing is, Google famously got away with using private API for their Google Mobile App in late 2008 only to have those API made nice and legal in 2009.

So for TiPb's part, we're going to wait for the iPhone 4.0 event in 2 days and see if the private vs. public API landscape doesn't change when the next SDK beta hits the streets.

[Thanks Dev for the tip]