Dommages collatéraux

Le SDK du iPhone OS 4.0 apporte beaucoup de nouvelles fonctionnalisées à la plateforme, il amène aussi un nouveau iPhone Developer Agreement. John Gruber de Daring Fireball fait remarquer que la nouvelle section 3.3.1 de cet accord banni tout ce qui n’est pas originellement écrit en C, C++ ou 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).

On y lit clairement qu’il n’est plus permis de développer pour iPhone OS avec le langage de son choix. Ceci rend inutile le compilateur Flash d’Adobe qui était presque prêt — et c’était probablement le but — mais ça empêche aussi l’utilisation d’autre langages dans les jeux et les applications qui pourrait en bénéficier. Essentiellement, Apple dicte les outils pour la création non seulement de l’interface utilisateur, mais du « back-end » du logiciel.

Michael Tsai en fait la description parfaite :

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.

Et ne peut qu’être d’accord Hank Williams sur ce point :

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.

C’est complètement insensé. Si j’ai à écrire un parseur pour mon application, est-ce que je peux l’écrire avec Lex/Yacc ? Non, parce que même si ces outils ne font que générer des petits bouts de codes en C à partir d’une grammaire, ce n’est pas du code écrit en C à l’origine. Qu’en est-t-il pour les expressions régulières ? Que dire d’une routine optimisé avec du code assembleur ?

Et comment peuvent-il faire respecter cette règle ? Avec suffisamment d’« inlining » dans le code compilé, il n’est pas vraiment possible de dire dans quel langage il a été écrit à l’origine. Certainement, certain cas seront évidents, mais dans beaucoup de cas ça va passer sans se faire remarquer.

Mon impression est que les règles de ce genre ne sont là que pour donner un semblant de cohérence. On sait déjà qu’Apple se réserve le droit de refuser une application pour n’importe quelle raison, et même de les enlever après approbation. Une règle qui interdit pratiquement tout mais qu’il n’est pas possible de faire respecter de façon cohérente est une bonne façon de justifier des décisions arbitraires sans avoir à dévoiler la vrai raison.