Private API is the Wrong Question 2010/04/07

With the release of iPad, Apple’s conformance to public API in their App Store offerings has come under scrutiny. iWork is lauded for using only public API, while more recently, iBooks has been called out for lacking such purity. As with many topics, arguing about whether Apple should use private API not only doesn’t have a simple answer, but it is the wrong question.

What’s comforting about the black or white phrasing is that it seemingly has an equally plain answer. While over simplification is a sure fire way to stir up bloggers, it avoids important issues. Looking at iWork for iPad, you might start to wonder about a more basic question: what counts as private API?

Building iWork using only public API is a huge achievement. I cannot even guess at how much work my friends at Apple put into accomplishing this, on top of making some incredible applications. Thank you!

Evolving public API has both costs to Apple (development, QA, maintenance, delays in important revenue generating events like, say, iPad) and it has benefits (allowing third-party developers to fill niche needs, making the platform more compelling to customers). iPhone OS 3.2 makes important strides, but shortchanges some critical factors: platform consistency and wasted effort. Consider these framework-worthy features, common across iWork:

Rich text editing
Document browser
Document export/import

Rich text editing is made feasible in iPhone OS 3.2 by the addition of CoreText, but just barely. Writing a real text editor atop CoreText is a large amount of work. It is difficult, and painstaking to exactly mimic all the little behaviors that aren’t addressed by CoreText at all (bi-di cursor movement, selection display and editing, style editing, fast multi-paregraph editing, embedded attachments, …). The document picker also has a wide range of common behaviors like open/close animations, custom scroll page snapping, preview rendering, and common actions. The import/export sheet has controls for selecting file types, and querying, listing and operating on the shared documents.

So, here we have a blob of common code that helps define the platform and I can’t get to it. This sounds like private API to me, even if it isn’t actually in the pile labelled “UIKit”. Instead of finishing this and making it available, the code is seemingly included directly in each of the iWork applications. The claim of iWork using 100% public API comes off a bit like a kid finishing cleaning their room by sweeping the last pile of junk under the bed. Yeah, it looks better for when company arrives, but it’ll generate more work overall.

By not finishing this API, Apple has left those of us needing similar features to either choose to build slightly different subsets of the features (and all get them differently wrong), or just drop the features. I can only guess as to what went into these decisions, so I won’t presume to say this choice was wrong. But, I do know that it is sad to hear the “100% public” claim, given how much we had to re-implement (and best case: only to throw it away for iPhone OS 4.0).

Stop whining, you!

Particularly on iPhone and iPad, it seems like there is a potential approach to improvement.

Consider that there is only one app running at a time (modulo Apple’s background apps and whatever announcements happen tomorrow with iPhone OS 4.0), there is no bundle loading and the developer submitting the app controls all the code above the frameworks. In all, this means it is pretty easy to version “mini SDKs” without symbol conflicts.

Let’s say that iWork for iPad 1.0 has a real CoreText-based editor widget, and while maybe it doesn’t have perfect API, it is at least the best on the platform! Apple could ship a static library, headers and some resources for these semi-baked APIs. The mini SDK would use only real public APIs, and maybe they would have some cross dependencies on each other (not great, but still OK). When iWork 1.1 arrives, maybe there is a new set of mini SDKs shipped and that’s fine: all the existing third-party apps would continue to work just fine until they chose to update.

Out of this Apple would get a more consistent platform for its users, external feedback on API before it becomes frozen, and higher quality third party apps by allowing developers to spend time on non-framework development … and I could spend less time writing code to throw away later. Just sayin’ …

Please reference Radar #7839960 if you agree!