Flutter, natif ou React Native pour une application d'entreprise ?

Une application native s'écrit deux fois : en Swift pour iPhone et en Kotlin pour Android. Avec Flutter, le même code produit les deux applications. Le développement, les tests et chaque évolution ne sont faits qu'une fois, et les deux versions restent identiques.

Sur un projet, cela se traduit par un budget et des délais nettement inférieurs à deux développements natifs (voir le prix d'une application mobile).

Oui pour les usages courants : listes, formulaires, cartes, animations, paiement, notifications, vidéo. Flutter dessine lui-même son interface et la compile en code natif, ce qui donne une application fluide.

Pesto, développée en Flutter, fait par exemple tourner un assistant vocal qui lit les recettes et répond aux questions.

• Une application centrée sur une fonction très récente d'iOS ou d'Android, disponible en natif avant d'être accessible depuis Flutter
• Des widgets d'écran d'accueil, des montres connectées ou des extensions complexes, qui demandent du code natif de toute façon
• Des traitements graphiques ou audio très poussés, comme un jeu 3D ou un logiciel de montage
• Une équipe interne déjà composée de développeurs iOS et Android

Même dans ces cas, on peut souvent garder Flutter pour l'essentiel et écrire en natif seulement la partie concernée.

React Native, porté par Meta, permet aussi une seule base de code pour iPhone et Android. La différence principale : React Native s'appuie sur les composants d'interface du téléphone, alors que Flutter dessine toute l'interface lui-même.

• Flutter donne un rendu identique sur iPhone et Android et des animations fluides, avec le langage Dart
• React Native utilise JavaScript ou TypeScript, ce qui peut convenir à une équipe qui fait déjà du web en React
• Les deux sont matures et utilisés en production par de grandes entreprises

Pour une application d'entreprise développée par un prestataire, le choix dépend surtout de l'équipe qui la maintiendra. Je développe en Flutter.

FlutterFlow et les outils no-code permettent de construire une application visuellement, plus vite au départ. Ils conviennent aux prototypes et aux applications simples. Leurs limites apparaissent quand la logique devient spécifique ou que l'application doit évoluer longtemps : le code généré est plus difficile à maintenir, et vous dépendez de l'outil.