Chapitre 11.1 — Les limites d’Expo Go (et la sortie)

Où on en est : Drill est complet côté features — et tourne toujours dans Expo Go. Il est temps de comprendre précisément ce que ce bac à sable ne peut PAS faire, et ce qui le remplace.

⏱️ TL;DR — Expo Go est une app déjà compilée contenant les modules du SDK, ni plus ni moins : impossible d’y exécuter un module natif tiers, d’y voir VOTRE icône/scheme réels, ou d’y tester les notifications push. Le remplaçant : le development build — votre app compilée avec expo-dev-client (le même menu dev, le même workflow Metro). Une fois adopté, on ne revient jamais à Expo Go — et le quotidien ne change presque pas.

🎯 Objectifs

Lister ce qu’Expo Go ne peut pas faire (et pourquoi c’est structurel).
Comprendre ce qu’est exactement expo-dev-client.
Savoir ce qui change (peu) et ce qui reste (presque tout) dans le workflow.
Décider QUAND basculer (pour Drill : maintenant, et pourquoi).

Le contrat d’Expo Go, relu avec les yeux de la Partie 1

Chapitre 1.3, on l’avait posé : Expo Go = une app du Play Store contenant le code natif du SDK Expo, qui télécharge votre JS depuis Metro. Dix parties plus tard, vous pouvez lire les conséquences structurelles :

Impossible dans Expo Go	Pourquoi (structurel)
Module natif hors SDK (paiement, widget, Bluetooth avancé…)	Son code natif n’est pas DANS Expo Go — et on ne compile pas à chaud
Votre icône, splash, nom réels	C’est l’app Expo Go, pas la vôtre
Le scheme `drill://` natif	Expo Go possède `exp://` (le détour du ch. 5.5)
Notifications push	Le token FCM appartient à l’app Expo Go, pas à Drill
Tester la config native (permissions manifest, edge-to-edge…)	app.json n’est lu qu’au BUILD
La New Architecture réglée par VOUS, versions natives précises	Figées par la version d’Expo Go installée

Rien de tout ça n’est un bug : Expo Go échange la généralité contre l’instantanéité. Parfait pour apprendre (zéro build pendant 10 parties !) ; insuffisant pour finir une app.

Le development build : votre Expo Go à vous

Un development build = votre projet compilé en mode debug, avec expo-dev-client dedans — le paquet qui apporte tout l’outillage d’Expo Go (l’écran de connexion à Metro, le menu dev, les erreurs lisibles, le fast refresh) :


npx expo install expo-dev-client

Ce qui change dans le quotidien : rien d’essentiel. npx expo start tourne pareil ; l’app (la vôtre, avec son icône) se connecte à Metro pareil ; fast refresh pareil. Ce qui change vraiment : quand vous ajoutez un module NATIF (ou touchez app.json), il faut recompiler le dev build — un événement rare (quelques fois par mois), pas un quotidien. Le JS, lui, reste instantané.

La règle mentale : le dev build est un conteneur, le JS est le contenu. On rebuild le conteneur quand sa liste de courses native change ; on itère le contenu à la vitesse Metro.

Quand basculer — et pourquoi Drill bascule maintenant

Le déclencheur théorique est le premier module hors SDK. Le déclencheur RÉEL, pour Drill, est triple :

Tester vrai : les deep links drill:// de la notification quotidienne (ch. 9.2), le splash, l’icône — tout ce qui était « à vérifier plus tard » devient vérifiable.
Préparer la P12 : le pipeline de build (EAS + gradle local) s’apprend en mode debug, sans enjeu — les builds de prod de la P12 seront les mêmes commandes avec un profil différent.
Le réalisme : à partir d’ici, ce qu’on teste est ce qu’on livrera.

⚠️ Piège — Après la bascule, gardez le réflexe : si un comportement natif semble étrange après un expo install d’un nouveau module ou une modif d’app.json, la question n’est plus « cache Metro ? » mais « mon dev build est-il à jour ? ». Le symptôme classique : Cannot find native module 'X' — le JS référence un module que le conteneur n’a pas. Remède : rebuild du dev build. Ajoutez-le à votre liste mentale de diagnostics (après expo start -c, avant le désespoir).

💡 Pour un dev Next.js — L’analogie la plus proche : Expo Go ≈ CodeSandbox (environnement hébergé, dépendances imposées) ; le dev build ≈ votre machine locale (tout installable, à vous de la maintenir). La bascule a le même goût : un peu de setup contre la liberté totale.

✏️ Exercices

1. Auditez Drill : listez ses modules actuels (package.json) et vérifiez qu’AUCUN n’exige déjà le dev build (tous SDK). Puis listez 3 features futures (vos idées P19+) qui l’exigeraient.

✅ Solution

Actuels : expo-sqlite, expo-notifications (locales), expo-haptics, expo-audio, expo-image, expo-clipboard, react-native-svg, reanimated, gesture-handler, zustand, tanstack — tous compatibles Expo Go (d’où 10 parties sans build !). Futures exigeant un dev build : widgets home screen (module natif tiers), notifications push (token FCM), achats in-app (P17 — react-native-purchases), health connect, Bluetooth. Le pattern : tout ce qui touche à l’identité de l’app ou à des services appareil/OS profonds.

2. Sans lancer de build : que va-t-il se passer pour le deep link de la notification quotidienne une fois dans le dev build, par rapport à Expo Go ? Relisez ch. 5.5/9.2 et prédisez précisément.

✅ Solution

Dans Expo Go, drill:// n’existait pas (scheme exp:// + préfixe /--/). Le dev build DÉCLARE le scheme drill (app.json → manifest au prebuild) : la notification avec data.url = '/quiz?…' routera nativement, et npx uri-scheme open "drill://quiz?theme=php" --android fonctionnera enfin tel quel. Le code, lui, ne change pas d’une ligne — c’était le but du contrat de robustesse (params validés).

3. Expliquez à un collègue (3 phrases max) pourquoi « Expo Go n’est pas Expo » — la confusion la plus répandue de l’écosystème.

✅ Solution

« Expo est le framework (modules, Router, outillage, EAS) — il vit dans TON app compilée. Expo Go n’est qu’une app de démo générique pour apprendre sans compiler. Les vraies apps Expo (Bluesky, la nôtre) n’embarquent pas Expo Go : elles utilisent le framework avec leur propre binaire. » Corollaire : « Expo c’est limité » confond presque toujours les limites d’Expo GO avec le framework.

🧠 Quiz

1. Pourquoi un module natif tiers ne peut-il pas tourner dans Expo Go ?

Réponse

Expo Go est une app déjà compilée avec le seul code natif du SDK : le natif ne se charge pas à chaud — il faut compiler sa propre app (dev build) qui embarque le module.

2. Qu’apporte exactement expo-dev-client ?

Réponse

L’outillage de développement DANS votre app : écran de connexion Metro, menu dev, fast refresh, erreurs lisibles — Expo Go-sans-Expo Go, pour votre propre binaire.

3. Après la bascule, quand faut-il recompiler le dev build ?

Réponse

Quand le conteneur natif change : nouveau module natif, modification d’app.json/config plugins, montée de SDK. Le JS quotidien reste servi par Metro, sans build.

4. Quel symptôme signale un dev build périmé ?

Réponse

Cannot find native module 'X' (ou un comportement natif qui ignore votre nouvelle config) : le JS attend du natif que le conteneur n’a pas encore. Remède : rebuild.

5. Citez deux choses de Drill enfin testables en dev build.

Réponse

Le scheme natif drill:// (notification → deep link réel), l’icône/splash/nom réels — plus, demain, tout module hors SDK (push, achats).

👉 Chapitre suivant : 11.2 — Créer son development build — EAS cloud et gradle local : les deux chemins, en pratique.