Chapitre 1.3 — Expo vs React Native « nu »
Où on en est : vous savez pourquoi RN et comment il fonctionne. Reste LA question que tout débutant pose : « React Native ou Expo ? ». Réponse courte : c’est la mauvaise question — et ce chapitre explique pourquoi.
⏱️ TL;DR — Expo n’est pas une alternative à React Native : c’est le framework officiel recommandé par l’équipe React Native pour construire des apps RN. Il apporte le SDK de modules natifs, Expo Go, les development builds, le prebuild (CNG) et les services EAS. Le React Native « nu » (sans framework) existe toujours, mais c’est réservé à des cas d’intégration particuliers. En 2026, on démarre TOUT projet avec Expo — et « éjecter » est un concept mort.
🎯 Objectifs
- Situer précisément ce qu’Expo ajoute à React Native (et ce qu’il ne cache pas).
- Comprendre les 3 modes de travail : Expo Go, development build, prebuild/CNG.
- Enterrer les mythes hérités : « Expo c’est limité », « il faudra éjecter ».
- Savoir lire la frontière entre Expo (l’open source) et EAS (les services cloud).
La mauvaise question — et la bonne
« Expo ou React Native ? » suppose deux concurrents. La réalité :
- React Native = le moteur de rendu natif + les composants core (
View,Text…). Il ne fournit ni routing, ni accès caméra, ni gestion de build confortable. - Expo = le framework au-dessus : ~80 modules natifs prêts (
expo-camera,expo-notifications,expo-sqlite…), Expo Router, la CLI, et le système de génération des projets natifs. Open source, gratuit. - EAS (Expo Application Services) = les services cloud : compiler dans le cloud (Build), livrer des mises à jour OTA (Update), pousser vers les stores (Submit). Optionnels — avec un plan gratuit dont on reparlera (Partie 12).
Depuis 2024, la doc officielle de React Native l’écrit noir sur blanc : démarrez avec un framework, et Expo est le framework recommandé. La bonne question est donc : « React Native via Expo, ou React Native sans framework ? » — et la seconde option ne se justifie que pour des cas précis (brownfield : intégrer RN dans une app native existante, ou besoins d’infra exotiques).
💡 Pour un dev Next.js — L’analogie est exacte : React Native est à Expo ce que React est à Next.js. Personne ne démarre un site en assemblant React + un routeur + un bundler à la main alors que Next.js existe. Même logique ici. Et l’analogie continue : Expo Router ≈ App Router, EAS ≈ Vercel (le cloud commercial de l’éditeur du framework open source).
Les trois modes de travail
C’est le cœur pratique du chapitre — ces trois modes structurent les Parties 2, 11 et 12.
Mode 1 : Expo Go — le bac à sable
Expo Go est une app à installer depuis le Play Store. Elle contient déjà tout le code natif
du SDK Expo. Quand vous lancez npx expo start, votre bundle JS est servi par Metro sur le
réseau local ; Expo Go le charge et l’exécute. Vous ne compilez rien : itération immédiate,
reload à chaque sauvegarde.
La limite est structurelle : Expo Go ne contient QUE les modules du SDK. Besoin d’un module natif hors SDK (un module de paiement, une lib de graphiques natifs) ? Expo Go ne peut pas l’exécuter.
Mode 2 : Development build — VOTRE bac à sable
Un development build est votre propre version d’Expo Go : une app compilée qui contient vos modules natifs (ceux du SDK + les autres), plus le même outillage de dev (connexion à Metro, menu dev, fast refresh). On la génère une fois, on l’installe, puis on retrouve le confort d’Expo Go — sans ses limites. C’est le mode de croisière des projets sérieux (Partie 11).
Mode 3 : Prebuild / CNG — la génération du natif
D’où viennent les dossiers natifs (android/) quand il faut compiler ? npx expo prebuild
les génère à partir de votre app.json et de vos dépendances. C’est le principe CNG
(Continuous Native Generation) : les projets natifs sont un artefact de build régénérable,
pas du code source à maintenir. Icône, permissions, nom du package : tout se déclare en config,
et les config plugins des libs modifient les fichiers natifs à la génération.
⚠️ Piège — Les vieux tutos parlent d’éjecter (eject) : abandonner définitivement Expo pour gérer
android//ios/à la main. Ce concept est mort. Aujourd’hui, prebuild régénère le natif à la demande, dans les deux sens : vous pouvez même supprimerandroid/et le régénérer. Si un article mentionne « eject », fermez l’onglet : il date d’avant ~2022.
Récapitulatif
| Expo Go | Development build | Build de production | |
|---|---|---|---|
| Compilation nécessaire | Non | Une fois (puis rarement) | À chaque release binaire |
| Modules natifs custom | ❌ SDK seulement | ✅ Tous | ✅ Tous |
| Usage | Apprendre, prototyper | Développer au quotidien | Distribuer (APK/AAB) |
| Dans ce cours | Parties 2-10 | Parties 11+ | Parties 12-13 |
Le mythe « Expo, c’est limité »
Héritage de l’époque 2017-2021, où Expo Go était le seul mode et où certaines APIs manquaient. En 2026 :
- Tout module natif de l’écosystème npm s’intègre via development build + config plugin.
- Besoin d’écrire du Kotlin vous-même ? L’Expo Modules API est même devenue la façon la plus agréable d’écrire un module natif (panorama en Partie 15).
- Les apps Expo en production incluent Bluesky, la PlayStation App, Starlink…
Ce qui reste vrai : Expo ajoute une couche d’outillage qu’il faut comprendre (c’est le rôle des Parties 11-12), et Expo Go seul ne suffit pas pour une app réelle. Ni l’un ni l’autre ne sont des limites — ce sont des marches.
⚡ Depuis SDK 5x — Le rythme Expo : ~3 SDK par an, chacun aligné sur une version de React Native (SDK 57 → RN 0.86). Une app se met à jour SDK par SDK (
npx expo install --fixaide). Retenez : la version de votre app se définit par son SDK Expo — c’est la première chose qu’on vous demandera sur un forum.
Expo et EAS : où passe la frontière gratuit/payant
Point important pour vos apps perso à zéro budget :
- Gratuit et local, pour toujours : le framework Expo, tous les modules, Expo Router, le prebuild, et les builds locaux sur votre machine (gradle, Partie 12) — illimités.
- EAS plan gratuit : un quota de builds cloud par mois (file d’attente partagée), EAS Update pour un usage modeste — largement assez pour ce cours et vos apps perso.
- EAS payant : plus de builds, priorité de file, plus d’utilisateurs OTA — le jour où une de vos apps décolle.
Notre stratégie de cours, décidée dès maintenant : apprendre les deux chemins de build (EAS cloud ET gradle local), pour ne jamais dépendre d’un quota.
✏️ Exercices
1. Classez ces besoins par mode minimal requis (Expo Go / dev build / build de prod) :
(a) apprendre FlatList, (b) tester expo-notifications avec deep link, (c) installer Drill sur
votre téléphone pour la semaine, (d) ajouter une lib native de paiement, (e) envoyer l’app à un ami.
✅ Solution
(a) Expo Go — composant core, rien à compiler. (b) Expo Go suffit pour les notifs locales (module du SDK) ; le deep link complet est plus fiable en dev build. (c) Build de prod (APK sideloadé) — une app qui vit sans Metro. (d) Dev build — module natif hors SDK. (e) Build de prod (APK à lui envoyer).
2. Expliquez le CNG à un collègue en deux phrases, avec l’analogie du .next/.
✅ Solution
Avec Expo, les dossiers natifs android//ios/ ne sont pas du code source : ils sont
générés par expo prebuild à partir de app.json + les config plugins des libs, comme
.next/ est généré par next build — on ne les édite pas, on ne les commit (en général) pas,
on les régénère. C’est le Continuous Native Generation.
3. Un tuto YouTube de 2021 conseille « d’éjecter dès le début pour être libre ». Trois raisons pour lesquelles ce conseil est nuisible en 2026 ?
✅ Solution
(1) L’eject n’existe plus — prebuild/CNG donne accès au natif SANS quitter Expo ni maintenir les
dossiers natifs à la main. (2) On perdrait l’outillage : config plugins, expo install (versions
compatibles), EAS, mises à jour de SDK assistées. (3) La doc RN officielle recommande désormais
un framework ; le RN sans framework n’est justifié que pour le brownfield ou des infra très
spécifiques — pas pour « être libre ».
🧠 Quiz
1. Quelle est la position officielle de l’équipe React Native sur Expo ?
Réponse
La doc officielle recommande de démarrer tout nouveau projet avec un framework, et Expo est le framework recommandé. Le RN « sans framework » est réservé aux cas d’intégration particuliers (brownfield, infra custom).
2. Pourquoi Expo Go ne peut-il pas exécuter un module natif tiers ?
Réponse
Expo Go est une app déjà compilée, distribuée par le Play Store, qui embarque uniquement le code natif du SDK Expo. Un module natif tiers exige son propre code compilé — il faut donc compiler sa propre app : un development build.
3. Que fait npx expo prebuild ?
Réponse
Il génère les projets natifs (android/, ios/) à partir de la config (app.json /
app.config.ts) et des config plugins des dépendances. Les dossiers natifs deviennent des
artefacts régénérables (CNG), pas du code à maintenir.
4. Citez la frontière entre Expo et EAS.
Réponse
Expo = le framework open source et gratuit (modules, Router, CLI, prebuild, builds locaux). EAS = les services cloud payants avec plan gratuit : Build (compilation cloud), Update (OTA), Submit (envoi aux stores).
5. Comment identifie-t-on la « version » d’une app Expo, et à quoi est-elle liée ?
Réponse
Par son SDK Expo (ex. SDK 57). Chaque SDK est lié à une version précise de React Native (SDK 57 → RN 0.86) et définit l’ensemble des versions de modules compatibles.
👉 Chapitre suivant : 1.4 — La carte de l’écosystème — le tour du propriétaire : versions, outils, libs et sources fiables, pour ne plus jamais être perdu.