Pourquoi React Native est toujours une bonne solution en 2021

23 février 2021

On ne présente plus React Native en 2021. Bien au contraire, la plupart de ses détracteurs actuels seront plutôt de l’avis que c’est du passé, dû notamment à l’arrivée de technologies comme Flutter ou  les PWA . Nous n’en sommes pas convaincus à Agaetis et nous allons vous expliquer pourquoi dans cet article. La principale raison est évidente : il n’y a pas de solution universelle qui réponde à tous les use-cases de la meilleure façon possible.

Rappel des intérêts de React Native

Avant d’entrer dans les détails, faisons un petit rappel des avantages de cette technologie par rapport à du développement natif (sous Kotlin et Swift). On distingue 3 p oints principaux :


  • L’avantage principal est bien évidemment le partage de code entre les deux plateformes : mêmes équipes de développement, mêmes tests et généralement moins de coûts !

  • React Native profite par ailleurs de la popularité de JavaScript : une communauté plus développée que Kotlin et Swift, donc plus de facilités pour recruter, faire monter en compétences, etc… Il profite également de la puissance de React pour créer des interfaces, après tout,  SwiftUI en est inspiré  ce n’est sûrement pas un hasard ! 

  • Enfin l’environnement de développement est plus “puissant” grâce au caractère interprété du JS face à ces 2 langages compilés, à travers notamment le hot reloading (donc encore des gains de productivité à la clé !).


Évidemment le tout est au prix d’une baisse de performances face à du développement natif, mais cela reste préférable à ce niveau, que des applications web hybrides ou des PWA. React Native a d’ailleurs un autre avantage face à ce type d’applications web : l’utilisation de composants natifs à l’affichage. L’utilisateur a l’impression d’utiliser une application native, en échange d’un démarrage un peu plus lent (on en reparle plus bas).


Représentation schématique du fonctionnement de cette technologie jusqu’à maintenant. A gauche le thread JS qui exécute le code de l’application. A droite en orange le thread “natif” classique (pour l’UI), vers lequel sont transpilés les composants graphiques au lancement de l’application. Le “Bridge” React Native relie le tout pour que l’ensemble fonctionne (par l’échange de messages asynchrones). Enfin on trouve “Yoga”, le moteur de calcul pour l’agencement des composants à l’écran.

Les trois facteurs déterminants pour le futur de React Native : Expo, Hermes et “JSI”

En quelques années, Expo est passé d’un petit framework sur-couche de React Native, à un must have pour la plupart des projets. Dans le même temps, l’équipe de ce dernier travaille à la mise en place du nouveau moteur Hermès qui promet des temps de démarrage bien meilleurs (2x plus rapides !).


Expo

Expo permet à l’origine de répondre au problème principale de React Native pour les développeurs : la dépendance au code natif. En effet, l’abstraction n’est pas complète et il faut toujours y toucher un peu lorsque l’on souhaite accéder à une API hardware (principalement lorsqu’on ajoute la dépendance). Et par ailleurs seuls les développeurs sous Mac peuvent développer et vérifier que l’application fonctionne sur iOS. Ce n’est plus le cas avec Expo, ce framework a indéniablement participé à l’émancipation de React Native.

A l’heure actuelle, le framework continue de se développer et va plus loin, notamment avec un système de mises à jour automatiques sans passer par les stores, à la manière des PWA (pas besoin de gérer de la rétrocompatibilité avec le backend !).

Evidemment Expo étant encore plus récent que React Native, son utilisation ne se fait pas sans contreparties : le support du Bluetooth, par exemple, n’est pas encore disponible. Mais à noter qu’il est possible à tout moment dans la vie d’un projet sous Expo de revenir à du React Native pur.


Hermès

La première fois qu’une application React Native est démarrée, elle va compiler ses composants graphiques en composants natifs (comme vu plus haut). Cette compilation n’est évidemment pas économe en temps et cela peut se faire ressentir ! Mais ce ne sera plus qu’un mauvais souvenir avec le moteur Hermès. Ce dernier va simplement permettre de faire cette étape de compilation au “build” de l’application, lorsqu’on souhaite la déployer sur un store.

Voici deux schémas pour illustrer :



L’équipe de React Native a indiqué que ce moteur allait réduire les temps de lancement de moitié : l’application hybride démarrerais ainsi presque aussi rapidement qu’une application native ! Il y a aussi des améliorations au niveau de l’utilisation de la mémoire ou de la taille du package. Ce moteur est pour l’instant expérimental et disponible seulement sur Android, encore un peu de patience !


JSI

Ce dernier point est bien plus technique. Pour faire simple, le “Bridge” que l’on a vu précédemment va être modifié et amélioré dans une prochaine version de React Native. Cette nouvelle version est appelée “JSI” (pour JavaScript Interface).

Ce Bridge a en effet quelques problèmes liés à son fonctionnement asynchrone. Par exemple, lorsqu’un événement natif comme une demande de scroll est envoyée au code JavaScript, ce dernier va recevoir l’information avec un décalage. Or l’environnement natif n’attendra pas que ce dernier prenne la main pour commencer le scroll, parce qu’il ne peut pas savoir lorsque cela aura lieu. Le natif n’a pas “conscience” de l’existence de la partie JavaScript. Ce délai peut être senti ou visible par l’utilisateur pour d’importantes listes d’éléments.


Le JSI va améliorer cette communication en réduisant la latence et en permettant l’interopérabilité entre les deux univers. Pour faire simple : cela ira plus vite ! Dans un second temps, cette nouvelle interface va permettre de s’affranchir de JavaScriptCore, le moteur JS de Safari. Ainsi, sur Android il sera possible d’utiliser V8 (avec de nouveaux gains de performances à la clé).

Plus d’informations techniques dans  cet article sur Medium  (où c’était annoncé pour 2020), et  sur ce ticket Github  pour suivre où ils en sont, car ils ont pris un peu de retard.

Vous pouvez constater les différences avec le schéma plus haut : Yoga sera accessible directement depuis le JSI (gains de perfs) et ce dernier est à cheval entre les deux “mondes”


Conclusion


React Native est donc toujours un très bon choix pour réaliser une application mobile, lorsque les performances ne sont pas un réel critère ou en tout cas non prioritaire. Nous verrons d’ici quelques années les impacts des améliorations en cours, mais d’ici là, si c’est important pour vous, privilégiez plutôt une application native ou Flutter (sujet d’un prochain article). Cette technologie est toujours un bon choix car l’équipe de Facebook reste dans une optique d’amélioration continue sur le sujet. Ce qui reste certain, c’est que le projet avance dans la bonne direction !

Enfin pour ne pas oublier un fait méconnu, il est possible d’intégrer des écrans React Native  dans une application native déjà existante . Pratique, si vous avez un gros historique et ne souhaitez pas tout réécrire de zéro, ou si vous souhaitez partager entre les deux OS mobiles une partie seulement d’un nouveau développement. Après tout Facebook l’utilisent eux mêmes avec l’application du même nom,  l’onglet Marketplace apparu il y a quelques années est en effet codé en React Native  ! Si vous jetez un œil, vous constaterez… que la différence est invisible. Magique ! 

Ressources Agaetis

par David Walter 6 novembre 2025
Project Context Michelin aimed to develop a new generation of digital services based on data from connected tires. The goal was to deliver added value to truck fleet managers and maintenance centers worldwide. The challenge lay in the collection, processing, and supervision of massive sensor data, while ensuring robustness, scalability, and relevance of analytics. Objectives The main objective was to establish a technical and architectural framework to: Efficiently collect and process data from connected tires Monitor data flows and measure the impact of business use cases Create a Big Data platform ready to evolve with growing data volumes Mission Duration A long-term engagement , combining initial architectural study, implementation of monitoring systems, and ongoing support. Implementation Agaetis leveraged its Data and Cloud expertise to: Initial architecture study: Define technological and structural choices Platform monitoring: Implement monitoring principles to ensure robustness and availability Load analysis: Evaluate the impacts of various business use cases Big Data framework definition: Integrate best practices to accelerate implementation Data Science work: Perform domain-specific analysis and develop new indicators and services Results Achieved New digital services: Creation of innovative solutions for fleet managers Robust and scalable platform: A Big Data environment ready to handle massive data volumes Operational optimization: Improved traceability and KPI tracking Enhanced innovation: Data transformed into strategic levers for Michelin Key Success Factors Agaetis’ expertise in Big Data and IoT data processing End-to-end methodology: From architecture to Data Science Immersion in the client’s business environment Proactive supervision ensuring robustness and reliability  And You? Are you wondering about: Leveraging data from your connected equipment ? Creating new digital services based on Data? Implementing a robust and scalable Big Data architecture ? 👉 Contact our experts to transform your IoT data into innovative, value-generating services.
par David Walter 6 novembre 2025
Project Context France’s first research foundation dedicated to innovation in pain management aimed to launch a market-ready application resulting from its clinical research and development program. The goal was to transform the app into a Digital Therapeutic (DTx) reimbursed by the national health insurance system. Objectives The organization focuses on driving healthcare innovation through extensive collaborations with hospitals, research institutes, universities, and technology companies. The main challenges included: Transforming an application into a Digital Therapeutic (DTx) reimbursed by the national health system. Managing the transition of patients to this new platform. Preparing a new data warehouse to support scientific research. Mission Duration 3 collaborators over 3 years Methodology Agaetis provided its expertise through targeted and structured actions: Audit of existing systems: Evaluation of current infrastructure to identify needs and areas for improvement. Decision support for partner selection: Assistance in choosing competent and reliable technology partners. Technology advisory: Guidance on application architecture, security, and scalability to ensure long-term viability. Results Achieved Development of an application supporting patients in chronic pain management, progressing toward recognition as a reimbursable DTx. Rigorous technical assessment and selection of strategic partners. Adherence to roadmap milestones , ensuring steady progress and alignment with expectations. This project highlights how Agaetis leverages its technological and strategic expertise to transform challenges into innovative, effective solutions — creating tangible value for clients in the healthcare sector.
Show More