Pourquoi Apple rend obligatoire les langages C, C++ ou Objective-C sur l’iPhone

La nouvelle a un peu surpris, et beaucoup choqué. En annonçant l’arrivée de l’iPhone OS 4.0 et de son SDK, Apple a modifié les conditions d’utilisation destinées aux développeurs. Désormais, un article 3.3.1 dispose que seuls les applications écrites dès le départ en Objective-C, en C, en C++ ou en JavaScript tel qu’exécuté par le moteur WebKit de l’iPhone seront autorisées sur l’App Store :

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

Il s’agit d’une première dans l’histoire de l’informatique. Jamais auparavant un constructeur ou même un éditeur de logiciels d’exploitation n’avait imposé à des développeurs le langage dans lequel ils devaient écrire les logiciels destinés à y être exécutés. Ce qui importe à Microsoft n’est pas d’imposer le C# plutôt que le C++ ou le Pascal, mais bien au contraire de faciliter au mieux la vie des développeurs pour qu’ils compilent des applications écrites comme bon leur semble. Mais elles seront exécutables uniquement sous Windows, et non compatibles avec Linux ou Mac OS. Plus il y a de logiciels compilés pour Windows, plus Windows s’impose comme standard obligatoire. C’est ce qui l’a aidé à avoir une part de marché proche de 100 % sur les PC.

Avec son nouveau contrat, Apple prend une posture totalement différente, mais qui répond à la même problématique d’incompatibilité. Il aurait pu permettre à tous les constructeurs d’installer l’iPhone OS sur leur téléphone mobile, comme l’a fait Microsoft pour Windows avec tous les constructeurs d’ordinateurs, dans l’espoir d’aquérir le même niveau de parts de marché. Mais la firme de Cupertino n’a pas cette culture ni cette ambition, et veut donc plutôt empêcher la création d’un standard unique qui serait compatible avec les principaux appareils mobiles, et dévaloriserait ainsi l’iPhone.

C’est un coup très dur porté aux éditeurs de SDK multi-plateformes comme Unity ou MonoTouch. Mais Adobe était le mieux placé pour parvenir à imposer un standard, avec son Flash CS5 qui devait permettre de compiler des applications écrites en Flash vers des applications pour iPhone ou d’autres plateformes. En quelques clics, les développeurs pouvaient créer une seule et même application en Flash, et la rendre compatible avec l’iPhone, l’iPad, l’iPod touch et divers appareils concurrents sous Android, Windows Mobile, ou Blackberry. De fait, le Flash se serait vite imposé comme standard dans les entreprises en recherche de productivité. Mais le navigateur mobile d’Apple ne reconnaît pas le Flash, et désormais les contrats imposés aux développeurs leur interdise de convertir une application Flash vers une application pour l’App Store. Il faut qu’ils la réécrivent en entier à partir du C, du C++ ou de l’Objective-C.

Or Apple ayant la part de marché la plus importante sur les smartphones, renforcée par le succès de l’iPad, il n’est pas concevable de se passer de la compatibilité avec l’iPhone et sa fratrie. L’iPhone OS restera donc la plateforme de prédilection, et les consommateurs qui souhaiteront accéder aux applications pour iPhone OS auront l’obligation d’acquérir un appareil Apple.

Interrogé sur sa stratégie, Steve Jobs n’a pas nié cette interprétation. Il a même renvoyé vers un billet de John Gruber, qui explique lui-aussi cette vision des choses. Gruber y voit aussi un souci de la part d’Apple de ne pas être dépendant de la vitesse d’Adobe ou des autres fournisseurs d’API alternatives à s’adapter à ses propres mises à jour. « Imaginez un monde où la boîte à outils cross-plateforme d’une autre société s’avère extrêmement populaire. Alors Apple dévoile de nouvelles fonctionnalités pour l’iPhone OS, et la boîte à outils de cette autre société est lente à s’y adapter. A ce stade, c’est l’autre société qui contrôle quand les applications des tiers peuvent tirer partie de ces fonctionnalités« , écrit-il.

C’est en somme la situation qu’ont subi les développeurs et webdesigners pendant des années, lorsque les spécifications adoptées par le W3C pour enrichir les pages web étaient publiées. Avant de pouvoir les exploiter, il fallait attendre parfois plusieurs années que Microsoft les prenne en charge sur Internet Explorer.