Mode d'emploi — de zéro à publié

Application mobile

Une app iOS + Android à partir de ton backend Next.js existant, avec React Native + Expo. Ce n'est pas un projet à part — c'est une couche en plus sur ce que tu as déjà.

Sommaire

01Initialiser le projet Expo

02Exposer le backend en API

03Authentification mobile — Better Auth

04Style — NativeWind

05Écrans & fonctionnalités

06Build & publication — EAS

Règle du jeu : tu tapes chaque commande toi-même dans ton terminal, dans l'ordre. Tu ne passes à l'étape suivante que quand la case « vérification » est cochée. Si une commande plante, copie-colle l'erreur exacte — on corrige ensemble, tu ne devines pas.

Prérequis important : ce guide part du principe que tu as déjà un projet Next.js avec Prisma/Supabase et Better Auth en place (voir les autres guides). L'app mobile ne recrée pas de backend — elle appelle celui qui existe déjà.

Réutilisable vs spécifique : les étapes réutilisable sont valables pour n'importe quelle app mobile de ta stack. Les étapes spécifique dépendent du produit que tu construis.

📖 C'est quoi chaque techno (Expo, React Native, NativeWind...) ? Le lexique complet est sur la page d'accueil →

Réutilisable

Initialiser le projet Expo

Une app qui démarre sur ton téléphone via Expo Go, dans un dossier séparé du projet web.

Prérequis : Node.js et pnpm installés. L'app Expo Go installée sur ton téléphone (App Store / Play Store).

Crée le projet Expo, à côté de ton projet web
```
npx create-expo-app@latest mon-app-mobile --template default
cd mon-app-mobile
```
C'est un dépôt séparé du projet Next.js — le mobile et le web restent deux applications distinctes qui parlent à la même base de données via l'API.

👁 Comment voir le résultat : tape ls dans mon-app-mobile — app/, package.json doivent exister.
Initialise Git
```
git init
git add -A
git commit -m "chore: init projet Expo"
```
👁 Comment voir le résultat : tape git log --oneline — une ligne avec ton message de commit doit s'afficher.
Lance le serveur de développement
```
npx expo start
```
Un QR code s'affiche dans le terminal. Scanne-le avec l'appareil photo (iOS) ou l'app Expo Go (Android) pour ouvrir l'app sur ton téléphone, en direct.

👁 Comment voir le résultat : l'app s'ouvre sur ton téléphone avec l'écran par défaut d'Expo. Modifie un texte dans app/index.tsx, enregistre — le changement doit apparaître sur le téléphone en 1-2 secondes, sans réinstaller l'app (hot reload).

Vérification

L'écran par défaut d'Expo s'affiche sur ton téléphone via Expo Go. git log montre un commit.

Réutilisable

Exposer le backend en API

Ton app mobile peut appeler ton backend Next.js par HTTP, comme n'importe quel client.

Prérequis : le projet Next.js existe déjà (Prisma + Supabase branché).

Comprends la différence clé

Les Server Actions (utilisées dans le web) ne sont appelables que depuis une page Next.js du même projet — pas depuis une app mobile. Il faut donc des Route Handlers classiques : des vraies routes API avec une URL, comme une API REST.
Crée une route API
```
// app/api/produits/route.ts
export async function GET() {
  const produits = await prisma.produit.findMany();
  return Response.json(produits);
}
```
Chaque donnée dont l'app mobile a besoin doit avoir sa route sous app/api/.... C'est le même Prisma, la même base — juste exposée différemment.
Autorise les requêtes venant de l'app mobile (CORS)

Par défaut, Next.js n'accepte que les requêtes venant de son propre domaine. Ajoute les en-têtes CORS nécessaires dans la route, ou un middleware, pour autoriser ton app mobile à appeler l'API en développement comme en production.
Teste la route depuis un navigateur ou curl
```
curl http://localhost:3000/api/produits
```
👁 Comment voir le résultat : le terminal doit afficher du JSON (ex. [{"id":"...","nom":"..."}]), pas une page d'erreur HTML. Teste ensuite depuis l'app mobile (sur le même Wi-Fi que ton ordinateur, avec l'IP locale au lieu de localhost) pour confirmer que la requête aboutit aussi depuis le téléphone.

Vérification

La route API répond avec les bonnes données en JSON. L'app mobile (en dev, sur le même réseau Wi-Fi) arrive à appeler cette route sans erreur CORS.

Réutilisable

Authentification mobile — Better Auth

Se connecter depuis le téléphone, avec la session gérée en toute sécurité.

Prérequis : Better Auth déjà configuré côté serveur Next.js.

Installe le client Better Auth pour Expo
```
npx expo install @better-auth/expo expo-secure-store
```
Better Auth fournit un client pensé pour React Native — il gère les appels réseau vers ton serveur d'auth existant.

👁 Comment voir le résultat : @better-auth/expo apparaît dans package.json.
Stocke le token de session de façon sécurisée

Contrairement au web (cookies), le mobile stocke le token dans expo-secure-store — un espace chiffré du téléphone, pas dans une simple variable ou un fichier en clair.
Crée les écrans connexion / inscription

Mêmes champs que côté web (email, mot de passe), mais avec des composants React Native au lieu de shadcn/ui.

👁 Comment voir le résultat : sur ton téléphone, crée un compte test depuis l'écran d'inscription — puis vérifie dans Prisma Studio (côté projet web) qu'une ligne apparaît dans la table User.
Protège les écrans qui demandent d'être connecté

Vérifie la session au lancement de l'app et redirige vers l'écran de connexion si elle est absente ou expirée.

👁 Comment voir le résultat : ferme complètement l'app puis rouvre-la — tu dois rester connecté (pas de retour à l'écran de connexion). Déconnecte-toi : tu dois être redirigé vers l'écran de connexion, et rouvrir l'app ne doit plus te reconnecter automatiquement.

Vérification

Se connecter depuis le téléphone fonctionne, et la session survit à la fermeture de l'app. Se déconnecter efface bien le token stocké.

Réutilisable

Style — NativeWind

Les mêmes classes Tailwind que sur le web, appliquées à des composants React Native.

Prérequis : étape 1 validée.

Installe NativeWind
```
npx expo install nativewind tailwindcss
```
Tailwind CSS n'existe pas nativement en React Native (pas de navigateur, pas de vrai CSS) — NativeWind traduit les classes Tailwind en styles React Native au moment de la compilation.
Configure Tailwind pour le projet mobile
```
npx tailwindcss init
```
Un tailwind.config.js propre au projet mobile — les fichiers scannés ne sont pas les mêmes que côté web (App.tsx, app/**/*.tsx au lieu de app/ Next.js).

👁 Comment voir le résultat : ls tailwind.config.js — le fichier doit exister.
Utilise les classes directement dans les composants
```
// exemple
<View className="flex-1 items-center justify-center bg-white">
  <Text className="text-lg font-bold">Bonjour</Text>
</View>
```
👁 Comment voir le résultat : colle cet exemple dans un écran, enregistre — sur ton téléphone, le texte « Bonjour » doit s'afficher centré, en gras, sur fond blanc. Change bg-white en bg-red-500 pour confirmer que les classes prennent bien effet.

Vérification

Une classe Tailwind appliquée à un composant change bien son style sur le téléphone.

Spécifique au projet

Écrans & fonctionnalités

Le cœur métier de l'app — ce qui change à chaque projet.

Prérequis : étapes 2 et 3 validées.

Mets en place la navigation entre écrans
```
npx expo install expo-router
```
Expo Router fonctionne par dossiers, comme l'App Router de Next.js — un fichier = un écran. Le repère est le même que celui que tu connais déjà côté web.

👁 Comment voir le résultat : crée un deuxième écran (ex. app/profil.tsx) et un lien vers lui — tape dessus sur ton téléphone, tu dois naviguer vers le nouvel écran avec l'animation de transition native.
Construis les écrans qui appellent tes routes API

Même logique que côté web (récupérer des données, les afficher, les valider avec Zod avant envoi) — seuls les composants d'affichage changent.

👁 Comment voir le résultat : ouvre l'écran concerné sur ton téléphone — les vraies données de ta base (créées via Prisma Studio ou l'app web) doivent s'afficher, pas des données factices codées en dur.
Gère les notifications push si le projet en a besoin
```
npx expo install expo-notifications
```
Uniquement si le produit en a l'usage (ex. prévenir un utilisateur) — ne l'ajoute pas par défaut.

Vérification

Le parcours principal de l'app fonctionne de bout en bout sur le téléphone.

Réutilisable

Build & publication — EAS

Une app installable, publiée sur l'App Store et le Play Store.

Prérequis : compte Expo (expo.dev), compte développeur Apple et Google si publication réelle visée.

Installe l'outil de build EAS
```
npm install -g eas-cli
eas login
```
👁 Comment voir le résultat : tape eas whoami — ton nom de compte Expo doit s'afficher.
Configure le projet pour le build
```
eas build:configure
```
👁 Comment voir le résultat : un fichier eas.json apparaît à la racine du projet.
Renseigne les variables d'environnement de prod
```
eas secret:create --name API_URL --value https://tondomaine.vercel.app
```
L'app mobile en production doit appeler ton backend Next.js déployé, pas localhost.

👁 Comment voir le résultat : eas secret:list doit afficher API_URL dans la liste.
Lance un build de test
```
eas build --platform android --profile preview
```
Un build « preview » s'installe directement sur un téléphone pour tester, sans passer par les stores — plus rapide qu'un cycle de validation complet.

👁 Comment voir le résultat : une fois le build terminé (~10-20 min, suivi sur expo.dev), un lien de téléchargement .apk s'affiche dans le terminal — installe-le sur un téléphone Android, l'app doit se lancer et appeler ton API de production.
Soumets aux stores quand tu es prêt
```
eas build --platform all --profile production
eas submit --platform all
```
La validation Apple prend en général quelques jours ; celle de Google est plus rapide. Prévois cette marge avant une date de lancement.

👁 Comment voir le résultat : le statut de la soumission est visible sur App Store Connect et Google Play Console — il passe de « En cours d'examen » à « Approuvé » (ou un refus avec le motif, à corriger).

Vérification

Le build preview s'installe et fonctionne sur un vrai téléphone. Les variables d'environnement de prod pointent bien vers le backend déployé, pas vers localhost.