Flutter ou React Native : choisir une pile multiplateforme

Si vous développez une application mobile sans vouloir maintenir deux bases de code natives distinctes, le choix pratique se résume aujourd'hui à deux frameworks : Flutter et React Native. Nous développons en Flutter, mais la réponse à « lequel choisir ? », c'est que les deux sont bons et que le bon choix dépend davantage de votre équipe et de votre produit que d'un quelconque benchmark.

Voici ce qui les distingue réellement, et comment nous vous aiderions à trancher.

La différence d'architecture fondamentale

Les deux frameworks résolvent le même problème de manières fondamentalement différentes, et presque tout le reste en découle.

• Flutter dessine sa propre interface. Il embarque un moteur de rendu et dessine lui-même chaque pixel, si bien qu'un widget a le même aspect et le même comportement sur toutes les plateformes et versions de l'OS. On écrit en Dart, un langage typé conçu pour cela.
• React Native s'appuie sur les composants natifs. Il associe vos composants JavaScript ou TypeScript aux vrais widgets natifs de la plateforme : l'interface est donc réellement native et hérite à la fois des atouts et des particularités de ces widgets sur chaque plateforme.

Aucune des deux approches n'est mauvaise. Flutter sacrifie un peu de fidélité à la plateforme au profit d'une cohérence et d'un contrôle totaux ; React Native sacrifie un peu de cohérence au profit des composants natifs et du vaste écosystème JavaScript.

Pourquoi nous développons en Flutter

Pour les applications que nous construisons, la cohérence et le typage de Flutter l'emportent. Comme il dessine sa propre interface, le comportement ne dérive pas d'une plateforme à l'autre et ne vous surprend pas sur une ancienne version de l'OS : ce que vous testez est ce que les utilisateurs obtiennent. Le typage fort de Dart, associé à des modèles immuables et à une gestion d'état prévisible, garde une grosse application maintenable à mesure qu'elle dépasse les premiers écrans. Et un seul chemin de rendu signifie un seul modèle mental pour toute l'interface, pas deux.

En pratique, ces choix façonnent le code dès le premier écran : un état typé et immuable, une seule base de code Dart pour Android et iOS, et une seule équipe responsable des deux plateformes. Les fonctionnalités s'écrivent une seule fois, et il n'y a pas de fork natif à garder synchronisé.

Quand React Native est le meilleur choix

Nous orienterions certaines équipes vers React Native :

• Votre équipe vit déjà dans JavaScript ou TypeScript et React : le langage et les compétences partagés sont un gain de productivité réel et immédiat.
• Vous voulez partager de la logique avec une application web React existante.
• Votre application repose fortement sur des composants d'interface natifs, et vous voulez qu'ils soient exactement ceux de la plateforme.
• Vous recrutez sur un marché où les profils React Native sont bien plus faciles à trouver que les profils Dart.

Le framework compte moins que l'adéquation. Une équipe qui livre sereinement avec la pile qu'elle connaît battra une équipe qui se débat avec une pile inconnue, quel que soit le logo sur la boîte.

Ce que les deux font bien

Quel que soit votre choix, vous remportez le gros lot : une base de code, une équipe, des fonctionnalités qui arrivent sur les deux plateformes en même temps, et rien de la « taxe du double développement » des applications natives séparées. Les deux sont matures, bien soutenus et utilisés en production par des applications sérieuses. C'est un problème vraiment agréable à avoir : il n'y a pas de mauvaise option ici, seulement une meilleure adéquation.

Quand renoncer au multiplateforme

Une réserve : si toute la valeur de votre application repose sur des API de plateforme de toute dernière génération, ou si vous avez besoin du summum des performances de la plateforme pour des graphismes temps réel exigeants, par exemple, des applications iOS et Android entièrement natives peuvent encore être le bon choix malgré le double coût. C'est une minorité d'applications, mais elle existe, et nous vous dirons si vous en faites partie.

Si vous pesez ce choix pour un vrai produit, nous serons heureux d'en discuter au regard de votre équipe et de vos objectifs plutôt qu'à partir d'une liste de contrôle générique.