Adobe a donc annoncé que la prochaine version de Flash (CS5) permettrait d'exporter des applications pour iPhone. Apple refusant à Flash d'entrer par la grande porte, Adobe a réussi à passer par la fenêtre. Commençons par nous pencher sur l'approche technique qu'Adobe a choisie, et par faire le détail du fonctionnement de Flash.
Flash est basé sur le langage ActionScript, un langage de type script proche de JavaScript. Ce type de langage nécessite un « interprète » : pour pouvoir être exécuté sur tout type de processeurs, il n'est pas compilé en langage machine. En lieu et place, un interprète fait l'interface entre le script et le processeur, en convertissant à la volée les instructions du script en commandes compréhensibles pour le processeur : ainsi, un fichier Flash peut être exécuté sans modification sur toute machine qui dispose du player ad-hoc, quel que soit son processeur ou les API de son système d'exploitation. Flash étant une technologie dédiée au web, et donc susceptible de fonctionner sur tout type de machine, c'est cette approche qui a été choisie (l'ActionScript n'ayant pas vocation à s'adresser à une plateforme matérielle en particulier).
Le problème d'un tel système, c'est que l'interprétation est bien plus lente que l'exécution d'un code compilé. Pour y remédier, on a parfois recours à un compilateur JIT (pour "just-in-time", à la volée), qui, au lieu d'interpréter les commandes, les compile directement en langage machine. C'est certes plus rapide que l'interprétation, mais malgré tout pas autant qu'une compilation "ahead-of-time", qui aboutit à du code assembleur exécutable directement (mais qui n'est donc pas distribuable universellement). D'autre part, la compilation JIT doit se faire très rapidement, au moment de l'exécution, et n'est donc pas aussi finement optimisée qu'une compilation réalisée en amont (celle-ci prend en effet beaucoup plus de temps).
Flash s'est vu adjoindre un compilateur JIT depuis sa version 9, mais reste malgré tout très gourmand en ressources (sans parler de la version Mac très critiquée pour ses lourdeurs), ce qui le rend difficilement exploitable sur des machines plus modestes telles que les smartphones. Apple a fait un choix tranché : pas de Flash sur iPhone ni iPod touch. D'autres constructeurs ont intégré Flash mobile avec plus ou moins de bonheur. Apple et Adobe se sont échangé quelques amabilités sur le sujet, la seconde n'appréciant manifestement pas qu'on pointe du doigt la pesanteur de son logiciel.
Une fois cet état des lieux dressé, comment Adobe compte-t-elle remédier à cette problématique avec Flash CS5 ? Rien de plus simple, en permettant de compiler ActionScript en langage machine ARM (le processeur des iPhone), à l'aide d'une bonne vieille compilation ahead-of-time. Ainsi Flash pourra produire des applications exécutables de la même manière que Xcode le fait avec l'Objective-C. Concrètement, Flash CS5 exploitera LLVM (voir notre une Apple tire le jus des processeurs) pour créer directement une application pour iPhone. Moralité, plus de problèmes de vitesse, une application réalisée avec Flash est susceptible de fonctionner aussi bien que n'importe quelle autre, pour peu du moins qu'Adobe fasse les choses comme il faut.
Certes, on peut se réjouir de la multiplication des points d'entrée sur l'App Store, qui offrent autant d'opportunités d'augmenter le nombre d'applications pour l'iPhone de manière exponentielle. Mais toutes les solutions en la matière ne se valent pas.
Car l'approche d'Adobe n'est pas sans inconvénients : si l'éditeur ouvre les portes de l'App Store aux innombrables développeurs Flash de tous bords, elle n'en reste pas moins un intermédiaire. Dès lors, si Apple vient à modifier ses API (ce qu'elle fait régulièrement), il en résultera nombre d'incompatibilités. De même, pour peu qu'Adobe ait laissé quelques bugs dans son compilateur, et ce sont toutes les applications développées par ce biais qui en souffriront, sans possible recours.
De même, pour peu que certaines fonctions de l'iPhone ne soient pas prises en compte par le compilateur d'Adobe, (comme c'est le cas pour l'accès au micro ou à la caméra par exemple), il n'y aura aucun moyen de contourner cette limitation. En outre, le « débugage » d'une application iPhone développée avec Flash consistera à tâtonner dans le noir, puisqu'un tel système ne permet aucun outil de traçage du code ni de remonter la piste d'un plantage, la seule manière de tester le code étant de le faire tourner sur un iPhone et de brûler un cierge. Enfin, ce système ne permet d'utiliser aucun des éléments d'interface graphique natifs de l'iPhone, dans lesquels Apple a mis tant d'efforts. Chaque application créée par ce biais proposera donc ses propres ersatz hétéroclites.
Cependant, Adobe est loin d'être la première à proposer une alternative pour le développement sur iPhone. On en compte nombre d'autres, comme Unity, Mono, GameSalad, ou encore Torque 3D qui permettent chacun de créer des applications compatibles iPhone OS sans coder en Objective-C. Cependant, pour la plupart, ces solutions proposent de convertir le code en Objective-C plutôt que de le compiler directement en assembleur ARM, ce qui laisse autrement plus de latitudes de contrôler la chaîne de production, et ce qui répond également aux problématiques soulevées plus haut.
L'autre élément à noter sur la démarche d'Adobe concerne le plan stratégique : pour mieux faire la démonstration de sa solution, Adobe a fait publier par des développeurs tiers une poignée d'applications sur l'App Store, toutes réalisées par le biais de Flash (Chroma Circuit, Trading Stuff, Fickleblox, Just Letters, South Park Avatar Creator, That Roach Game (ci-dessous), Red Hood).
Quel meilleur moyen en effet de montrer la validité du principe que de montrer des applications validées par Apple et publiées sur l'App Store ? Certains pourraient d'ailleurs y voir la démonstration que Flash peut bel et bien fonctionner normalement sur un iPhone, mais ce serait oublier les nombreuses différences entre ce moteur et le player Flash standard. Cependant, aucune des applications en question ne fait figurer de fonctionnalité avancée ou gourmande en ressources, difficile donc de juger de son efficacité. Cependant, les différentes applications ont montré quelques saccades sur des appareils de générations précédentes, ce qui ne laisse guère augurer du meilleur pour des fonctions plus poussées (voir l'article Premier test des applications Flash pour iPhone). N'oublions pas cependant qu'il ne s'agit encore que d'une version bêta (Adobe a annoncé qu'une bêta publique de ses outils sera disponible d'ici la fin de l'année).
Une fois qu'on a fait le tour de la question, il reste cependant une inconnue : comment Apple va-t-elle réagir à cette initiative ? D'une part, c'est un pied de nez autour du bras de fer concernant Flash sur iPhone, et d'autre part Apple perd le contrôle de la façon dont les applications sont créées pour iPhone, qui plus est sans cohérence graphique, et avec le risque de se retrouver avec des applications trop lentes. D'un autre côté, Flash pourrait également offrir une manne de nouvelles applications, permettant à l'App Store de continuer à gagner de l'importance, pour peu que les applications soient dignes d'intérêt. Enfin, si jusqu'ici il fallait obligatoirement avoir un Mac pour compiler une application pour iPhone, avec Flash CS5 il sera possible de le faire également à partir de Windows.
Flash est basé sur le langage ActionScript, un langage de type script proche de JavaScript. Ce type de langage nécessite un « interprète » : pour pouvoir être exécuté sur tout type de processeurs, il n'est pas compilé en langage machine. En lieu et place, un interprète fait l'interface entre le script et le processeur, en convertissant à la volée les instructions du script en commandes compréhensibles pour le processeur : ainsi, un fichier Flash peut être exécuté sans modification sur toute machine qui dispose du player ad-hoc, quel que soit son processeur ou les API de son système d'exploitation. Flash étant une technologie dédiée au web, et donc susceptible de fonctionner sur tout type de machine, c'est cette approche qui a été choisie (l'ActionScript n'ayant pas vocation à s'adresser à une plateforme matérielle en particulier).
Le problème d'un tel système, c'est que l'interprétation est bien plus lente que l'exécution d'un code compilé. Pour y remédier, on a parfois recours à un compilateur JIT (pour "just-in-time", à la volée), qui, au lieu d'interpréter les commandes, les compile directement en langage machine. C'est certes plus rapide que l'interprétation, mais malgré tout pas autant qu'une compilation "ahead-of-time", qui aboutit à du code assembleur exécutable directement (mais qui n'est donc pas distribuable universellement). D'autre part, la compilation JIT doit se faire très rapidement, au moment de l'exécution, et n'est donc pas aussi finement optimisée qu'une compilation réalisée en amont (celle-ci prend en effet beaucoup plus de temps).
Flash s'est vu adjoindre un compilateur JIT depuis sa version 9, mais reste malgré tout très gourmand en ressources (sans parler de la version Mac très critiquée pour ses lourdeurs), ce qui le rend difficilement exploitable sur des machines plus modestes telles que les smartphones. Apple a fait un choix tranché : pas de Flash sur iPhone ni iPod touch. D'autres constructeurs ont intégré Flash mobile avec plus ou moins de bonheur. Apple et Adobe se sont échangé quelques amabilités sur le sujet, la seconde n'appréciant manifestement pas qu'on pointe du doigt la pesanteur de son logiciel.
Une fois cet état des lieux dressé, comment Adobe compte-t-elle remédier à cette problématique avec Flash CS5 ? Rien de plus simple, en permettant de compiler ActionScript en langage machine ARM (le processeur des iPhone), à l'aide d'une bonne vieille compilation ahead-of-time. Ainsi Flash pourra produire des applications exécutables de la même manière que Xcode le fait avec l'Objective-C. Concrètement, Flash CS5 exploitera LLVM (voir notre une Apple tire le jus des processeurs) pour créer directement une application pour iPhone. Moralité, plus de problèmes de vitesse, une application réalisée avec Flash est susceptible de fonctionner aussi bien que n'importe quelle autre, pour peu du moins qu'Adobe fasse les choses comme il faut.
Certes, on peut se réjouir de la multiplication des points d'entrée sur l'App Store, qui offrent autant d'opportunités d'augmenter le nombre d'applications pour l'iPhone de manière exponentielle. Mais toutes les solutions en la matière ne se valent pas.
Car l'approche d'Adobe n'est pas sans inconvénients : si l'éditeur ouvre les portes de l'App Store aux innombrables développeurs Flash de tous bords, elle n'en reste pas moins un intermédiaire. Dès lors, si Apple vient à modifier ses API (ce qu'elle fait régulièrement), il en résultera nombre d'incompatibilités. De même, pour peu qu'Adobe ait laissé quelques bugs dans son compilateur, et ce sont toutes les applications développées par ce biais qui en souffriront, sans possible recours.
De même, pour peu que certaines fonctions de l'iPhone ne soient pas prises en compte par le compilateur d'Adobe, (comme c'est le cas pour l'accès au micro ou à la caméra par exemple), il n'y aura aucun moyen de contourner cette limitation. En outre, le « débugage » d'une application iPhone développée avec Flash consistera à tâtonner dans le noir, puisqu'un tel système ne permet aucun outil de traçage du code ni de remonter la piste d'un plantage, la seule manière de tester le code étant de le faire tourner sur un iPhone et de brûler un cierge. Enfin, ce système ne permet d'utiliser aucun des éléments d'interface graphique natifs de l'iPhone, dans lesquels Apple a mis tant d'efforts. Chaque application créée par ce biais proposera donc ses propres ersatz hétéroclites.
Cependant, Adobe est loin d'être la première à proposer une alternative pour le développement sur iPhone. On en compte nombre d'autres, comme Unity, Mono, GameSalad, ou encore Torque 3D qui permettent chacun de créer des applications compatibles iPhone OS sans coder en Objective-C. Cependant, pour la plupart, ces solutions proposent de convertir le code en Objective-C plutôt que de le compiler directement en assembleur ARM, ce qui laisse autrement plus de latitudes de contrôler la chaîne de production, et ce qui répond également aux problématiques soulevées plus haut.
L'autre élément à noter sur la démarche d'Adobe concerne le plan stratégique : pour mieux faire la démonstration de sa solution, Adobe a fait publier par des développeurs tiers une poignée d'applications sur l'App Store, toutes réalisées par le biais de Flash (Chroma Circuit, Trading Stuff, Fickleblox, Just Letters, South Park Avatar Creator, That Roach Game (ci-dessous), Red Hood).
Quel meilleur moyen en effet de montrer la validité du principe que de montrer des applications validées par Apple et publiées sur l'App Store ? Certains pourraient d'ailleurs y voir la démonstration que Flash peut bel et bien fonctionner normalement sur un iPhone, mais ce serait oublier les nombreuses différences entre ce moteur et le player Flash standard. Cependant, aucune des applications en question ne fait figurer de fonctionnalité avancée ou gourmande en ressources, difficile donc de juger de son efficacité. Cependant, les différentes applications ont montré quelques saccades sur des appareils de générations précédentes, ce qui ne laisse guère augurer du meilleur pour des fonctions plus poussées (voir l'article Premier test des applications Flash pour iPhone). N'oublions pas cependant qu'il ne s'agit encore que d'une version bêta (Adobe a annoncé qu'une bêta publique de ses outils sera disponible d'ici la fin de l'année).
Une fois qu'on a fait le tour de la question, il reste cependant une inconnue : comment Apple va-t-elle réagir à cette initiative ? D'une part, c'est un pied de nez autour du bras de fer concernant Flash sur iPhone, et d'autre part Apple perd le contrôle de la façon dont les applications sont créées pour iPhone, qui plus est sans cohérence graphique, et avec le risque de se retrouver avec des applications trop lentes. D'un autre côté, Flash pourrait également offrir une manne de nouvelles applications, permettant à l'App Store de continuer à gagner de l'importance, pour peu que les applications soient dignes d'intérêt. Enfin, si jusqu'ici il fallait obligatoirement avoir un Mac pour compiler une application pour iPhone, avec Flash CS5 il sera possible de le faire également à partir de Windows.
