The Much-Discussed Apple iPhone 4.0 beta TOS

As I write this in April 2010, Apple has just released a beta iPhone 4.0 SDK with the following rather alarming addition to the legal terms (at least according to many web sites; I haven’t seen it directly from Apple yet):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The is an avalanche of commentary out there on this, most of it negative, centered around the word “originally”. John Gruber, in his second comment about section 3.3.1, gives some reasons why this is sensible from Apple’s point of view. The essence is that it will lead to higher quality app, on average.

I will try to add a bit of insight from my experience. I am of two minds on this.

Why It Makes No Sense

From the point of view of using / creating the best tools, it strikes me as ridiculous. Great developers, or developers creating great things, generally use layered software designs to do so; and indeed layering, the increase in abstraction over time, is absolutely crucial to the software industry’s ability to make good use of ever-growing hardware capabilities. One obvious and vital kind of layering/abstraction is the use of higher level languages. Apple’s new insistence that only its provided languages/runtimes be used, ignores this fundamental insight.

More ominously, if this notion of “originally written” turns out to be enforceable. Imagine if earlier platforms had required that all software be written “originally” in the provided languages, with any attempt to build a higher level on top, banned; we could never have gotten to the amazing variety of technology available today, under such a regime. If such restrictions grow popular beyond Apple, that could lead our industry in to a kind of dark age.

I don’t think that’s likely though, and for that matter I think it is most likely that Apple won’t be able to make this new term stick. There are many successful apps already using a variety of languages, frameworks, and layered designs. Enforcing it as written, universally, would impact too many of those. Yet if Apple enforces it selectively (just to squash Flash, as many commentators suggest), they invite a long and painful legal mess. Speaking of that, such a legal mess would be an enormous windfall for Android.

Why It Makes a Bit of Sense

Setting aside the questions of whether it can possibly work, Apple’s notion does make a some sense, at least for the immediate future for this specific (iPhone etc.) platform. Most iPhone users/customers are probably better served by a market consisting mostly of native apps.

The difference between native and non-native apps for iPhone OS, is mostly analogous to the same difference a decade ago in PalmOS software. The native (and tedious to use) C toolset was the most popular, but there were many other (higher level) tools to choose from, and with frank honesty I can say that the results were generally poor, and almost always worse that write the same app with the native tools.

In fact, my firm Oasis Digital worked for at least two different customers on projects to replace applications written using such tools, with code we wrote in C or C++. Yes, it took longer; yes, it was more lines of code. Yes, it took more testing and was more prone to the kinds of problems low level code has, with memory leaks and the like.

But most critically, from the point of view of the users, our results with low level tedious implementation were obviously better. The high level tools available today for iPhone are much better than the Palm stuff a decade ago; but still, I suspect the same applies to a lesser extent on the iPhone-OS platform today.