But if developers try to use undocumented (aka private) APIs, the resulting applications will most likely be rejected by the App Store approval process. About the best outcome developers can hope for is "OK, but make sure you remove that in the next version."
The latest round of controversy was sparked by an observation by Marco Arment, lead developer of Tumblr and Instapaper, that the iBooks app uses private APIs, including one that provides a true brightness control.
Arment's concern is that "I won't be able to offer some features that iBooks has (such as a true brightness control), but my customers will expect them, making my app inferior to Apple's in key areas."
Consequently, Apple's apps would be advantaged over third-party products in the same segment. But as Arment noted, the Pages, Keynote and Numbers apps reportedly do not use private APIs, so it doesn't seem as if the company is seeking an unfair advantage.
So why do private APIs exist in iPhone OS? And why doesn't Apple want third-party developers to use them? Please read on.
APIs are essentially contracts between their provider and developers. The deal is that developers can write to APIs, confident that the functions will continue to work even if the provider makes under-the-hood changes, and that the API won't vanish without an extended period of notice.
So a provider such as Apple doesn't want to make an API public until it is confident that the interface is stable and can accommodate likely changes in underlying functionality.
If Apple's about anything other than making money, it's about the user experience. And you don't deliver a good user experience if applications have to be updated just to keep working with every new OS release.
History suggests that Apple does progressively make more functionality available via public APIs. For example, iPhone SDK 3.0 made it possible for apps to access the iPod library. And when 3.1 arrived, it provided a way to superimpose graphics on a live video stream from the camera.
Arment's suggestion that "Ideally, Apple should only publish first-party App Store apps that would be approved if they were submitted by a third party, and they should therefore use no undocumented or prohibited APIs" is clearly - and understandably - looking at the issue from the perspective of a developer, not an end user.
What might Arment's idea mean to those end users? Please read on.
And even if Apple did adopt Arment's suggested policy, it would still have an easy workaround available - simply deliver iBooks as a 'built in' iPad application rather than leaving it to owners to download the software from the App Store.
Those in Arment's camp might argue that the long term benefits that will accrue from more level playing field (in the context of Apple vs all other developers) will outweigh any short-term loss of utility. Others might adopt the attitude that 'in the long run we're all dead.'
And trying to draw parallels with anti-trust actions against Microsoft (and this is something that Arment brought up) are misplaced. Central to the case against Microsoft was its overwhelming market share.
Popular as the iPhone is, BlackBerry is still the leading smartphone in the US. And not even BlackBerry accounts for the majority of smartphones in use in that country.
While it's reasonably obvious that the fewer private APIs the better, expecting platform vendors not to use them doesn't make much sense.
If a tree falls in a forest and no one is around to hear it, it does not make a sound - sound (as opposed to vibration) requires a listener. And an interface that no application is allowed to use can hardly be called an API.