Créé en 1995, Java était présenté à l'époque comme une nouvelle façon de programmer et d'exécuter des applications. Pour faire simple, en écrivant son code, le programmeur n'avait plus à se soucier de la machine sur laquelle il allait être exécuté, il n'avait pas à se préoccuper de la gestion de la mémoire et le langage en lui-même présentait un niveau d'abstraction suffisamment élevé pour se concentrer sur le fonctionnel, plus que sur les optimisations diverses.
Java est partout... sauf sur iOS !
20 ans après, le Java a largement conquis le monde de l'entreprise, et a regagné en popularité ces dernières années, avec la décision de Google de l'utiliser pour Android. Il est désormais nettement en tête du classement Tiobe, qui évalue les langages les plus populaires chaque année. Malgré ce succès, Apple a choisi de poursuivre avec ObjectiveC, un langage également orienté objet, mais dont les bases sont très différentes du Java : il faut gérer la mémoire manuellement et il s'agit d'un langage compilé, qui produit des exécutables spécifiques pour une (ou plusieurs) plateformes. Chacun a ses avantages et ses inconvénients, et le choix d'Apple s'est finalement montré plutôt convaincant : le fait d'être compilé offre des performances nettement supérieures à CPU égal, les apps consomment moins de mémoire, il n'a pas besoin de Garbage Collector pour gérer sa mémoire et il ne faut pas oublier qu'il est rétro-compatible avec le langage C, encore très populaire (2e du classement Tiobe). Mais en face, Java garde quelques atouts, et pas des moindres : Java est bien plus accessible qu'ObjectiveC (il est souvent enseigné à l'école), le programmeur n'a pas à gérer la mémoire et surtout, il n'est pas dépendant d'une seule plateforme matérielle spécifique.
Swift, à la conquête de Java
Depuis quelques années, Apple a donc décidé de venir marcher sur les terre de Java, mais avec sa propre approche. L'arrivée de ARC a permis aux développeurs venant du web ou du monde Java de ne plus se soucier de la gestion de la mémoire sans faire de concession sur les performances (pas de Garbage Collector). Cette technologie, qui a fait ses preuves sur iOS, a été logiquement conservée avec Swift.
L'arrivée de ce nouveau langage ne s'est d'ailleurs pas faite par hasard et avait également Java en ligne de mire : la structure est plus simple, et se rapproche même plus des langages de script les plus populaires (JavaScript, PHP...), gage d'adoption majeur chez les jeunes. Mieux encore, Swift 2 est passé Open Source... tout comme Java depuis plus de 10 ans !! Comme Jeff vous l'expliquait il y a quelques jours, l'intérêt de cette décision est énorme, tant sur le plan universitaire que pour conquérir, par exemple, le marché des serveurs.
BitCode : la pierre angulaire
Cette année, Apple a finalement posé la dernière pierre nécessaire pour atteindre l'édifice Java : l'indépendance des plateformes grâce au BitCode. L'annonce est passée un peu inaperçue pendant la keynote et les développeurs présents à la WWDC ont d'ailleurs été assez étonnés de ne voir aucune sessions dédiée (hormis quelques mots dans App Thinning in Xcode). Plus étrange encore, la documentation se limite à seulement quelques lignes :
Le BitCode d'Apple se rapproche en fait du ByteCode Java, à la différence près qu'il ne sera pas exécuté sur l'iPhone directement. Sur Android, Google utilise une technologie dite Just In Time qui permet de compiler l'app directement sur le téléphone, là où Apple fait le choix de n'offrir que des binaires optimisés à ses utilisateurs (on se demande d'ailleurs si une ferme de Mac existe quelque part pour réaliser l'opération !). Cupertino demande donc à ses développeur de pré-compiler leurs programmes, charge à elle de gérer la dernière étape, qui consiste à compiler le code pour une plateforme donnée et à gérer les dernières optimisations, habituellement réalisées par le compilateur, côté développeur. L'approche est intelligente, puisqu'Apple pourrait potentiellement changer ses processeurs sans demander de travail supplémentaire à ses éditeurs. Mieux encore, ce type de solution permet d'ajuster chaque app aux petits oignons pour un processeur et un environnement donné : actuellement, une app est compilée de la même manière pour tous les appareils, avec comme seul choix, une version 32 et 64 bits. Désormais, Cupertino pourrait offrir des dizaines de combinaisons possibles d'un même programme, chacune optimisée spécifiquement pour l'appareil concerné.
BitCode, la porte ouverte à des Mac ARM ? Pas si vite !
Un article anonyme posté sur Medium fait le buzz depuis hier, l'homme estimant qu'Apple prépare en fait une transition CPU ou plutôt, s'offre le choix des puces : si BitCode arrive un jour sur Mac (ce n'est pas encore le cas pour l'instant), il pourrait permettre aux développeurs de fournir à Apple des exécutables qui seraient indifféremment compatibles avec des machines ARM ou Intel. Toutefois, il ne s'agit que d'une théorie : actuellement, Apple impose un bitcode par architecture, il n'est donc pas possible d'avoir un seul et même code pour les apps 32 et 64 bits. Pour le moment, seules les évolutions mineures des architectures sont prises en charge, mais ce n'est sans doute que le début.
Sur iOS, BitCode est déjà imposé sur l'Apple Watch, ce qui permettra à Apple de proposer un processeur S2 immédiatement optimisé avec les anciennes applications, sans avoir à demander aux développeurs de recompiler leurs apps. Pour iOS, le binaire classique reste de mise, et le BitCode n'est envoyé (pour le moment) qu'en complément. BitCode se présente donc comme un moyen idéal de ne pas se retrouver dépendant d'une plateforme matérielle, sans pour autant perdre en performances ou être obligé de créer des techniques Just In Time utilisées actuellement pour accélérer l'exécution des langages non compilés (Java, JavaScript, PHP...).
Un accueil mitigé chez les développeurs
Et les développeurs, ils en pensent quoi de ce BitCode ? Le moins que l'on puisse dire, c'est que les réactions sont partagées. D'un côté, la plupart se félicitent de l'élégance de la solution, qui pourrait se montrer ultra-efficace le jour où le hardware ne se limitera plus à de l'ARM sur iOS et de l'x86 sur Mac. Mais cette technique ouvre aussi de nombreuses interrogations :
- Quid du testing ?
C'est LA crainte principale des développeurs : si demain, Apple sort un iPhone 6s avec un processeur A9, Cupertino pourrait recompiler toutes les apps pour ce processeurs, avec toutes les optimisations nécessaires. Seul hic, aucun développeur n'aura pu tester le code avant la sortie. Apple prend donc le risque de voir certains programmes planter ou se comporter anormalement. De nombreux développeurs continuent d'essuyer les plâtres du passage au 64 bits (qui ne s'est pas fait dans la douceur, loin de là) et l'idée qu'Apple puisse valider elle-même une nouvelle transition inquiète. Les ingénieurs se sont toutefois montrés rassurants durant les labs de la WWDC : pour l'heure, un même BitCode ne sera utilisé que pour de toutes petites modifications d'architecture. Mais le risque ne sera jamais nul !
- Quid du versionning ?
Là aussi, on peut s'interroger : le développeur a-t-il encore la main sur ses apps ? Si Apple se charge de compiler les programmes, est-ce qu'une version optimisée pour le A9 sera automatiquement incrémentée sur l'App Store ou dans les numéros de build ? Pour l'heure, aucune information n'a été donnée.
- Quid du debugging ?
En imaginant qu'Apple génère de nouvelles versions des apps automatiquement (ce qui sera de toute façon le cas), comment récupérer les crashlog et débugger les programmes ? A cette question, iTunes Connect va normalement fournir les fichiers DSYMs nécessaires pour remonter à la source des plantages de ses utilisateurs. Cela nous a été confirmé par différentes sources.
- Quid des optimisations CPU ?
Le BitCode est généré durant une étape interne du compilateur Clang/LLVM, et même s'il ne s'agit pas de langage machine, on obtient tout de même un code assez bas niveau. Les optimisations seront évidemment réalisées automatiquement par le compilateur (et par Apple, in fine) mais il sera alors impossible d'inclure du code assembleur, par exemple. Difficile de savoir si aujourd'hui, beaucoup de développeurs iOS optimisent leur code de la sorte, mais sur Mac, il est probable que ces pratiques soient encore relativement courantes dans certains domaines (imagerie, jeux etc.).
- Quid des librairies tierces ?
De tous les développeurs avec qui nous avons pu discuter, c'est là que règne la plus grande incertitude. Il faut dire que cette année, beaucoup ont déjà eu de grandes difficultés à obtenir des versions 64 bits requises par Apple des bibliothèques tierces utilisées abondamment dans les programmes. Avec BitCode, Apple est très claire et c'est même Xcode qui crache le morceau :
You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. Note: This will be an error in the future.
Si pour les libs OpenSource, il est facile d'obtenir de nouvelles compilations, c'est toujours plus compliqué pour les bibliothèques propriétaires. Beaucoup espèrent qu'Apple n'imposera pas le BitCode trop rapidement, comme ce fut le cas pour le 64 bit !
BitCode au coeur du futur d'OS X et d'iOS ? Pas sans un Mac App Store 2.0 !
Si l'arrivée de BitCode sur iOS génère finalement plus de questions que de véritables inquiétudes, son extension au Mac et à OS X parait comme une évidence, surtout avec l'idée d'un Mac ARM en ligne de mire.
Seule différence notable, actuellement, les programmes peuvent encore être téléchargés en dehors du Mac App Store, qui peine d'ailleurs à convaincre les développeurs. Sous le manteau, on parle même de vrai fiasco, la solution d'Apple étant jugée bien trop restrictive en matière de coding et les fameux 30% prélevés ne compensent pas l'apport de visibilité que pourrait apporter la boutique.
Sur le papier, et sans un modèle de distribution centralisé, on est encore loin de pouvoir espérer l'arrivée du BitCode sur OS X. Et même si Apple verrouille de plus en plus son modèle (en obligeant notamment les développeurs à signer leur programme), on ne voit pas bien comment la firme pourra obliger les éditeurs à ne plus distribuer leurs apps comme bon leur semble, sans prendre de très gros risques pour l'avenir du Mac.
