Apple iPad, Private APIs, and a Tempest in a Teapot
In the wake of the generally positive iPad reviews circulating the web, a light developer backlash has occurred, in the form of grousing about private APIs. Of course, developer backlash around recent Apple products is not new: the moment the iPhone was announced, developers went ballistic that the recommended platform of choice was web apps; after a native app store was released, the protests turned to the byzantine and often arbitrary nature of its approval process. Now, with the iPad, it appears that there is something new to contest.
Background: what are "Private APIs" ?
Software systems that open themselves up to third party development provide ways by which developers may use built-in frameworks and libraries to build their applications. These are "application programming interfaces," or APIs. Public APIs are publicly accessible and documented, whereas private APIs – while still perhaps technically available to third party developers – are not.
It's important to note that there is very little that separates a public API from a private one, beyond the fact that the public is documented, and "blessed." By blessed, I mean that that interface has been documented and described in the hopes that developers will use it, and with the implicit understanding that it is not likely to change in an incompatible way any time soon. Private APIs offer no such guarantee. If developers can find them, they can technically use them – but there is nothing stating that they won't just disappear the next time the core software is updated. For their own safety, third party developers ought to tread lightly. Private APIs are generally regarded as unfinished, half-baked, and likely subject to change.
Software products that encourage add-ons don't want their third party developers to use private APIs, because that frequently leads to third party software that requires frequent updates, any time the underlying core is changed. For example, on Mac OS X there are a number of "haxies" – software programs which modify OS X's appearance or low level behavior in ways Apple hasn't foreseen or blessed. Users install this software because they aren't completely happy with the way OS X functions. To do what they do, these programs take advantage of functionality that Apple hasn't documented for the outside world. The result? Whenever updating OS X, make damn sure you check to see that there's an update to all this third party software first, because it's quite likely that the private APIs have changed in some way, and updating the core will lead to an unstable or unworking system.
Enter the App Store
The micromanagement of the updating process as described above is tedious. Even worse, most computer users will fault the OS for breaking their favorite extensions, when in fact their extensions are built on a shifting foundation. But with the iPhone and iPad app store, Apple has implicitly guaranteed that their device is more an appliance than a typical computer system, and appliances can't require this same level of maintenance. They have to "just work." That's why Apple has rejected apps from the app store which use private APIs. Most developers will tell you that's reasonable.
Do as I say (not as a I do)
Then what's the problem? Apple has apps, within the app store, which use private APIs! Why does Apple get to play by a different set of rules than third party developers?!
This seems like a reasonable complaint, right? Obviously, Apple can do what they want with their store, but isn't that somewhat skeezy (for lack of a better term?)
No. It's necessary.
If you'll permit me, I'm going to proceed with a tangent. In concrete5 version 5.2, we introduced a new class named PageList. This class was meant to provide an object-oriented and extendable way to search and filter pages, and replace the ailing, old and poorly thought-out CollectionSearch class. While we did have portions of the PageList class documented when it was released, we didn't release official documentation for it until just recently.
Why? Simply put, the class wasn't ready. It was 80% of the way, but we knew that underlying frameworks that the class referenced weren't totally stable, and that the class and its API were likely to change. It wouldn't be smart for us to recommend third party developers use and rely on this API when we know its still in flux.
And yet, did that stop us from using the class in production and throughout the core, where applicable? No. Why? Two reasons: 1) we needed to put it through its paces, and 2) real artists ship! We needed to get 5.2 out there, and we couldn't spend the time exhaustively documenting and planning the entirety of the class, especially as we knew it would eventually interact with entire libraries and objects that hadn't even been planned yet. We needed to use code in projects and add-ons to see where the class fell short, and what it needed.
Fundamentally, I imagine Apple – and the iPad project in particular – is no different. When the word comes from on high that the project, including its apps, must be ready, who's going to tell Steve Jobs that the APIs used by the iBooks app need to be completely set in stone, documented, and shared with the developer community? Heh, you first! Instead, the team packages up what they have and uses it as a starting point, and the private APIs evolve organically into the public ones! Ship first, refine, improve, and then publish. That way, you'll see where you application interface needs tweaking and fixing. Far better to iron out the kinks before the API is published and made available to third party developers, than release the documentation too early, and have a slew of apps that require updates when an update to the API breaks them.
In Conclusion
To the developers bashing Apple over this, I'd ask you to consider the position of the framework manager, or the manager of the entire iPhone OS ecosystem. Step outside of the ideal world and start thinking pragmatically. Yes, there are some very valid concerns regarding Apple and its handling of the app store, but I don't think this is one of them. Besides – it sounds like there's already something brewing that makes this seem like small potatoes.
