Flutter, React Native ou natif : choisir selon des critères

Dans le développement natif, l'application iOS est écrite dans le langage et avec les outils propres à la plateforme, et l'application Android dans les siens. Vous obtenez deux bases de code. Vous avez un accès prioritaire aux nouvelles fonctions de chaque plateforme et le lien le plus direct avec les capacités de l'appareil, mais le travail est fait deux fois.

Flutter est un outil qui dessine lui-même l'interface avec son propre moteur de rendu et utilise le langage Dart. React Native s'écrit en JavaScript ou en TypeScript et affiche l'interface grâce aux composants propres à la plateforme. Les deux visent à publier sur deux stores avec une seule équipe ; ils diffèrent par la façon de produire l'interface et par le langage que l'équipe connaît.

Pour que le choix ne tourne pas au débat technologique, écrivez d'abord les critères et notez chacun pour votre propre produit. Si un critère est critique pour vous, il tranche, quelle que soit la qualité des autres.

La même question est posée à chaque critère : quel risque cette approche comporte-t-elle, au minimum, pour répondre aux besoins de ce produit ? Les réponses ne sortent généralement pas sous forme de chiffres, mais d'une distinction comme « confortable », « demande de l'attention » et « difficile ».

• Équipe : le langage et l'expérience des développeurs que vous avez ou pouvez trouver
• Fonctions de l'appareil : besoins proches de la plateforme, comme l'appareil photo, les capteurs, le Bluetooth et le travail en arrière-plan
• Interface et animation : propre à la marque et très travaillée visuellement, ou l'apparence standard de la plateforme
• Maintenance : qui suivra les mises à jour de version et les changements de bibliothèques des deux plateformes, et comment
• Temps et budget : une équipe ou deux, et l'urgence de la première publication

Si le produit est très proche de la plateforme, par exemple avec un usage intensif de l'appareil photo et des capteurs, un travail qui tourne en continu en arrière-plan, des extensions pour la montre et la voiture, ou un besoin des toutes dernières fonctions de la plateforme dès le premier jour, le natif réserve généralement le moins de surprises. Le coût est l'entretien de deux bases de code et, le plus souvent, de deux équipes.

Si vous voulez que l'interface soit identique et propre à la marque sur les deux plateformes et que l'équipe est prête à apprendre un nouveau langage, Flutter est un candidat naturel. Si votre équipe compte des développeurs web qui connaissent déjà JavaScript ou TypeScript, React Native est le chemin le plus court pour utiliser les compétences existantes, et le partage de code et de connaissances entre le web et le mobile peut aussi devenir plus facile.

Ces phrases décrivent des tendances générales, pas des règles. Des applications réussies, rapides et attrayantes sont écrites avec les trois approches ; les problèmes viennent généralement d'une inadéquation entre le produit et l'outil, pas de l'outil. Avant de décider, un petit essai qui teste l'écran ou la fonction la plus risquée du produit avec chaque candidat raccourcit donc le débat.

Le travail ne s'arrête pas à la publication de l'application. Chaque année, les deux plateformes sortent de nouvelles versions, les bibliothèques changent et les règles des stores sont mises à jour. Avec les outils multiplateformes, ces changements doivent être absorbés à la fois par la plateforme et par l'outil lui-même. En natif, le même changement est fait deux fois dans deux bases de code distinctes.

Le côté humain compte aussi. Demandez-vous qui remplacerait la personne qui connaît l'outil choisi si elle partait, et dans quelle mesure la communauté et la documentation de l'outil sont vivantes. Pesez cela non pas au jugé, mais d'après la situation réelle de votre propre marché pour trouver des développeurs dans ce langage.

• Qui suivra les mises à jour annuelles de version des deux plateformes
• Qui résoudra une incompatibilité de bibliothèque dans l'outil choisi
• Avec quelle facilité on peut remplacer un membre de l'équipe qui part
• À quel point la documentation et la communauté de l'outil sont à jour

L'erreur la plus courante est de laisser le choix à la popularité ou aux arguments lus en ligne. Un outil qui a fonctionné dans une autre entreprise ne donnera peut-être pas le même résultat avec votre équipe et votre produit. La deuxième est de croire que le multiplateforme est toujours moins cher ; une seule base de code réduit le travail de développement, mais les parties propres à chaque plateforme et la maintenance demandent encore des efforts.

La troisième est de ne penser qu'à la première publication au moment de décider. Qui entretiendra l'application dans trois ans compte souvent plus que la rapidité de sortie de la première version.

• Laisser le choix à la popularité ou au débat en ligne
• Croire que le multiplateforme est moins cher dans tous les cas
• Ne penser qu'à la première publication, sans compter la maintenance
• Décider sans avoir essayé la fonction la plus risquée

Si votre produit affiche surtout du contenu, remplit des formulaires et a peu besoin de fonctions comme la présence dans les stores ou les notifications, la vraie question est de savoir s'il doit être une application mobile ou une PWA ; l'une des trois approches de développement découle de cette question. Vérifiez d'abord que le produit a réellement besoin d'une application.

Si vous en êtes encore au stade de l'idée, choisir une technologie est également prématuré. Testez d'abord l'idée avec un prototype ; le choix sera plus sain une fois clair ce qui sera réellement construit. D'autres options existent, mais comprendre le raisonnement derrière ces trois-là vous donne aussi une bonne base pour les juger.