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.

Dans ton projet Next.js (pas le projet Expo), crée le dossier et le fichier de la route

mkdir -p app/api/produits && touch app/api/produits/route.tsNew-Item -ItemType Directory -Force -Path app/api/produits; New-Item -ItemType File -Force -Path app/api/produits/route.ts

Colle le contenu de la route API

// app/api/produits/route.ts
import { prisma } from "@/lib/db/client";

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/produitsInvoke-RestMethod 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.

Crée le fichier du client auth

touch lib/auth-client.tsNew-Item -ItemType File -Force -Path lib/auth-client.ts

// lib/auth-client.ts
import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";
import * as SecureStore from "expo-secure-store";

export const authClient = createAuthClient({
  baseURL: "http://TON-IP-LOCALE:3000",
  plugins: [
    expoClient({
      scheme: "monappmobile",
      storagePrefix: "monappmobile",
      storage: SecureStore,
    }),
  ],
});

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. Remplace TON-IP-LOCALE par l'IP locale de ton ordinateur (pas localhost, qui sur un téléphone pointerait vers le téléphone lui-même) ; en production tu pointeras vers ton URL Vercel (étape 6).

Crée les fichiers des écrans connexion / inscription

touch app/login.tsx app/signup.tsxNew-Item -ItemType File -Force -Path app/login.tsx, app/signup.tsx

Colle le contenu de l'écran de connexion

// app/login.tsx
import { useState } from "react";
import { View, TextInput, Button, Text } from "react-native";
import { router } from "expo-router";
import { authClient } from "@/lib/auth-client";

export default function LoginScreen() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [error, setError] = useState("");

  async function handleLogin() {
    const { error } = await authClient.signIn.email({ email, password });
    if (error) return setError(error.message ?? "Connexion refusée");
    router.replace("/");
  }

  return (
    <View className="flex-1 justify-center p-6 gap-3">
      <TextInput placeholder="Email" value={email} onChangeText={setEmail} autoCapitalize="none" className="border p-3 rounded" />
      <TextInput placeholder="Mot de passe" value={password} onChangeText={setPassword} secureTextEntry className="border p-3 rounded" />
      {error ? <Text className="text-red-500">{error}</Text> : null}
      <Button title="Se connecter" onPress={handleLogin} />
    </View>
  );
}

Duplique la même structure pour app/signup.tsx (fonction SignupScreen) en remplaçant authClient.signIn.email(...) par authClient.signUp.email({ email, password, name: email }).

👁 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. Reconnecte-toi ensuite depuis l'écran de connexion avec les mêmes identifiants.

Colle le contenu du fichier app/_layout.tsx pour protéger les écrans
```
// app/_layout.tsx
import { Redirect, Slot } from "expo-router";
import { authClient } from "@/lib/auth-client";

export default function RootLayout() {
  const { data: session, isPending } = authClient.useSession();
  if (isPending) return null;
  if (!session) return <Redirect href="/login" />;
  return <Slot />;
}
```
Ce fichier existe déjà (créé par create-expo-app) — remplace son contenu. Il s'applique à tous les écrans : 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 : ouvre app/index.tsx (l'écran d'accueil créé automatiquement à l'étape 1), remplace le JSX retourné par cet exemple, 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.
Déclare tes couleurs une seule fois, dans tailwind.config.js
```
// tailwind.config.js
module.exports = {
  content: ["./app/**/*.{js,jsx,ts,tsx}", "./components/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {
      colors: {
        primary: "#2563eb",
        background: "#ffffff",
      },
    },
  },
};
```
Sans ça, tu retapes le même code couleur (#2563eb) dans chaque écran — si tu veux changer de teinte plus tard, tu dois le faire une seule fois ici, plutôt que de chasser chaque occurrence dans tous les fichiers.

👁 Comment voir le résultat : remplace bg-red-500 par bg-primary et text-lg reste, sauvegarde — le fond doit prendre la couleur bleue déclarée dans primary.
Pour modifier le style plus tard

Garde npx expo start lancé en continu — c'est le rechargement à chaud (« Fast Refresh ») : tu ouvres l'écran concerné (dans app/), tu changes les classes dans className, tu sauvegardes, l'app se met à jour seule sur le téléphone sans recompiler. Pour changer une couleur partout d'un coup, retouche tailwind.config.js plutôt que chaque écran un par un. Pour savoir ce que fait une classe (p-4, rounded-lg, text-xl...), consulte le lexique ou tailwindcss.com/docs.

Vérification

Une classe Tailwind appliquée à un composant change bien son style sur le téléphone. Une couleur déclarée dans tailwind.config.js (bg-primary) s'applique correctement, sans coder le code couleur en dur dans l'écran.

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.

Crée le fichier d'un écran qui appelle ta route API

touch app/produits.tsxNew-Item -ItemType File -Force -Path app/produits.tsx

Colle le contenu de l'écran

// app/produits.tsx
import { useEffect, useState } from "react";
import { View, Text, FlatList } from "react-native";

type Produit = { id: string; nom: string };

export default function ProduitsScreen() {
  const [produits, setProduits] = useState<Produit[]>([]);

  useEffect(() => {
    fetch("http://TON-IP-LOCALE:3000/api/produits")
      .then((r) => r.json())
      .then(setProduits);
  }, []);

  return (
    <FlatList
      data={produits}
      keyExtractor={(p) => p.id}
      renderItem={({ item }) => (
        <View className="p-4 border-b">
          <Text>{item.nom}</Text>
        </View>
      )}
    />
  );
}

Même logique que côté web (récupérer des données, les afficher, les valider avec Zod avant envoi côté formulaire) — seuls les composants d'affichage changent. En production, remplace l'URL par ton domaine Vercel (étape 6).

👁 Comment voir le résultat : ouvre l'écran produits 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.