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.


Suivi


Commentaires

Marie-Eve Tremblay

Difficile d’être d’accord avec une telle règle, non seulement ça ne règlera pas le problème de la qualité des applications soumises (ce qui je crois est l’intention initiale), il prive le monde de potentiel évolutions et améliorations. Apple aurait vraiment intérêt a apprendre du monde des consoles, qui avec des lignes directrices claires, obtiennent des applications d’une niveau de qualité optimal.

Simon Tremblay

Il ne faut quand même pas oublier que dans le monde des consoles avec tous les TRC, bien que cela fait en sorte que les jeux sont en général de meilleure qualité, que tout ce système a un coût énorme.

Bref, j’ai bien hâte de voir comment il est possible de faire respecter leur article 3.3.1 alors qu’a priori on ne peut avoir aucune idée ou presque dans quelle langage d’origine a été écrit une application!

Michel Fortin

Simon: Je doute qu’ils soit très exhaustif dans leur recherches. Ils vont cibler certains outils, déceler des patterns dans les applications compilés avec ceux-ci et vérifier les applications soumises. Une sorte de « black list » de patterns, qui seront probablement pris dans la runtime des langages bannis. Dépendant du langage d’origine, ça va fonctionner plus ou moins bien.

Le problème c’est que personne ne peut vraiment savoir ce qui est permis ou non. En théorie tout est interdit, mais en pratique c’est Apple qui décide selon des critères arbitraires, et il est peut probable qu’Apple s’attaque à des choses comme des générateurs de code basé sur des grammaires tel Lex/Yacc ou des trucs dans le backend des applications (mais ce n’est que mon avis).

Ironiquement, le jeu que j’ai porté a été converti du D au C++ (manuellement). Le « langage d’origine » du jeu est donc le D. À mon sens ça brise la nouvelle règle. Mais vraisemblablement ils ne feront rien.


  • © 2003–2018 Michel Fortin.