Experts React Native
iOS & Android cross-platform

Soyons directs : si votre équipe fait du React web ou que vous avez un projet web React existant, React Native est le choix évident — les devs, les types, les composants se partagent entre web et mobile. C'est un avantage structurel qu'aucun argument Flutter ne peut contrer. Flutter gagne quand l'UI est le vrai différenciateur (animations 120fps, interfaces pixel-perfect non-standard) ou quand vous visez aussi le desktop. On maîtrise les deux, on a livré de nombreuses apps RN et Flutter, et notre recommandation est toujours contextuelle. Mais dans la majorité des cas, RN l'emporte.

Meta fait tourner Facebook, Instagram et Messenger sur React Native. Microsoft y fait tourner Teams mobile et Outlook. La question n'est plus là. Ce qui compte, c'est l'implémentation. On a livré des apps enterprise avec SSO (SAML via OIDC bridge), RBAC granulaire, chiffrement local (react-native-keychain + crypto natif), mode offline complet et conformité RGPD avec purge automatique des données. La New Architecture a réglé les derniers problèmes de perf sur les grosses apps : plus de bridge bottleneck, les appels natifs sont synchrones via JSI.

Avec la New Architecture, les performances sont honnêtement indistinguables du natif sur la grande majorité des use cases. Les animations Reanimated tournent sur le thread UI natif — zéro passage par le JS thread. Le cold start avec Hermes est significativement plus rapide grâce au bytecode précompilé. Sur nos projets, nous mesurons des cold starts très rapides, comparables au natif. Pour les cas vraiment intensifs (traitement d'image, ML on-device), on écrit des TurboModules en Swift/Kotlin — c'est du code natif pur, pas un compromis.

On va être transparents. Le budget dépend de la complexité du projet. Une app métier classique (authentification, CRUD, quelques intégrations API, notifications push) démarre à partir de 30k EUR. Le budget évolue ensuite en fonction des fonctionnalités : offline-first, sync temps réel, intégrations hardware ou écosystème complet (app + back-office + API + infra). Le gain RN par rapport au natif double (Swift + Kotlin) est significatif, et surtout une seule équipe à gérer au lieu de deux. On commence toujours par un sprint de cadrage d'une semaine pour poser le périmètre et le chiffrage — pas de surprises.

On ne fait pas de PWA déguisée en app native — si vous voulez une app, on fait une vraie app. Cela dit, le natif pur (Swift/Kotlin) ne se justifie plus que dans des cas très spécifiques : apps avec ARKit/ARCore poussé, jeux 3D, ou exploitation d'APIs système bleeding edge non encore supportées par RN. Pour le reste — apps métier, fintech, e-commerce, B2B — React Native offre la même qualité avec un time-to-market 30 à 40 % plus court. Et comme nos devs maîtrisent aussi Swift et Kotlin, on crée des TurboModules natifs quand une fonctionnalité l'exige.

Honnêtement, ça dépend de ce qu'on construit. Un MVP 5-10 écrans avec auth et backend : 8 à 10 semaines. Une app complète avec offline, temps réel et intégrations multiples : 12 à 16 semaines. Ce qui accélère tout : Expo et EAS Build nous permettent d'avoir un prototype testable sur device dès la semaine 2. Les OTA updates via EAS Updates poussent des correctifs en production sans repasser par la review Apple/Google. Et notre CI pousse une beta à chaque merge, donc le client teste en continu, pas une fois à la fin.