React Native + Expo permet de livrer une app iOS et Android à partir d’une seule base de code, maintenue par une seule équipe. Concrètement, 85 à 95 % du code est partagé entre les deux plateformes : vous écrivez chaque écran une fois, vous corrigez chaque bug une fois, et vous publiez sur l’App Store et Google Play en parallèle. Résultat : un temps de développement et un coût de maintenance divisés par deux par rapport à deux apps natives distinctes, sans sacrifier l’expérience pour l’immense majorité des produits.
Une base de code, une équipe, deux stores
En natif, vous entretenez deux projets en parallèle : une app en Swift pour iOS, une app en Kotlin pour Android. Deux équipes, deux backlogs, deux fois plus de bugs à reproduire et à corriger. React Native inverse la logique : un seul code TypeScript/React pilote les deux plateformes, avec des composants qui s’appuient sur les vrais éléments d’interface natifs. Une fonctionnalité développée le lundi est disponible sur iOS et Android le même jour.
Ce qu’Expo apporte concrètement
- Configuration zéro : pas de Xcode ni d’Android Studio à dompter pour démarrer, l’environnement est prêt en minutes.
- Over-the-air updates : vous poussez un correctif directement aux utilisateurs sans repasser par la validation des stores.
- APIs natives prêtes à l’emploi : caméra, notifications push, biométrie, géolocalisation, paiements in-app.
- Builds cloud (EAS) : générer les binaires iOS et Android signés sans machine macOS locale.
- Un écosystème mature, utilisé en production par des apps à des millions d’utilisateurs.
Les limites : quand ça coince
React Native n’est pas magique. Certaines apps ont des besoins que le cross-platform gère mal, ou moins bien qu’un développement 100 % natif. Les cas à surveiller :
- Calcul ou rendu intensif : jeux 3D, montage vidéo, réalité augmentée temps réel.
- Fonctionnalités matérielles de pointe ou très spécifiques à une plateforme, sorties avant leur support côté React Native.
- Modules natifs personnalisés : dès qu’il faut écrire du Swift ou du Kotlin, vous perdez une partie du bénéfice « une seule équipe ».
- Contraintes de performance extrêmes sur des animations complexes, où chaque milliseconde compte.
Quand préférer le natif
Le natif reste le bon choix quand la plateforme est le produit : une app qui vit et meurt sur ses performances graphiques, ses capteurs avancés ou une intégration système profonde. Pour un jeu AAA, un outil de création vidéo ou une app qui exploite les toutes dernières APIs d’un OS le jour de leur sortie, deux bases natives se justifient. Pour tout le reste — SaaS mobile, marketplace, app métier, réseau social, outil B2B — React Native + Expo couvre 90 % des besoins réels sans compromis visible.
Écrire chaque écran deux fois n’a de sens que si la plateforme est le produit. Sinon, c’est payer deux fois pour le même résultat.
Ce que ça change pour votre V1
Une seule base de code, c’est aussi un seul budget et un seul calendrier. C’est pourquoi Khufu construit ses apps mobiles sur React Native, Expo et NestJS : une V1 réellement publiable sur l’App Store et Google Play, livrée en 7 jours pour un prix fixe de 15 000 €, code source à vous. Vous validez votre marché sur les deux plateformes en même temps, puis vous faites évoluer le produit avec un budget de maintenance mensuel (à partir de 1 490 €/mois) — sans jamais entretenir deux apps en double.