Applications Flutter : un code, deux stores en ligne

Flutter est un framework d'interface développé par Google, écrit en Dart, qui produit des applications fonctionnelles pour iOS, Android, le web et le bureau à partir d'une base de code unique. Il dessine sa propre interface avec son propre moteur de rendu, si bien que le même bouton et la même animation de transition sont identiques sur les deux plateformes.

Le code est compilé en code natif avant d'arriver sur le store ; ce n'est pas une page web qui tourne dans une coque. Cette distinction compte, car en matière de performance et de validation du store, les applications Flutter sont évaluées dans la même catégorie que les applications natives.

Le gain le plus net, c'est le temps. Une nouvelle fonctionnalité s'écrit une fois et part vers les deux plateformes ensemble, plutôt que deux fois selon des calendriers séparés. Un bug se corrige à un seul endroit.

Le second gain concerne l'entretien. Une fois l'application en ligne, le suivi des versions, les mises à jour des bibliothèques et la compatibilité avec le système d'exploitation passent tous par une base de code unique, ce qui permet à une petite équipe de garder l'application en bonne santé plus longtemps sans agrandir ses effectifs.

Le test décisif est simple : la logique métier de l'application (formulaires, listes, un parcours de commande, notifications) se comporte-t-elle de la même façon quelle que soit la plateforme, ou doit-elle se comporter différemment sur chacune. Si c'est le premier cas, Flutter fait gagner un temps réel ; si c'est le second, le gain se réduit rapidement.

Flutter n'est pas la réponse à tous les besoins mobiles. Si l'application n'a qu'à afficher un peu de contenu et que l'utilisateur l'ouvre déjà quelques fois par jour, une PWA peut faire le même travail à un coût bien plus bas ; construire une application de store distincte devient alors un investissement inutile.

Si une équipe dispose déjà de développeurs natifs solides et que le périmètre de l'application repose largement sur des fonctionnalités matérielles propres à une plateforme, passer à Flutter ajoute une courbe d'apprentissage alors que le gain de temps reste limité. Dans ce cas, continuer avec l'équipe native en place a généralement plus de sens.

L'erreur la plus fréquente consiste à sauter les tests sur appareil réel sur les deux plateformes une fois Flutter choisi. Le même code tourne sur les deux, mais le comportement du clavier, le déroulé de la demande d'autorisation et les retours matériels comme la vibration peuvent varier légèrement d'une plateforme à l'autre, et ces différences n'apparaissent que sur un appareil réel.

La seconde erreur consiste à traiter les exigences du store (taille de l'application, textes d'autorisation, règles d'icône) comme une réflexion tardive plutôt qu'un point de départ. Comme évoqué dans notre article sur le processus de soumission à l'App Store et à Google Play, cela peut faire rejeter même une application Flutter bien construite dès la première tentative.

• Publier sans avoir testé sur un appareil réel sur les deux plateformes
• Laisser les textes d'autorisation et les règles d'icône du store pour la fin du développement
• Repousser à la toute fin du projet une fonctionnalité qui nécessite un canal de plateforme

Oui, elles existent. Si l'application repose fortement sur la réalité augmentée, un traitement caméra avancé ou un accès matériel propre à une plateforme, cette partie précise peut nécessiter du code natif via des canaux de plateforme. Flutter le permet, mais ce n'est pas la même chose qu'écrire du natif depuis zéro.

Se pose aussi la question de reproduire au pixel près le langage de design de chaque plateforme. Pour la plupart des applications commerciales, les utilisateurs ne remarquent pas la différence ; pour les marques avec des règles visuelles très strictes, une conversation directe avant de démarrer vaut la peine.

Un fabricant de revêtements de sol voulait que son réseau de revendeurs consulte les niveaux de stock et suive les commandes depuis un téléphone. Plutôt que de monter deux équipes natives, nous avons construit l'application avec une seule équipe Flutter ; même interface, même logique métier, publiée le même jour sur les deux stores.

Chaque fonctionnalité demandée ensuite par les revendeurs a été écrite une fois, testée une fois. Deux équipes séparées travaillant en parallèle auraient considérablement ralenti ce cycle.

Une base de code unique produit toujours deux paquets distincts pour l'App Store et Google Play, mais la source reste unique. Quand une mise à jour sort, elle peut partir le même jour vers les deux stores, sous le même numéro de version.

Au-delà d'un coût de maintenance réduit, cela signifie que les deux plateformes restent à jour en même temps ; aucune plateforme ne traîne en attendant une fonctionnalité.