L'essentiel sur le développement React Native avec Nehos

React Native est le framework mobile de Meta qui permet de développer des applications iOS et Android en JavaScript/TypeScript avec des composants natifs. En 2026, React Native est utilisé par plus de 2 000 applications dans le top 500 des stores (source : Statista Mobile Framework Report 2025), dont des applications critiques chez Meta (Instagram, Facebook), Microsoft (Teams, Outlook Mobile), Shopify (Shop App), Discord, et Coinbase. La New Architecture — Fabric (nouveau moteur de rendu) et TurboModules (nouveau système de modules natifs) — est stable depuis React Native 0.76 et activée par défaut sur Expo SDK 52. Cette architecture élimine le pont asynchrone JavaScript-Native qui était le principal goulot d'étranglement de performance des versions précédentes. En 2026, React Native n'est plus un compromis — c'est une plateforme de développement mobile mature.

Pourquoi React Native plutôt que Flutter ? La réponse honnête : pour l'écosystème. Si votre entreprise a déjà un produit web en React/Next.js, une équipe TypeScript, et des composants UI partagés, React Native permet un partage de code significatif entre web et mobile (logique métier, hooks, types, utilitaires). Les développeurs React web sont productifs en React Native en 2 à 3 semaines — pas besoin d'apprendre un nouveau langage (Dart) ou un nouveau paradigme. L'écosystème npm (2.1 millions de packages) est incomparablement plus large que pub.dev (40 000 packages Dart). Et Expo SDK 52 a résolu les problèmes historiques de React Native : configuration zéro pour 90 % des projets, EAS Build pour le CI/CD cloud, et un SDK de 50+ modules natifs pré-packagés (camera, notifications, auth, maps, payments).

Expo SDK 52 — Le game changer pour React Native. Expo n'est plus un wrapper limité — c'est la plateforme de référence pour React Native en 2026, recommandée officiellement par Meta dans la documentation React Native. Expo SDK 52 apporte : Expo Router v4 (routing basé sur le filesystem, inspiré de Next.js App Router, avec deep linking natif), EAS Build (builds cloud iOS et Android sans Mac local), EAS Update (mises à jour OTA — déployer des corrections en production sans re-soumission store, latence 30 secondes), Expo Modules API (créer des modules natifs en Swift/Kotlin avec un bridge TypeScript type-safe). La distinction "Expo managed" vs "bare" a disparu — tous les projets Expo SDK 52 ont un accès complet au code natif quand c'est nécessaire.

Tarification : 1,5 k€ HT pour un MVP React Native (3-4 mois, 8-12 écrans, Expo SDK 52, authentification, API REST, push notifications), jusqu'à 711 k€ HT pour une application React Native complète (8-10 mois, 25-35 écrans, partage de code web/mobile, offline, temps réel, intégrations complexes, CI/CD EAS Build complet). Le cadrage fonctionnel et technique initial (5-8 jours, à partir de 992 € HT) est déductible du projet si engagement dans les 45 jours.

Développement React Native — Expo SDK 52, New Architecture, TypeScript

React Native avec Expo SDK 52 et la New Architecture (Fabric + TurboModules) permet de livrer des applications iOS et Android performantes en TypeScript, avec un partage de code natif avec votre web React/Next.js. Nehos conçoit et développe vos applications React Native avec une architecture production-ready : Zustand/Jotai pour l'état, React Navigation v7, EAS Build pour le CI/CD, et un écosystème npm de 2 millions de packages. De 1,5 k€ HT pour un MVP à 711 k€ HT pour une application complète.

Adapté à toute taille de structure

Artisan

Startup

PME / TPE

ETI

Grand Groupe

#React Native New Architecture — Fabric et TurboModules en production

Pendant des années, la critique principale de React Native était le "bridge" — le pont asynchrone entre le thread JavaScript et le thread natif. Chaque interaction UI (scroll, animation, gesture) devait traverser ce pont sérialisé en JSON, ce qui introduisait une latence de 5 à 15 ms par frame sur les interactions complexes. En 2026, ce problème est résolu.

#Fabric — Le nouveau moteur de rendu

Fabric remplace l'ancien système de rendu de React Native avec une architecture synchrone qui élimine le pont asynchrone pour les opérations de rendu. Concrètement : les composants React Native sont rendu via un C++ Rendering Pipeline qui communique directement avec les vues natives iOS (UIKit) et Android (Android Views) via JSI (JavaScript Interface) — une interface C++ qui permet des appels synchrones entre JavaScript et le code natif, sans sérialisation JSON.

Résultat mesurable : sur nos benchmarks Nehos (application de référence, Samsung Galaxy S23), le P99 frame time passe de 18 ms (ancienne architecture) à 11 ms (Fabric) sur des écrans complexes avec listes virtualisées, animations Reanimated, et gestures simultanés. Sur iPhone 15 Pro, le P99 passe de 12 ms à 7 ms. Les micro-freezes perceptibles lors du scroll rapide dans des listes longues sont éliminés.

#TurboModules — Modules natifs à la demande

TurboModules remplace l'ancien système NativeModules avec deux améliorations majeures. Lazy loading : les modules natifs ne sont chargés en mémoire que quand ils sont effectivement utilisés (l'ancien système les chargeait tous au démarrage, impactant le cold start). Interface typée via Codegen : chaque TurboModule a une spécification TypeScript qui génère automatiquement le code bridge C++/Objective-C++/Java — fini les erreurs de runtime causées par des incompatibilités de types entre JS et natif.

Impact sur le cold start : sur un projet Nehos avec 12 TurboModules, le cold start est passé de 1 450 ms à 980 ms sur Samsung Galaxy A54 après migration vers TurboModules (les 12 modules ne sont plus chargés au boot, seulement les 3 nécessaires à l'écran initial).

#Expo SDK 52 — La plateforme React Native de référence

Meta recommande officiellement Expo comme la façon de démarrer un projet React Native en 2026. Ce n'est pas un outil optionnel — c'est la plateforme de référence. Expo SDK 52 (décembre 2025) apporte un niveau de maturité qui change fondamentalement l'expérience développeur React Native.

#Expo Router v4 — Routing filesystem comme Next.js

Expo Router v4 implémente un routing basé sur le filesystem, directement inspiré de l'App Router de Next.js. Les fichiers dans le dossier app/ définissent les routes : app/index.tsx → route racine, app/users/[id].tsx → route dynamique /users/:id, app/(tabs)/ → layout avec navigation tabs, app/+not-found.tsx → page 404. Les layouts sont des _layout.tsx qui wrappent les routes enfants — exactement comme layout.tsx dans Next.js. Le deep linking iOS (Universal Links) et Android (App Links) est configuré automatiquement pour chaque route — plus besoin de configuration manuelle. Pour les équipes qui développent aussi un site web Next.js, la cohérence des patterns de routing entre Expo Router et Next.js App Router réduit significativement la charge cognitive.

#EAS Build — CI/CD cloud natif

EAS Build (Expo Application Services) est le service de CI/CD cloud pour React Native. Il compile les builds iOS et Android sur les serveurs Expo — pas besoin d'un Mac local pour les builds iOS, pas besoin de configurer Xcode manuellement, pas besoin de gérer les certificats Apple manuellement (EAS gère le code signing automatiquement via le Credentials Service). Configuration via eas.json : un fichier qui définit les profils de build (development, preview, production) et les profils de soumission store. Un eas build --platform all lance les builds iOS et Android en parallèle dans le cloud. Temps de build moyen : 8-12 minutes pour iOS, 6-10 minutes pour Android.

#EAS Update — Mises à jour OTA en 30 secondes

EAS Update permet de déployer des mises à jour JavaScript en production sans re-soumission sur l'App Store ou Google Play. Concrètement : vous corrigez un bug, vous lancez eas update, et les utilisateurs reçoivent la mise à jour en 30 secondes au prochain lancement de l'app — sans passer par le processus de review Apple (24-48h) ou Google (2-7 jours). Limites : les updates OTA ne peuvent modifier que le code JavaScript/TypeScript et les assets — pas le code natif (Swift/Kotlin). Mais en pratique, 90 % des corrections et évolutions sont côté JavaScript. C'est un avantage compétitif significatif pour la réactivité post-lancement.

Chaque projet React Native Nehos suit une architecture standardisée qui garantit la maintenabilité à long terme.

#Structure de projet

Structure en feature modules : chaque fonctionnalité métier (auth, orders, profile, notifications) est un module autonome avec ses propres screens, composants, hooks, stores (Zustand), types, et tests. Les modules communiquent via des interfaces typées, pas des dépendances directes. Les librairies partagées (design system, API client, utils) sont dans un dossier shared/. Cette structure scale de 5 à 50 modules sans devenir ingérable.

#State management — Zustand + React Query

Pour la gestion d'état, on combine Zustand (état client local — UI state, préférences, navigation state) et React Query (TanStack Query — état serveur, cache, invalidation, optimistic updates). Cette combinaison est plus légère et plus intuitive que Redux : Zustand se configure en 10 lignes (un create avec les actions et le state), React Query gère automatiquement le cache serveur, les refetch, les mutations, et les erreurs. Pas de boilerplate, pas de reducers, pas de selectors complexes. Jotai est utilisé en alternative pour les cas où l'état est très atomique et composable (formulaires complexes, configurations multi-steps).

React Navigation v7 (ou Expo Router v4, qui est construit sur React Navigation) gère la navigation avec support natif des gestures iOS (swipe back) et Android (back button), des transitions animées via react-native-reanimated, du deep linking automatique, et de la navigation conditionnelle (auth guard, onboarding flow). La configuration est déclarative et type-safe grâce aux types TypeScript générés pour chaque écran et ses paramètres.

#Partage de code React Web et React Native — Le vrai argument

Le partage de code entre une application web React/Next.js et une application React Native est l'argument différenciant de React Native par rapport à Flutter. Mais il faut être précis sur ce qui se partage et ce qui ne se partage pas.

#Ce qui se partage (50-70 % du code métier)

Types TypeScript et interfaces : les mêmes types définissent les entités métier côté web et mobile. Hooks custom métier : useAuth(), useOrders(), useNotifications() — la logique est identique, seuls les hooks de navigation diffèrent. Logique de validation : schémas Zod partagés entre web et mobile pour la validation des formulaires. Client API : les fonctions d'appel API (fetch + React Query) sont identiques. Utilitaires : formatage de dates, calculs métier, transformations de données.

#Ce qui ne se partage pas (et c'est normal)

Composants UI : un <Button> web (HTML <button>) n'est pas un <Button> React Native (<Pressable>). Le design system doit être dupliqué — même API de props, implémentation différente par plateforme. Navigation : React Router (web) vs React Navigation (mobile) — patterns différents. Stockage local : localStorage (web) vs AsyncStorage ou SQLite (mobile). Animations : CSS transitions (web) vs react-native-reanimated (mobile).

La clé : structurer le code en packages monorepo (Turborepo ou Nx) avec un package shared (types, hooks, logique métier), un package web (Next.js), et un package mobile (Expo). Le partage de 50-70 % de la logique métier réduit significativement le coût de développement et de maintenance de l'ensemble web + mobile.

#Performances React Native 2026 — Benchmarks honnêtes

Voici nos benchmarks internes Nehos, mesurés en avril 2026 sur une application de référence (liste de 10 000 items, 15 écrans, animations Reanimated, appels API REST) avec la New Architecture activée.

Samsung Galaxy S23 : cold start 1 020 ms, scroll P99 frame time 11 ms, mémoire résidente 178 MB, taille APK 22 MB. iPhone 15 Pro : cold start 720 ms, scroll P99 frame time 7 ms, mémoire résidente 145 MB. Ces chiffres sont excellents pour une application cross-platform — et suffisants pour 95 % des cas d'usage B2B. Les 5 % restants (jeux, applications graphiques intensives, AR/VR) nécessitent du natif pur ou Flutter.

Comparaison avec la génération précédente (React Native 0.72, ancienne architecture) : cold start -30 %, frame time P99 -40 %, mémoire -15 %. La New Architecture est un saut de performance réel, pas un argument marketing.

#CI/CD React Native — EAS Build + GitHub Actions

Le pipeline CI/CD React Native Nehos combine GitHub Actions (lint, type-check, tests unitaires, tests E2E) et EAS Build (compilation native, code signing, distribution).

#Pipeline type

Pull request ouverte → GitHub Actions exécute : ESLint + Prettier (30 secondes), TypeScript type-check strict (45 secondes), tests unitaires Jest (1-3 minutes), tests E2E Detox sur émulateur (5-10 minutes). Si tout est vert → merge dans main → EAS Build déclenché automatiquement : build iOS preview (8-12 minutes), build Android preview (6-10 minutes), distribution sur TestFlight (iOS) et Firebase App Distribution (Android) pour les testeurs internes. Tag de release → EAS Submit : soumission automatique sur App Store et Google Play.

#Tests automatisés

Trois niveaux de tests. Tests unitaires Jest : couvrent la logique métier pure (hooks, utilitaires, stores Zustand, fonctions de validation). Tests de composants React Native Testing Library : couvrent le rendu et les interactions des composants en isolation. Tests E2E Detox : couvrent les parcours utilisateur complets sur émulateur ou device réel — login, navigation, CRUD, offline/online. Detox est notre choix pour les tests E2E React Native car il s'exécute de manière synchrone avec l'application (pas de polling comme Appium), ce qui rend les tests plus rapides et moins flaky.

#Tarification React Native Nehos — 20 à 711 k€ HT

Trois fourchettes selon le périmètre.

MVP React Native Expo — 1,5 k€ HT, 3 à 4 mois. 8-12 écrans, Expo SDK 52, authentification (email/password + SSO), API REST, push notifications (Expo Notifications), analytics (Expo + Firebase), CI/CD EAS Build de base, publication App Store et Google Play. Partage de code avec web React/Next.js si existant.

Application React Native standard —à partir de 128 k€ HT, 5 à 7 mois. 15-25 écrans, offline-first avec synchronisation (WatermelonDB ou custom SQLite), deep linking, navigation tabs + stack + drawer, design system custom, tests unitaires + composants + E2E Detox, CI/CD EAS Build complet, EAS Update pour les hotfixes.

Application React Native complexe — 50 à 711 k€ HT, 7 à 10 mois. 25-35+ écrans, partage de code monorepo web/mobile (Turborepo), temps réel WebSocket, intégrations tierces multiples (paiement Stripe, cartographie Mapbox, scanner camera, Bluetooth), multi-tenant, accessibilité, localisation i18n, tests E2E sur device farm (AWS Device Farm), monitoring Sentry Mobile.

Tous les tarifs incluent le cadrage initial (5-8 jours). Estimation en 30 minutes : Prendre RDV React Native.

Questions & Réponses

Questions fréquentes sur le développement React Native

Oui, et plus que jamais. La New Architecture (Fabric + TurboModules) a résolu le problème historique du pont asynchrone — les performances sont désormais comparables à Flutter sur la majorité des cas d'usage. L'avantage décisif de React Native reste l'écosystème : 2.1 millions de packages npm, un vivier de développeurs JavaScript/TypeScript 5 à 10 fois plus large que Dart, et surtout la possibilité de partager 50-70 % du code métier entre votre web React/Next.js et votre mobile React Native. Si votre entreprise a déjà une stack React web, le choix React Native est quasi évident. Si vous partez de zéro sans contrainte existante et que la performance graphique est prioritaire, Flutter mérite d'être considéré. Voir notre page [Flutter](/services/development/flutter) pour la comparaison détaillée.

Non, mais ne pas utiliser Expo en 2026 revient à se compliquer la vie sans raison. Meta recommande officiellement Expo comme la façon de démarrer un projet React Native. Expo SDK 52 n'est plus un wrapper limité — c'est une plateforme complète avec accès natif total. La distinction "Expo managed" vs "bare" workflow a disparu : tout projet Expo peut ejcter du code natif Swift/Kotlin quand c'est nécessaire, tout en gardant les avantages d'Expo (EAS Build, EAS Update, SDK modules pré-packagés). Les seuls cas où un bare React Native sans Expo pourrait être pertinent : intégration profonde avec du code natif C++ existant (jeux, traitement d'image temps réel), ou contraintes de sécurité interdisant les services cloud Expo (dans ce cas on utilise EAS Build self-hosted). Pour 95 % des projets B2B, Expo SDK 52 est le bon choix.

Sur nos projets monorepo web + mobile Nehos, le taux de partage mesuré est de 50 à 70 % du code métier (hors UI). Ce qui se partage : types TypeScript (100 %), hooks métier (80-90 %), logique de validation Zod (100 %), client API React Query (90 %), utilitaires (100 %). Ce qui ne se partage pas : composants UI (implémentation différente web/mobile, même API de props), navigation (React Router vs React Navigation), stockage local (localStorage vs AsyncStorage/SQLite), animations (CSS vs Reanimated). L'architecture monorepo Turborepo avec un package `shared` est la clé : le code partagé est dans un package séparé importé par `web` et `mobile`. Le gain économique réel est de 25-35 % sur le coût total de développement + maintenance de l'ensemble web + mobile, comparé à deux codebases indépendants.

EAS Update (anciennement CodePush) permet de déployer des mises à jour du code JavaScript/TypeScript et des assets directement sur les devices des utilisateurs, sans passer par le processus de review Apple (24-48h) ou Google (2-7 jours). Concrètement : vous corrigez un bug, vous lancez `eas update --branch production`, et 30 secondes plus tard l'application télécharge la mise à jour en background — au prochain lancement, les utilisateurs ont la version corrigée. Limites importantes : EAS Update ne peut modifier que le JavaScript et les assets — pas le code natif (Swift/Kotlin), pas les dépendances natives, pas la configuration Expo. Si votre correctif nécessite un changement natif, il faut un nouveau build et une soumission store classique. En pratique, 85-90 % des corrections et petites évolutions sont côté JavaScript — EAS Update couvre la majorité des besoins de mise à jour rapide. C'est particulièrement utile pour les applications B2B critiques où un bug en production doit être corrigé en heures, pas en jours.

Oui, c'est un de nos cas d'intervention courants. La migration d'un projet React Native bare (ou Expo SDK ancien) vers Expo SDK 52 avec la New Architecture apporte des gains significatifs : performances améliorées (Fabric + TurboModules), CI/CD simplifié (EAS Build), mises à jour OTA (EAS Update), et accès aux dernières fonctionnalités Expo (Router v4, modules natifs pré-packagés). La migration se déroule en phases : audit de l'application existante (architecture, dépendances, modules natifs custom) → plan de migration avec identification des breaking changes → migration progressive par module → activation de la New Architecture → configuration EAS Build/Update → validation sur device panel. Durée typique : 4 à 8 semaines selon la taille de l'application et le nombre de modules natifs custom. Coût : à partir de 32 000 € HT. L'audit initial (3 jours, à partir de 1 362 € HT) donne une estimation précise.

Oui, avec plusieurs options selon la complexité. Pour un stockage local simple : `expo-secure-store` (données sensibles chiffrées, < 2 KB) et `@react-native-async-storage/async-storage` (données non sensibles, paires clé-valeur). Pour un stockage structuré avec queries : WatermelonDB (base de données réactive optimisée React Native, sync Watermelon avec backend) ou expo-sqlite (SQLite natif avec API synchrone). Pour un offline-first complet avec synchronisation : on combine SQLite local + queue de mutations (actions offline stockées localement, rejouées quand le réseau revient) + résolution de conflits (stratégie configurable par entité). Le package `@tanstack/react-query` avec son `persistQueryClient` gère aussi un cache offline intelligent avec revalidation automatique. Sur nos projets terrain (logistique, maintenance industrielle), l'architecture offline-first WatermelonDB + queue de mutations gère des volumes de 20 000 à 100 000 enregistrements locaux avec des performances de synchronisation satisfaisantes.

Exploration associée

Flutter applications mobiles Mobile Santé HDS Next.js React TypeScript strict SaaS intranet-extranet Développement Nehos Agence web vs freelance : comment choisir ?API Platform Symfony : generer une API REST complete | Guide 2026 API REST vs GraphQL 2026 : lequel choisir pour votre projet