Générer l'APK et publier sur le Play Store et l'App Store

Publier une application mobile, c'est la compiler en un fichier installable et signé (un APK ou un AAB pour Android, une IPA pour iOS), puis la soumettre au Google Play Store ou à l'App Store, qui la vérifient avant de la proposer au public. Avec Expo, la compilation se fait dans le cloud avec Expo Build (anciennement EAS Build), sans Android Studio ni Mac. Ce chapitre configure app.json, produit l'APK d'AppliFrais à installer pour une démonstration, explique la gestion des versions, puis les étapes de publication sur chaque magasin et les mises à jour à distance.

Du code à l'application installable

Toute application doit être signée avec une clé privée : la signature prouve que les mises à jour viennent du même éditeur. Sur Android, cette clé est rangée dans un fichier keystore ; si tu la perds, tu ne peux plus mettre à jour ton application sur un téléphone où elle est installée. Expo Build crée et conserve cette clé pour toi, sur ses serveurs ; Google Play, de son côté, re-signe les applications publiées avec sa propre clé (Play App Signing).

Configurer app.json

Avant la première compilation, complète l'identité de l'application dans app.json :

{
  "expo": {
    "name": "AppliFrais",
    "slug": "applifrais-mobile",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./assets/images/icon.png",
    "scheme": "applifrais",
    "userInterfaceStyle": "automatic",
    "android": {
      "package": "com.gsb.applifrais",
      "adaptiveIcon": {
        "foregroundImage": "./assets/images/android-icon-foreground.png",
        "backgroundColor": "#E6F4FE"
      }
    },
    "ios": {
      "bundleIdentifier": "com.gsb.applifrais"
    },
    "plugins": ["expo-router", "expo-secure-store", "expo-sqlite"]
  }
}

Compiler dans le cloud avec Expo Build

Expo Build compile l'application sur les serveurs d'Expo : tu n'as besoin ni d'Android Studio ni d'un Mac, même pour iOS. L'offre gratuite d'Expo inclut un nombre limité de compilations par mois, avec une file d'attente ; c'est largement suffisant pour un projet de BTS.

Les services d'Expo s'appelaient EAS (Expo Application Services) jusqu'en 2026, et ont été renommés : EAS Build est devenu Expo Build, EAS Submit Expo Submit, EAS Update Expo Update. Les commandes gardent le nom eas, et le fichier de configuration s'appelle toujours eas.json.

npm install --global eas-cli    # ou préfixe chaque commande par npx eas-cli@latest
eas login                       # avec ton compte Expo
eas build:configure             # crée eas.json et relie le projet à ton compte

eas.json définit des profils de compilation. Pour AppliFrais :

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "android": { "buildType": "apk" },
      "env": { "EXPO_PUBLIC_API_URL": "https://recette-api.gsb.example/v1" }
    },
    "production": {
      "autoIncrement": true,
      "env": { "EXPO_PUBLIC_API_URL": "https://api.gsb.example/v1" }
    }
  }
}

Les variables EXPO_PUBLIC_… de chaque profil remplacent celles du fichier .env : l'APK de recette et la version publiée n'appellent pas la même API. Les magasins exigent aussi un numéro de compilation (versionCode sur Android, buildNumber sur iOS), un entier qui augmente à chaque envoi, même pour la même version. Avec appVersionSource: "remote" et autoIncrement, il n'est plus dans app.json : Expo tient lui-même le compteur sur ses serveurs et l'augmente à chaque compilation de production. Tu ne peux plus oublier de le faire, et une valeur écrite dans app.json serait ignorée.

Pour produire l'APK de démonstration :

eas build --platform android --profile preview

La compilation prend une dizaine de minutes. À la fin, la commande affiche un lien et un QR code : ouvre-le sur le téléphone, télécharge l'APK et installe-le (Android demande d'autoriser l'installation d'applications de cette source). eas build:run -p android l'installe directement sur l'émulateur.

Compiler sur ta machine

Si tu as Android Studio, tu peux aussi compiler localement :

npx expo run:android --variant release

Expo génère alors le dossier android/ à partir d'app.json (la génération native continue : npx expo prebuild), puis lance Gradle, l'outil de compilation d'Android. Ce dossier est généré : ne le modifie pas à la main et ne le versionne pas, toute la configuration passe par app.json et les greffons. Depuis le SDK 58, les versions de publication Android passent aussi par R8, l'outil d'Android qui retire le code Java et Kotlin inutile et raccourcit ses noms internes. Pour iOS, la compilation locale demande un Mac avec Xcode.

Publier sur Google Play

1. Créer un compte développeur Google Play : 25 dollars, payés une seule fois. Google vérifie l'identité du titulaire.
2. Créer l'application dans la Play Console : nom, langue, gratuite ou payante.
3. Remplir la fiche : description courte et longue, captures d'écran, icône, catégorie, adresse de contact.
4. Remplir les déclarations : la politique de confidentialité (une adresse web obligatoire), le formulaire Sécurité des données (quelles données l'application collecte, pourquoi, si elles sont chiffrées et partagées), la classification du contenu, le public visé.
5. Envoyer l'AAB de production, dans un canal de test d'abord.
6. Passer en production après les tests ; Google examine l'application, de quelques heures à quelques jours.

Google impose aussi une version Android cible récente : depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36). Le SDK 58 d'Expo cible déjà ce niveau : tenir son SDK à jour, c'est aussi rester publiable.

La commande eas submit -p android envoie le dernier AAB compilé vers la Play Console, après une première configuration (un compte de service Google, créé une fois).

Publier sur l'App Store

1. Adhérer au programme Apple Developer : 99 dollars par an (99 € en France). Sans adhésion, ni publication ni TestFlight : un Mac avec Xcode permet seulement d'installer l'application sur ton propre iPhone, pour quelques jours.
2. Compiler avec eas build -p ios --profile production : Expo Build crée les certificats et les profils de signature à partir de ton compte Apple, sans Mac.
3. Envoyer la compilation avec eas submit -p ios vers App Store Connect.
4. Tester avec TestFlight, l'outil de bêta d'Apple : jusqu'à 10 000 testeurs externes, qui installent l'application TestFlight.
5. Remplir la fiche : captures pour chaque taille d'iPhone, description, politique de confidentialité, et les étiquettes de confidentialité (App Privacy) qui listent les données collectées.
6. Soumettre à la revue : Apple vérifie l'application à la main, en général en un ou deux jours, selon ses règles (App Review Guidelines). Motifs de refus fréquents : un plantage, une fonction factice, un message de permission vague, un identifiant de démonstration manquant pour une application qui demande une connexion.

Les mises à jour : une nouvelle version ou une mise à jour à distance

Une nouvelle version passe par le magasin : compilation, envoi, examen, puis mise à jour sur les téléphones, sur plusieurs jours. Pour corriger un bogue dans le JavaScript, Expo propose une voie plus rapide : Expo Update (anciennement EAS Update), avec le module expo-updates. L'application télécharge le nouveau code JavaScript et les nouvelles images au démarrage, sans passer par le magasin.

npx expo install expo-updates
eas update:configure
eas update --channel production --message "Corrige le calcul du total"

La version d'exécution (runtime version) garantit qu'une mise à jour n'est envoyée qu'aux compilations dont le code natif est compatible. Les magasins autorisent ces mises à jour pour corriger et améliorer, pas pour transformer l'application en une autre sans examen.

N'oublie pas l'autre bout du câble : des téléphones garderont l'ancienne version des mois. L'API doit rester compatible avec les versions encore en circulation, ce qui justifie son versionnement (/v1/, versionner une API). Et pour une faille grave, l'application doit pouvoir imposer la mise à jour : au démarrage, elle demande à l'API la version minimale acceptée et bloque l'accès si elle est plus ancienne (contrôle MASVS-CODE-2, chapitre 13).