React Native : une app mobile sans doubler les équipes

Construire une application mobile pose vite une question coûteuse : une app iOS et une app Android, donc deux équipes, deux codebases ? React Native propose une autre voie : un seul code pour les deux plateformes.

Un code, deux plateformes

React Native permet d'écrire l'application une fois, en TypeScript/React, et de la déployer sur iOS et Android. Pour une équipe déjà familière de l'écosystème React, c'est un gain de temps et de cohérence majeur, et une seule base à faire évoluer.

Un changement technique important mérite d’être connu, parce qu’il rend obsolète une bonne partie des comparatifs en ligne. La « nouvelle architecture » de React Native est activée par défaut depuis la version 0.76 : le pont asynchrone qui sérialisait chaque échange entre JavaScript et le natif a été remplacé par une interface directe (JSI) et un nouveau moteur de rendu (Fabric). Concrètement, l’argument classique du « pont qui ralentit tout » ne tient plus dans les mêmes termes, et les mesures de performance antérieures à 2024 ne décrivent plus l’outil actuel. C’est aussi une raison de vérifier la compatibilité des bibliothèques tierces d’un projet ancien avant de le reprendre.

Quand React Native est le bon choix

• Une app métier, un back-office mobile, un outil de terrain, là où l'expérience n'a pas besoin d'effets natifs extrêmes.
• Un budget et un délai qui ne permettent pas de doubler les développements natifs.
• Un besoin de mode hors-ligne, photo, scan, signature, géolocalisation, tout ça se fait très bien en React Native.

Un point de budget échappe au débat technique et s’applique dans tous les cas : la publication reste soumise aux magasins d’applications. Le programme développeur d’Apple coûte 99 $ par an et son adhésion est obligatoire pour distribuer sur l’App Store ; Google Play impose ses propres frais d’inscription et une vérification d’identité. S’ajoutent les délais de revue à chaque mise à jour, les règles de confidentialité à déclarer et, en cas de vente dans l’application, les commissions. Un code partagé divise le coût de développement ; il ne divise pas le coût de distribution, qui reste double.

C'est typiquement ce qu'on déploie pour les outils métier qui ont une composante terrain.

Quand préférer le natif (ou une PWA)

Pour des applications très exigeantes graphiquement (jeux, animations 3D, accès matériel pointu), le natif garde l'avantage. Et pour un usage purement consultatif, une PWA (application web installable) peut même suffire, sans passer par les stores.

L’alternative de la PWA mérite d’être chiffrée plutôt qu’évoquée, car elle change la nature du projet. Une application web devient installable sur l’écran d’accueil en ajoutant trois éléments, un service worker, un manifeste et HTTPS, dont le guide MDN décrit les conditions exactes. Ce qu’on gagne : pas de compte développeur, pas de revue, pas de commission, une mise à jour immédiate pour tout le monde. Ce qu’on perd : l’accès complet au matériel, dont la couverture varie selon le navigateur et le système, et la découverte par recherche dans les magasins. Pour un outil métier ou un back-office de terrain, l’équation penche souvent vers la PWA ; pour une application grand public, rarement.

Le bon réflexe : cadrer l'usage réel

Mobile natif, React Native ou PWA : le choix se fait sur l'usage réel, pas sur la mode. On l'arbitre au cadrage, sur nos projets de développement d'applications.

Une app mobile en tête ? On regarde ensemble la voie la plus efficace.