Collateral Damage

The iPhone 4.0 SDK brings a lot of new features to the platform, it also brings a new iPhone Developer Agreement. John Gruber from Daring Fireball points out to the updated section 3.3.1 of the agreement effectively bans everything not originally written in C, C++ or Objective-C:

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).

It clearly states that you cannot do iPhone OS development with the language you want. This rules out Adobe’s near-ready Flash compiler — which was probably the point — but it also bans the use of other languages in games and applications that would benefit from it. Basically, Apple is telling us what language to use not only for the front-end, but also the back-end of our software.

Michael Tsai writes it best:

Leaving aside the question of whether it’s reasonable to ban cross-platform applications rather than let customers decide whether they’re useful, I worry that this new regulation will also affect native applications. There are a variety of reasons that a developer might want to leverage other languages (either at build time or runtime) for code reuse, libraries, or development speed and power. Consider, for example, an AI or game engine written in Lisp that compiles down to ARM assembly or C.

I’ll also have to agree with Hank Williams about this:

Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not “originally” written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is INSANE.

Steve does not want to allow Adobe’s tools to be able to generate compiled code for the iPhone. But with this additional twist he doesn’t even want Adobe to be able to generate objective-C which is then compiled by Apple’s tools. The ridiculousness of specifying the manner in which one writes their code is hard to understate.

Insanity at its best. If I need to write a parser for my application, can I write it in Lex/Yacc? No, because even though those tools just generates small snippets C code from a grammar it wouldn’t be originally written in C. What about regular expressions? What about routines optimized using assembler code?

And how will they enforce that? Given proper inlining in the compiled code, they can’t really tell in what language you’re working. Sure, in some cases it’ll be obvious, but in many cases it’ll slip easily.

My impression is that rules of this kind are only there to give a semblance of coherency. We already know Apple reserves itself the right to refuse any application for whatever reason they like when you submit them, and to remove them even after they were accepted. A rule that outlaws practically anything even though it’s not coherently enforceable is a great way to justify arbitrary decisions without having to publicly acknowledge the real reason.