Depuis 2007 et l’arrivée de l’iPhone, le paysage informatique a évolué dans des proportions difficiles à imaginer les années précédentes. Moqué par certains à sa sortie, le smartphone d’Apple est le point de départ d’une révolution qui a bouleversé la relation que nous avons avec la technologie. Consommation d’information, relations interpersonnelles, travail, services, tout a été chamboulé par l’explosion de ce nouveau marché, étroitement lié à l’augmentation des usages d’Internet dans le grand public.
En coulisse, ce sont les programmeurs qui ont dû réinventer leur métier en fonction des évolutions des habitudes et des outils disponibles. Une transformation qui continue d’être un casse-tête, à une époque où certaines applications se doivent d’être disponible partout, depuis le web jusqu’aux smart TV. Même en se limitant à iOS et Android, le challenge reste entier. Faut-il développer une application hybride ? Native ? Avec quel framework ? Nous allons tenter d’y voir plus clair tout en expliquant ces concepts aux non-programmeurs.
Le don d’ubiquité
Quand une société développe une nouvelle application, devoir l’adapter aux spécificités de chaque système d’exploitation est souvent perçu comme une problématique majeure. C’est synonyme pour certains de perte de temps, d’argent, d’une maintenance plus complexe, avec potentiellement à terme des évolutions sur chaque version, qui peuvent parfois amener à des divergences entre les OS et donc à une confusion chez les utilisateurs.
Dans ces conditions, certaines sociétés ont eu des envies d’harmonisation entre les plateformes, malgré l’inévitable nivellement par le bas que ça apporte. Ce rêve de ne coder qu’une fois son application puis de pouvoir la déployer partout concerne énormément d’acteurs de l’industrie informatique : Facebook, Google, Microsoft, ou encore des services comme Netflix ou Spotify pour ne citer que des noms très connus.
Entrée en scène des frameworks
Devant ce challenge, de nombreux travaux ont été entrepris pour mettre en place de nouveaux modèles de développement, capables de faire gagner du temps en évitant de devoir réinventer la roue à chaque fois. Sans être innovant, le concept de framework gagne soudain en visibilité, en proposant des atouts indéniables.
Mais qu’est-ce qu’on entend par cet anglicisme que l’on retrouve à toutes les sauces ? Les traductions françaises vont du classique « infrastructure logicielle » aux plus osés « cadriciel, canevas », et autres « socle d’applications, cadre d’applications, etc. » La définition Wikipédia reste un peu indigeste pour le néophyte, mais a le mérite d’être précise :
« En programmation informatique, un framework désigne un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel (architecture). Un framework se distingue d’une simple bibliothèque logicielle principalement par :
- son caractère générique, faiblement spécialisé, contrairement à certaines bibliothèques ; un framework peut à ce titre être constitué de plusieurs bibliothèques, chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : communication de données, data mapping, etc.
- le cadre de travail qu’il impose de par sa construction même, guidant l’architecture logicielle voire conduisant le développeur à respecter certains patrons de conception ; les bibliothèques le constituant sont alors organisées selon le même paradigme.
Les frameworks sont donc conçus et utilisés pour modeler l’architecture des logiciels applicatifs, des applications web, des middlewares et des composants logiciels. Les frameworks sont acquis par les informaticiens, puis incorporés dans des logiciels applicatifs mis sur le marché, ils sont par conséquent rarement achetés et installés séparément par un utilisateur final. »
Pour simplifier à l’extrême, on parle souvent de boîte à outils, voire de briques de Lego : en exploitant un framework adapté à son projet, on peut aller piocher dans des fonctions existantes pour gagner du temps. La métaphore est un peu rapide, mais elle fonctionne. L’autre avantage, c’est d’offrir un cadre préexistant aux développeurs, qui n’en seront que plus efficaces et éviteront de se perdre dans l’architecture de leur code sur des projets complexes.
Il existe donc des frameworks dédiés à tous les secteurs, avec des champs d’application très variés, mais ceux qui nous intéressent particulièrement dans ce dossier sont dédiés au développement mobile.
L’ère « Mobile First »
Les usages modernes font qu’un nouveau service passe souvent par le triptyque « application web / app mobile iOS / app mobile Android ». Ce cas de figure très répandu a donné naissance à toute une catégorie de frameworks qui promettent tous d’atteindre plus ou moins le même nirvana pour programmeur : développer une seule fois le produit et pouvoir le déployer partout. En 2021, cette promesse reste compliquée à tenir, même en acceptant les limitations qu’elle apporte.
Dans les faits, il existe aujourd’hui trois options pour développer une application mobile :
- un développement natif, qui va tirer parti des spécificités de son système d’exploitation, et offrir un résultat optimal en termes de performances, de design et d’expérience utilisateur.
- un développement hybride, qui mélange développement natif, spécifique à l’OS hôte, et développement web. Une app hybride est généralement constituée d’un container natif qui va afficher du contenu tiré du Net.
- le développement d’une webapp, qui utilise le strict minimum de son OS hôte pour se lancer, et s’exécute en utilisant uniquement des ressources et technologies issues du monde du web. Ça peut également être un projet 100% web, sans rien à installer.
Chaque option a un intérêt, et toutes bénéficient de solutions dédiées pour faciliter la création d’application. Malheureusement, malgré les progrès des apps web et hybrides, seules les applications natives offrent aujourd’hui un confort optimal. C’est particulièrement évident sur iOS, ou rien que la différence d’interface est souvent frappante sur les webapps, compte tenu de l’homogénéité du système. Les apps hybrides masquent mieux ce problème. Attention : ça ne veut pas pour autant dire qu’une webapp ne sera pas utile et qu’il faut absolument fuir cette méthode. Il est simplement important d’être conscient des limitations qui y sont associées.
L’embarras du choix
Histoire de brouiller un peu plus les cartes pour les développeurs qui ne suivent pas l’actualité de manière assidue, le monde des frameworks et languages est en constante évolution. L’offre est pléthorique : React Native, Kotlin, Flutter, Xamarin, Ionic, NativeScipt, Framework7, Titanium, jQuery Mobile, Sencha Ext JS, Mobile Angular UI, etc. On peut continuer la liste longtemps ! Certains sont open source, d’autres propriétaires, voire payants, et évidemment ils sont loin d’être équivalents. Outre leurs forces et faiblesses, ils sont aussi dédiés à des usages spécifiques. Il faut également vérifier la communauté autour de chacun, pour s’assurer de ne pas miser sur une technologie déjà sur la pente descendante, voire carrément bientôt abandonnée ! En plus de coder, le programmeur doit donc aujourd’hui réaliser une veille permanente de son domaine. C’est une évidence pour certains, mais c’est loin d’être acquis pour l’ensemble de la profession.
Hybride vs. Native.
Le choix cornélien sur un projet moderne qui veut éviter de faire une webapp à 100% est de définir s’il est pertinent de partir sur une application native, qu’il faudra donc totalement adapter sur plusieurs OS, ou si un développement hybride est envisageable. Parfois, ce choix d’une app hybride sera forcé par des contraintes budgétaires : tout le monde ne peut pas s’offrir le luxe de développer une application Android avec Kotlin ou Java et de faire en même temps la version iOS en Objective-C ou Swift.
Si en plus le but est de sortir l’application sur beaucoup d’autres plateformes, la balance peut rapidement pencher vers l’hybride, surtout que les succès sont assez nombreux avec cette technologie : Instagram, Facebook, Pinterest, Netflix et bien d’autres sont des apps mobiles hybrides.
Le succès du framework React Native, lancé par Facebook en 2015, a contribué à augmenter significativement la popularité des apps hybrides en quelques années, mais c’est loin d’être le seul. Ionic est également très utilisé. Ce framework, construit autour d’autres technologies web reconnues (AngularJS et Apache Cordova) offre des outils efficaces, et est réputé pour permettre de coder des interfaces très réactives qui offrent une expérience utilisateur satisfaisante.
Chez Google, la star du moment s’appelle Flutter. Disponible depuis 2018 en version 1.0, ce framework dispose d’un moteur de rendu 2D nommé Skia, qui a déjà largement fait ses preuves. C’est une option intéressante pour qui veut donner à son app hybride un look le plus « natif » possible, sans parler de la réactivité qui sera meilleure, au prix de développements spécifiques. Plus jeune que ses concurrents, l’app la plus connue basée sur Flutter est Google Ads, qui permet de gérer des campagnes de publicité Google directement depuis son smartphone.
Le natif contre-attaque
Comme dans tout projet informatique, le choix de la méthode de développement d’une application mobile sera déterminé par le projet. Oui, le budget est évidemment un paramètre inévitable, mais il faut comprendre que l’option de l’app native est parfois la seule route possible, surtout pour les développements complexes.
Que ce soit pour iOS ou Android, développer une app native permet d’exploiter au mieux les capacités hardware de chaque appareil, mais aussi de tirer parti de fonctions cruciales du système d’exploitation. Cet accès direct, associé à l’exploitation optimale des performances est indispensable pour certains usages. Outils de montage vidéo, jeux les plus gourmands ou encore la MAO, où iOS reste intouchable en proposant des fonctions qui permettent aux apps de communiquer entre elles, sont des secteurs où le développement natif est une évidence.
La sécurité est aussi plus facile à garantir avec un développement natif, ou l’application va majoritairement s’exécuter directement sur le smartphone et contrôler au mieux ses interactions avec des serveurs distants. Ça permet au passage d’exploiter plus rapidement de nouvelles fonctions de l’OS, parfois liées au hardware, comme FaceID à sa sortie sur iOS. Et même si dans notre monde hyperconnecté on a tendance à l’oublier, le natif est aussi le seul moyen de s’assurer qu’une application puisse fonctionner hors-ligne, si son usage s’y prête.
Cultiver la différence
L’uniformisation des applications qu’apportent certains frameworks n’est pas forcément vue d’un bon œil par les constructeurs. Il faut pouvoir mettre en avant des usages uniques pour justifier l’achat de tel ou tel modèle de smartphone. Pour faciliter la vie des programmeurs, Google et Apple proposent donc chaque année des évolutions de leurs différents SDK (software development kit).
Objective-C n’est ainsi plus le passage obligé pour coder sur les machines d’Apple. Non seulement Swift modernise la façon de programmer sur tous les OS de l’écosystème aux pommes depuis 2014 (iOS, iPadOS, macOS, tvOS, et watchOS), mais SwiftUI simplifie grandement la mise en place d’interfaces de qualité, avec des outils interactifs qui surprendraient plus d’un programmeur du début des années 2000.
Côté Google, on travaille aussi constamment sur ses outils de développement natifs. Jetpack Compose est ainsi leur dernier outil en date pour coder des interfaces natives plus efficacement, outil qui s’interface logiquement avec Kotlin, un langage de programmation moderne pour Android. Cette évolution de Java permet d’utiliser du code classique en même temps, afin de ne pas trop bousculer les habitudes. Une transition en douceur donc, mais que Google entend motiver, en utilisant majoritairement Kotlin sur ses propres applications pour montrer l’exemple.
Du reste, Kotlin est un projet avec des volets encore plus ambitieux, et vise à allier les forces du développement natif avec le développement multiplateforme. Kotlin Multiplatform Mobile (KMM) a pour but de permettre de générer à la fois l’application iOS et son pendant pour Android à partir d’une même base de code. Il restera à analyser l’efficacité réelle de cette méthode. Certains développeurs argumenteront, chiffres à l’appui, qu’il est actuellement plus difficile de maintenir deux applications dans une seule codebase que deux applications avec deux codebases. Les spécificités de chaque projet rendent ce genre d’affirmation difficile à vérifier.
Et demain ?
C’est le retour de cette quête du Graal dont nous parlions précédemment : disposer de frameworks / SDK mobiles capables de générer des applications, cette fois natives, pour tout le monde. Plus de nivellement par le bas, plus d’obligation de se contenter de technologies issues du web. L’omniprésence d’Android et d’iOS, l’existence de leurs outils de développement open source, laissent entrevoir un futur où cela serait possible. Kotlin ambitionne de gérer d’autres plateformes, le web en tête, ce qui en fait un des projets les plus importants à surveiller actuellement. Difficile de prédire si ces travaux se concrétiseront de manière bénéfique pour les développeurs, mais si l’informatique nous a bien appris une chose depuis sa création, c’est que ses évolutions constantes bousculent les règles et les habitudes en permanence. Et c’est ce qui rend ce domaine si passionnant !