Apple et Google possèdent, à eux deux, plus de 99,5% du marché des Systèmes d’Exploitation du mobile (chiffres du dernier trimestre 2016). Toutefois, il existe les développeurs d’applications iOS (Objective-C) et les développeurs d’applications Android (Java).
La révolution d’Apple ( IOS ) : le langage Swift
Swift est apparu comme le successeur logique de l’Objective-C, qui était le langage natif pour le développement d’applications iOS et MacOS depuis son apparition en 1983. Cet anglicisme signifie « rapide », et cela annonce bien la volonté de l’entreprise. Ce langage compilé permet une intégration aisée avec l’Objective-C (mais aussi avec C/C++). Certaines applications présentent par ailleurs une mixité de ces 2 langages dans leur code source, puisqu’ils peuvent coexister.
La déferlante « Swift » attire les jeunes développeurs
Le langage est encore jeune, mais les développeurs ne tarissent pas d’éloges à son sujet. En effet, Swift se veut beaucoup plus lisible et facile d’utilisation que son ancêtre Objective-C. En terme de syntaxe, il s’inspire de l’Objective-C bien sûr, mais aussi de Ruby, de Python et de C#. Il est assez aisé à prendre en main pour un utilisateur novice en la matière. En termes de performances, les différences sont moins probantes. Si Apple annonce une rapidité des applications codées en Swift jusqu’à 220 fois supérieure à celle des autres langages, les tests effectués par les développeurs d’application iOS ne reflètent pas vraiment ces chiffres vertigineux. Toutefois, le langage évoluant beaucoup, les performances s’améliorent. Dans sa version 3.0, les temps d’exécution en Swift sont de l’ordre de ceux de C++. Dans sa version 4.0, la durée des opérations sur la mémoire sera particulièrement travaillée. Cette amélioration significative de l’expérience de l’utilisateur final pousse naturellement les nouveaux développeurs à se tourner vers le langage Swift plutôt qu’Objective-C.
Apple et l’open source : un bouleversement dans les habitudes
En 2015, dans sa version 2.0, le langage Swift est devenu open source. Cette stratégie d’Apple vise à permettre aux utilisateurs d’enrichir grandement les bibliothèques de programmation et donc de susciter un attrait encore plus important. Avec ce passage à l’open source, la firme, habituée à contrôler le Hardware comme le Software, change de créneau et devient contributrice open source. De plus, Apple propose un compilateur Linux. Grâce à ce compilateur, il est donc possible de créer du code back-end en Swift ! Ainsi, un même code Swift est rendu utilisable sur iOS, OS X, WatchOS, et Linux. Ce qui conduit à se demander si on ne pourrait pas aller un peu plus loin…
Un langage « made by Apple » pour Google ?
A priori, cela pourrait sembler insensé. Les deux géants sont réputés pour s’opposer en tout point. De plus, avec plus de 10 millions de développeurs Java dans le monde, qu’est-ce qui pourrait bien pousser Google à changer de langage de programmation ? La réponse est simple : un différend d’ordre juridique avec Oracle, pour une affaire de droits d’utilisation de certaines APIs Java nécessaires au fonctionnement de la JVM de Google pour Android : Dalvik. La procédure est en cours depuis 2010 et pourrait bien coûter quelques milliards de dollars au leader des moteurs de recherche. Début 2016 à Londres, Google, Facebook et Uber se sont réunis suite au passage de Swift en open source afin d’évoquer les possibilités offertes par ce langage. Si Facebook et Uber se sont montrés très intéressés par la facilité d’interaction entre les front-ends et les back-ends, l’utilisation de Swift par Google s’avère plus compliquée.
Un équilibre opportunités / contraintes à mesurer
Si certaines applications iOS comme Vimeo, Airbnb ou LinkedIn sont totalement codées en Swift, il n’existe pas pour le moment d’applications Android utilisant ce même langage. Et pour cause : les bibliothèques (dont les éléments d’interface graphique) utilisées sous Android sont développées quasi uniquement en Java. Or, il n’existe pas de pont entre ces 2 langages. Les APIs de bas-niveau nécessitent donc d’être réécrites afin d’être utilisables pour une application en Swift, ce qui représente un travail important pour Google. Un autre frein est la différence des environnements d’exécution entre Java et Swift : il faudrait désactiver les fonctionnalités non compatibles Android dans Swift et apporter des modifications au compilateur pour prendre en compte une plateforme Android en sortie.
Au niveau des avantages, le langage développé par la marque à la Pomme n’est pas en reste : moins d’erreurs de code grâce à l’inférence de types qui soulève des erreurs à la compilation, un accès limité aux pointeurs mémoire limitant les failles de sécurité, l’initialisation forcée des variables utilisées…
Google a tranché lors de la Google I/O 2017
La firme de Mountain View a annoncé le support de Kotlin pour les applications Android. Kotlin est un langage développé par JetBrains, assez proche de Swift en termes de syntaxe. On retrouve de nombreux avantages de ce dernier, même si Kotlin est moins rapide. Kotlin a l’avantage d’être interopérable avec Java, et fait ses preuves depuis quelques années déjà. Il est, de plus, compatible avec Eclipse et Android Studio, et sera d’ailleurs le langage par défaut d’Android Studio 3.0. Il sera également possible de convertir automatiquement un fichier Java en Kotlin et le copier/coller, et cela permettra de transformer du code source Java en code source Kotlin.
Un avenir en commun encore possible
Malgré les choix récents de Google, je terminerai cet article en disant qu’il n’est pas impossible que l’on finisse tout de même par développer des applications Android en Swift. Plusieurs raisons qui m’amènent à cette conclusion : maintenir Objective-C est coûteux pour Apple, ce qui va motiver à enrichir Swift pour, petit à petit, ne plus utiliser que ce langage. Ensuite certains développeurs comme Romain Goyet se sont essayés avec succès à l’écriture d’une application Android entièrement en Swift, ouvrant le champ des possibilités. Enfin, Google sera de plus en plus présent sur iOS au travers de Google Assistant notamment, donc pourquoi ne pas envisager une présence accrue d’Apple sur Android ?
