Flutter — Le nouveau paradigme

En février, lors de la MWC 2018, le nouveau framework mobile Flutter a été rendu disponible en béta. S‘il reste encore un challenger de petite envergure par rapport aux méthodes actuelles (et bien implantées) de développement mobile, le fait est que Flutter constitue un nouveau paradigme extrêmement intéressant pour toutes les entreprises qui reposent sur une application mobile.

Pour comprendre pourquoi, passons en revue ce qui se fait jusqu’à présent :

Historique des paradigmes

Les SDK d’origines

En 2008, un an après la sortie du premier iPhone, Apple lance l’AppStore et la possibilité d’installer et d’utiliser des applications tierces. Pour cette occasion est publié le SDK iOS qui permet aux développeurs de coder des applications spécifiquement conçues pour l’iPhone. C’est un environnement complètement nouveau et unique en son genre, qui obéit à ses propres règles et possède ses propres limites, très différentes de celles d’une application Desktop, fut-elle pour Mac.

Quasiment dans le même temps, Google fait de même en déployant l’Android Market, ainsi que son propre SDK pour développer des applications spécifiquement et uniquement conçues pour Android comme les applications iOS le sont pour l’iPhone (puis l’iPad).

Chacun de ces deux SDK constitue son propre univers indépendant. Pour des raisons de langage, d’une part, mais aussi et surtout parce que les outils de développement proposés sont intrinsèquement liés au système auquel ils sont destinés, car une application conçue nativement pour un OS fait appel directement à du code de cet OS.

Par conséquent, puisqu’il est si différent de développer une application native pour iOS et une application native Android, cela implique plusieurs choses. Car d’un côté, chaque application (iOS et Android) sera parfaitement intégrée pour son environnement, et pourra tirer partie des fonctionnalités spécifiques à son OS. Mais ce seront deux applications totalement distinctes dans le fond; cela requiert deux (groupes de) développeurs, donc un budget plus important, et nécessite de maintenir deux applications, chacune ayant son lot de bugs et d’améliorations potentielles.

Les Hybrid Web Apps

Un autre paradigme d’application s’était développé depuis l’iPhone, celui des Web Apps. Paradigme qui d’ailleurs fut encouragé par Apple avant que ne sorte en 2008 le SDK iOS pour permettre d’installer directement des applications. L’idée était la suivante : à défaut de pouvoir installer des applications sur le téléphone, pourquoi ne pas exécuter un code distant sur une page web ?

Or, surfant sur la frustration de devoir concevoir deux applications indépendantes pour un même produit, ce paradigme a continué de se développer sous les formes que l’on connait aujourd’hui avec Ionic, Cordova, etc… dans une forme hybride. C’est à dire que l’on crée une application dont la seule partie native est d’afficher une page web, tandis que le reste du code est interprété comme s’il venait d’un site. Les fonctions du smartphone (Bluetooth, localisation, appareil photo) étaient accessibles via un bridge JavaScript, raisonnablement efficace pour cet usage.

Etant donné qu’il s’agissait de travailler avec des technologies web, les compétences requises étaient beaucoup plus populaires parmi les développeurs. D’autant plus qu’une seule équipe pouvait alors suffire. Faire développer une telle application était donc relativement simple…

A ceci près que rendre du contenu dans une page web sur mobile posait rapidement des problèmes de performances, ce qui affectait sensiblement l’expérience utilisateur. (Il semblerait cependant que ce procédé ait connu depuis quelques améliorations).

Les Hybrid Native Apps

Cette méthode propose une approche plus subtile : au-lieu de retranscrire du JavaScript dans une page web, on va concevoir une application en JavaScript que l’on peut adapter à l’univers Android / iOS. C’est pour l’instant l’approche “write once, run everywhere” réputée la plus efficace.

Efficace car, à l’instar des hybrid web apps, ce type de développement fait appel à des compétences très proches de celles du web, et donc peut être pris en charge par un grand nombre de développeurs. Tant et si bien d’ailleurs que ces frameworks jouissent aujourd’hui d’une très grande popularité. De plus, c’est une approche très universelle puisqu’elle ne nécessite vraiment qu’un seul code (et presque qu’un seul langage pour ce qui est du React Native). Ainsi, faire développer une application dans ce paradigme peut s’avérer assez rapide, pour des résultats très satisfaisants.

Cependant, la pierre angulaire des frameworks tels que React Native repose sur le bridge, qui fait le lien en temps réel entre l’application qui a été écrite et le code de l’OS, aussi bien objets graphiques que fonctions du smartphone. Ce qui implique deux choses :

• Le code de l’application dépend encore massivement de l’OS, puisqu’elle est entièrement construite à partir de ce qui disponible dans cet OS. De fait, un changement dans l’OS peut avoir des conséquences sur l’application elle-même.
• Le bridge devient dans certains cas un goulot d’étranglement qui altère les performances de l’application. C’est la transcription du code JavaScript en quelque chose d’exploitable par l’OS qui pose le plus limitations.

Viens Flutter…

Flutter est fondé sur un paradigme plus ambitieux et radical (notamment en terme d’interface) dont l’idée fondatrice tient en ces termes : au-lieu d’essayer d’utiliser les méthodes définies par l’OS, on les court-circuite simplement.

Autrement dit, il s’agit de s’affranchir au mieux de tout ce qui dépend de l’OS, et de n’utiliser que le strict minimum pour avoir le plus grand contrôle possible sur le fonctionnement de l’application.

A la recherche de l’universalité

Flutter exploite une technique que l’on peut appeler BYOT (Bring Your Own Tools) : chaque application Flutter vient en réalité avec son propre lot de fonctions, d’objets graphiques, son moteur graphique, son gestionnaire d’interface, etc… pour être totalement indépendant de l’OS dans ses hautes sphères, et pour exploiter directement, avec ses propres outils, le hardware du smartphone.

Par conséquent, chaque application a un poids un peu plus conséquent que ce que l’on pourrait attendre, étant donné qu’il faut à chaque fois intégrer de quoi la faire fonctionner.

Mais l’intérêt sous-jacent, c’est qu’elle ne dépend plus de l’OS sur lequel elle tourne. C’est à dire que les problèmes de compatibilité ne se posent plus avec d’anciennes versions d’un OS (on peut lancer une app Flutter sur Android 4.3, sorti en 2012, et iOS 8.0, sorti en 2014), ni à sa mise à jour vers une version plus récente. Il en résulte donc qu’il est possible d’atteindre quasiment 100% des smartphones avec une même application / un même code.

Optimisation

S’affranchir de l’OS a une deuxième conséquence : celle de l’optimisation, notamment en terme de rendu d’interface. En effet, puisque les objets graphiques dont on dispose ont été conçus avec le moteur de rendu de Flutter en tête, la méthode de rendu a pu être ajustée finement pour être la plus minimale possible, et la plus efficace sur mobile.

Contrairement à des technologies cross-platform précédentes, où tout ce qui se trouve à l’écran est redessiné au moindre changement (donc jusqu’à 60 fois par secondes) en passant soit par un bridge, soit par une page web, avec Flutter, seul ce qui change entre deux images est redessiné, et ce avec son propre moteur de rendu.

Rapidité

Un autre élément différentiateur dans ce nouveau paradigme découle du fait qu’il n’est pas nécessaire de passer par un bridge. Parce qu’une application Flutter est compilée une fois pour toute, il n’y a pas de processus sans cesse actif pendant son exécution pour faire le pont entre le code de l’application et les services de l’OS qui ne peuvent être court-circuités, comme ce serait le cas avec celles développées en JavaScript. Ce qui est d’autant plus intéressant qu’il peut s’agir dans certains cas d’un facteur très impactant pour les performances de l’application.

Flexibilité et sécurité

Parce que tout ce dont a besoin une application Flutter pour fonctionner se trouve est incorporé intrinsèquement, elle ne risque pas d’être altérée ou modifiée par une mise à jour, soit de l’OS, soit des ressources Flutter, sauf si ces changements ont été incorporés dans l’app par le développeur.

Processus de développement

Flutter apporte aussi un lot de fonctionnalités qui permettent un flux de développement très efficace et rapide, parmi lesquelles :

• Code unique cross-platform, à langage unique également
• Compilation en direct pendant le processus de développement uniquement
• Pas de layout à composer manuellement
• Recharge à la volée de l’application pendant le développement
• Dart, un langage très proche de JavaScript, doc accessible à la majorité des développeurs aujourd’hui

La conséquence est immédiate, puisqu’un développement rapide faisant intervenir peu de ressources humaines entraîne des coûts mesurés, aussi bien d’un point de vue temporel que financier.

En résumé

Faisons l’hypothèse que vous êtes à la tête d’une entreprise et que vous souhaitez proposer au public une nouvelle application. Plusieurs paradigmes sont envisageables :

• le natif iOS / Android, qui est très optimisé mais qui nécessite de faire développer deux applications pour un même produit;
• l’hybride web app, qui, sous réserve d’une bonne construction de projet, permet de joindre site web et application, mais qui peut s’avérer limité en terme de qualité d’expérience utilisateur mobile;
• l’hybride natif, pour des applications de qualité, mais qui souffre d’une double dépendance imbriquée vis-à-vis de l’OS et du bridge entre l’app et l’OS;
• Flutter, ou le BYOT, encore marginal et en croissance, mais au concept prometteur de s’affranchir au possible de l’OS.

Bien qu’étant encore à un état embryonnaire par rapport à d’autres environnement puissants et bien implantés dans la communauté, Flutter constitue un nouveau paradigme de développement qui mérite la considération des entreprises désireuses de déployer une nouvelle application. Il propose une approche radicale de la manière de construire une application capable de tourner à la fois sur Android et iOS.

Flutter rend accessible la possibilité d’un développement rapide, pour une application fiable, optimisée et surtout absolument universelle. C’est à dire des coûts de développement limités et un produit final de qualité.

En somme, le meilleur des deux mondes…