Flutter vs React Native : pourquoi je préfère Flutter aujourd'hui

J’ai longtemps trouvé React Native plus rassurant que Flutter. Quand on vient du web, React Native a quelque chose d’évident : React, JavaScript, des composants, un écosystème immense. On a l’impression qu’on va pouvoir construire une app mobile sans vraiment changer de façon de penser.

J’avais même testé Flutter assez tôt, puis je l’avais vite mis de côté. À l’époque, les animations accrochaient, les transitions n’étaient pas fluides, il y avait des janks visibles. Pour une app mobile, c’était rédhibitoire. L’interface pouvait être bien pensée, si le scroll ou une animation donnait une impression de lourdeur, tout le produit perdait en qualité.

Donc je suis reparti sur React Native. Et pendant un moment, ça avait du sens.

Ce qui m’a fait changer d’avis plus tard, ce n’est pas un benchmark ou un débat de communauté. C’est l’usure. À force de travailler sur des apps mobiles, deux problèmes revenaient trop souvent : la friction autour des builds de release et les différences de rendu entre iOS et Android.

React Native paraît simple au début

React Native est agréable quand on démarre. On retrouve des réflexes de React, on structure vite des écrans, on branche des librairies, on avance. Pour une équipe web, c’est un vrai avantage.

Le problème, c’est qu’une app mobile ne se comporte pas comme une app web. On doit gérer les claviers, les safe areas, les permissions, les gestes, les scrolls, les performances perçues, les stores, les différences de plateforme. React Native simplifie une partie du sujet, mais il ne la fait pas disparaître.

Et quand la complexité revient, elle revient souvent de façon assez pénible : un écran propre sur iOS mais pas tout à fait sur Android, une lib native qui ne compile plus, un cache à nettoyer, une différence de comportement qui oblige à ajouter une condition spécifique.

Rien d’insurmontable. Mais beaucoup de petites interruptions.

Les builds de release restent un vrai sujet

Ce qui m’a pesé, ce n’était pas seulement la boucle de dev locale. C’était surtout tout ce qui tourne autour des vrais builds de release, en particulier l’archive iOS à produire, signer, valider et envoyer sur les stores.

Expo a amélioré pas mal de choses sur ce terrain. L’outillage est plus propre, l’automatisation est meilleure, et une partie de la friction est mieux absorbée qu’avant. Mais au bout du compte, on dépend toujours d’un vrai build natif, avec tout ce que ça implique en temps d’attente, en configuration et en points de contrôle.

À une époque, j’avais aussi mis en place App Center et CodePush pour pousser certaines mises à jour sans repasser par un build complet. Ça allégeait une partie de la friction côté React Native, même si ça ne changeait rien aux vrais builds natifs nécessaires pour les stores.

Avec React Native, j’avais trop souvent l’impression qu’un changement pourtant simple côté produit pouvait finir par rallonger la chaîne de livraison : Gradle, pods, certificats, cache, rebuild, vérification, archive iOS. Même quand on sait gérer tout ça, ça consomme de l’énergie mentale.

Flutter m’a paru plus stable sur ce point. Il y a toujours des builds de release, des soucis iOS ou Android, des détails de store. Mais l’ensemble me donne une chaîne plus cohérente et plus prévisible.

Sur une petite équipe, c’est énorme. La vitesse d’itération n’est pas juste du confort développeur, c’est ce qui permet de polir une interface au lieu de s’arrêter à “ça passe”.

Les différences iOS/Android finissent par coûter cher

L’autre sujet, encore plus important, c’est le rendu.

React Native s’appuie sur des composants natifs. C’est une force quand on veut coller aux plateformes. Mais dans la pratique, j’ai souvent payé cette approche en petits écarts permanents.

Un texte ne prend pas exactement la même place. Une ombre ne rend pas pareil. Un scroll réagit différemment. Le clavier pousse l’écran d’une autre façon. Une animation a l’air correcte d’un côté, moins de l’autre. Un composant accepte une propriété ici, mais pas là.

On peut tout corriger. Le problème, c’est le volume. À force, la promesse “une seule base de code” reste vraie dans Git, mais moins vraie dans le temps passé à stabiliser l’app.

Flutter m’a plu parce qu’il réduit beaucoup cette zone grise. Comme il dessine lui-même l’interface, le rendu est beaucoup plus cohérent entre iOS et Android. On peut toujours adapter certains détails par plateforme, mais on ne passe pas son temps à découvrir des différences de rendu au dernier moment.

Pour moi, c’est probablement son plus gros avantage.

Flutter a aussi eu besoin de mûrir

Je ne veux pas faire comme si Flutter avait toujours été évident. Ma première impression était mauvaise. Les janks que j’avais vus au début m’avaient vraiment refroidi.

Mais le framework a beaucoup évolué. L’expérience que j’ai aujourd’hui n’a plus grand-chose à voir avec ce premier test. Les animations sont fluides, le rendu est propre, l’outillage est plus solide, et l’écosystème est beaucoup plus crédible.

Il reste des défauts. Dart peut être un frein au début. Certains packages ne sont pas au niveau de l’écosystème JavaScript. La navigation, la gestion d’état et l’architecture demandent de vrais choix. Flutter ne supprime pas les contraintes mobiles : certificats, stores, notifications push, permissions, deep links, tout ça reste là.

Mais les problèmes me semblent plus explicites. Je préfère devoir choisir une architecture Flutter claire plutôt que perdre du temps sur des écarts de rendu que je n’avais pas anticipés.

Ce que je perds avec React Native

React Native garde de vrais atouts.

Si une équipe maîtrise déjà React, si le produit web et mobile partagent beaucoup de logique, ou si l’entreprise a déjà une base React Native en production, il n’y a aucune raison de tout jeter. L’écosystème est énorme, les ressources sont nombreuses, et de très bons produits tournent avec React Native.

Et si je dois bosser en React Native pour un client, ça ne me dérange pas. Je peux très bien revenir dessus dans un bon contexte, et peut-être qu’un jour ce sera de nouveau mon choix sur un projet. Je continue d’ailleurs à suivre l’actu de l’écosystème, parce que React Native reste une stack importante et qu’elle évolue encore beaucoup.

Mais dans mon cas, le coût caché devenait trop visible. Le temps perdu dans les builds, les différences iOS/Android, les ajustements spécifiques, les petites surprises de libs natives : tout ça finissait par peser plus que les avantages de rester dans un univers proche du web.

J’avais besoin d’une stack mobile qui me laisse avancer plus régulièrement.

Pourquoi je choisis Flutter aujourd’hui

Aujourd’hui, si je dois démarrer une app mobile avec une petite équipe, je pars plutôt sur Flutter.

Pas parce que c’est parfait. Pas parce que React Native serait un mauvais choix. Mais parce que Flutter me donne une meilleure impression de contrôle : rendu plus homogène, même système de widgets, même logique d’interface, boucle de développement plus fiable.

Le point décisif, pour moi, c’est la fatigue opérationnelle. Attendre moins. Réparer moins d’écarts entre plateformes. Tester plus vite. Garder plus d’énergie pour le produit.

Au final, le meilleur framework mobile n’est pas celui qui gagne un débat théorique. C’est celui qui permet de faire évoluer l’app pendant des mois sans que chaque détail d’interface devienne une négociation avec la stack.