Parcours techniquesMis à jour le 23 octobre 202612 min de lecture

Publier une app Expo sur l'App Store avec EAS Build et EAS Submit

eas.json, certificats gérés par EAS, numéro de build, envoi sur TestFlight, EAS Update ou nouveau build : publier une app Expo sur iOS, pas à pas.

Sources Apple vérifiées le 23 octobre 2026 · relu par Équipe Briksell

Sommaire

Réponse courte

Pour publier une app Expo sur l'App Store, deux services d'Expo font le gros du travail :

  • EAS Build fabrique le fichier de ton app iOS (le « build ») sur des Mac hébergés dans le cloud d'Expo. Il peut aussi créer et garder pour toi les certificats de signature qu'Apple exige.
  • EAS Submit envoie ce build sur App Store Connect, l'espace en ligne d'Apple où tu gères ton app. Après traitement, il apparaît dans TestFlight, en général en 10 à 15 minutes d'après Expo.

Trois réglages comptent avant de lancer quoi que ce soit :

  1. le fichier eas.json, qui décrit tes « profils » de build (développement, test, production) ;
  2. l'identifiant de l'app (ios.bundleIdentifier), identique à celui de ta fiche App Store Connect ;
  3. le numéro de build, différent à chaque envoi. EAS peut l'augmenter tout seul.

Ensuite, pour corriger ton app, tu as deux chemins : une mise à jour EAS Update (sans repasser par Apple) pour le JavaScript, les styles et les images, ou un nouveau build dès que tu touches au code natif, aux autorisations ou à la version du SDK Expo.

Qui est concerné, et les exceptions

Les apps Expo, dont celles créées avec Briksell

Ce guide part d'un projet Expo (React Native), la technologie des apps créées avec Briksell. D'après Expo, EAS Build fonctionne aussi sans Expo, mais les exemples suivent un projet Expo.

Il faut ton propre compte Apple Developer

Expo le rappelle : sans adhésion à l'Apple Developer Program (99 $/an, affiché en euros à l'inscription), pas de build pour l'App Store. Et la règle 4.2.6 d'Apple refuse les apps issues d'un service de génération d'apps si elles ne sont pas soumises par le fournisseur du contenu. C'est donc ton compte qui signe et envoie l'app. Voir S'inscrire à l'Apple Developer Program.

Pas besoin de Mac

Les builds iOS tournent sur les Mac d'Expo, et EAS Submit fonctionne sous macOS, Linux et Windows. Le détail est dans Publier une app sur l'App Store sans Mac. Un iPhone reste très utile pour tester.

Ce que ce guide ne couvre pas

La fiche App Store (captures, description, prix) est dans Créer sa fiche App Store Connect. Les contrôles techniques avant la revue (version de Xcode exigée, autorisations, chiffrement) sont dans Préparer techniquement une app iOS avant App Review.

Ce que contient le code exporté de Briksell

La publication sur TestFlight directement depuis Briksell est en préparation et pas encore ouverte (voir Publication App Store). En attendant, tu exportes le code en ZIP ou sur GitHub, puis tu suis ce guide.

Voici ce que tu trouves dans le projet exporté :

  • un projet Expo SDK 54 avec Expo Router et TypeScript ;
  • un fichier app.json avec le nom, la version 1.0.0 et un identifiant d'app de la forme app.briksell.nomdetonapp. Remplace-le par le tien (par exemple com.tonnom.tonapp), comme l'indique le mode d'emploi fourni ;
  • un fichier README.md qui renvoie vers EAS Build puis EAS Submit.

Le projet exporté ne contient pas encore de fichier eas.json : la commande eas build:configure le crée (étape 2). Il n'embarque pas non plus la bibliothèque expo-updates : EAS Update n'est donc pas prêt d'office (voir plus bas).

Procédure pas à pas

Étape 1 : installer l'outil d'Expo et te connecter

Crée un compte Expo, puis installe l'outil en ligne de commande avec npm install --global eas-cli (ou utilise npx eas-cli@latest). Connecte-toi avec eas login. La commande eas whoami confirme le compte utilisé.

Étape 2 : créer le fichier eas.json

Dans le dossier du projet, lance eas build:configure. Le fichier eas.json est créé à la racine, à côté de package.json. Il contient trois profils :

ProfilÀ quoi il sert
developmentUne version avec les outils de développement, installée sur tes appareils. Jamais envoyée sur un store.
previewUne version de test sans outils de développement, à installer par ton équipe.
productionLa version envoyée sur l'App Store ou sur TestFlight.

Si tu ne précises pas de profil, Expo indique que la commande eas build utilise celui qui s'appelle production.

Étape 3 : vérifier app.json

Avant le premier build, contrôle dans app.json :

  • ios.bundleIdentifier : l'identifiant de l'app, exactement le même que celui de ta fiche App Store Connect ;
  • version : le numéro affiché sur l'App Store (par exemple 1.0.0) ;
  • les textes d'autorisation (caméra, photos, position…) sous ios.infoPlist, un texte précis par autorisation.

Apple rattache chaque build à ta fiche grâce à l'identifiant et au numéro de version contenus dans l'app.

Étape 4 : régler le numéro de build une fois pour toutes

Expo distingue deux numéros :

  • version (version) : celle que voient les utilisateurs ;
  • numéro de build (ios.buildNumber) : celui qui distingue chaque envoi. Apple s'en sert pour identifier le build dans tout son système.

La solution la plus simple, recommandée par Expo depuis la version 12 d'EAS CLI : stocker le numéro de build sur les serveurs d'EAS. Dans eas.json, mets "appVersionSource": "remote" dans la partie cli, et "autoIncrement": true dans le profil production. EAS augmente alors le numéro à chaque build. Les valeurs de build écrites dans app.json sont ignorées.

Si l'app a déjà été envoyée sur App Store Connect, lance eas build:version:set et saisis le dernier numéro envoyé, pour que la suite reparte au-dessus.

Avec "appVersionSource": "local", c'est app.json qui fait foi : autoIncrement marche aussi, mais il faut enregistrer la modification dans ton code après chaque build.

Étape 5 : lancer le build iOS

Lance eas build --platform ios. Si tu n'as pas encore de certificat ni de profil, l'outil te propose de les créer : tu te connectes à ton compte Apple Developer et tu suis les questions.

D'après Expo, EAS génère alors pour iOS :

  • le certificat de distribution ;
  • le profil de provisionnement (le document qui relie ton app, ton compte et le certificat) ;
  • une clé pour les notifications push.

Ces éléments sont stockés sur les serveurs d'EAS et réutilisés aux builds suivants. La commande eas credentials permet de les consulter, de les modifier ou de les supprimer. Tu peux aussi fournir les tiens : c'est le réglage "credentialsSource": "local" du profil (par défaut, il vaut remote, c'est-à-dire géré par EAS).

Étape 6 : créer la fiche dans App Store Connect

Apple demande d'ajouter l'app à ton compte App Store Connect avant d'y envoyer un build. Crée la fiche avec le même identifiant que dans app.json : voir Créer sa fiche App Store Connect.

Note ensuite l'Apple ID de l'app, affiché dans App Store Connect sous « General Information ». Expo l'appelle ascAppId. Tu peux l'écrire dans la partie submit de eas.json, profil production. Expo précise qu'avec ce numéro, EAS Submit saute l'étape de création de l'app.

Étape 7 : envoyer le build avec EAS Submit

Lance eas submit --platform ios. Pour enchaîner les deux étapes, tu peux aussi lancer eas build --platform ios --auto-submit : le build terminé part directement à EAS Submit.

Pour envoyer sans répondre à des questions (par exemple depuis un service automatique), EAS a besoin d'une clé API App Store Connect. La commande eas credentials --platform ios peut la créer, ou tu renseignes ta propre clé dans eas.json.

Étape 8 : traitement, TestFlight, puis revue

Apple traite le build avant de l'afficher ; tu reçois un e-mail quand c'est fini. Le build apparaît ensuite dans l'onglet TestFlight. Teste-le sur un vrai iPhone : voir TestFlight : tester ton app.

La mise en vente reste manuelle. Dans App Store Connect, ouvre la version, clique sur + à côté de « Build », choisis le build testé, enregistre, puis soumets à la revue. Apple n'accepte qu'un build par version, mais tu peux en changer jusqu'à l'envoi en revue. Si le build affiche « Missing Compliance », réponds d'abord aux questions sur le chiffrement. Pour les notes à laisser à l'équipe de revue, lis Notes App Review et compte de démo.

EAS Update ou nouveau build : lequel choisir ?

Une fois l'app publiée, EAS Update envoie une mise à jour directement aux apps déjà installées. L'app la télécharge au démarrage, et elle s'applique au redémarrage suivant.

Ce que tu changesEAS Update suffit ?
Textes, écrans, logique en JavaScriptOui
Styles, couleurs, imagesOui
Ajout d'une bibliothèque avec du code natifNon, nouveau build
Nouvelle autorisation (caméra, notifications…)Non, nouveau build
Passage à une nouvelle version du SDK ExpoNon, nouveau build

Mettre en place EAS Update

  1. Installe la bibliothèque avec npx expo install expo-updates.
  2. Lance eas update:configure. Il ajoute à app.json un numéro de compatibilité (runtimeVersion) et l'adresse des mises à jour, et règle un « canal » (channel) dans les profils preview et production de eas.json.
  3. Fais un nouveau build et publie-le : seules les apps qui contiennent expo-updates peuvent recevoir des mises à jour.
  4. Pour chaque correction ensuite : eas update --channel production --message "Ce qui change". À partir du SDK 55, Expo demande aussi l'option --environment.

Le numéro de compatibilité (runtime version)

Il garantit qu'une mise à jour n'arrive que sur des builds dont le code natif est compatible. Expo décrit deux règles :

  • appVersion : le numéro change quand tu changes la version de l'app. Si tu modifies le code natif sans changer la version, une mise à jour incompatible peut partir ;
  • fingerprint : le numéro change dès que quelque chose peut toucher au code natif. Plus sûr, mais tu feras des builds plus souvent.

Ce qu'Apple autorise

Expo le dit lui-même : avec EAS Update, tu dois respecter les règles des stores. Chez Apple, la règle 2.5.2 interdit de télécharger ou d'exécuter du code qui ajoute ou modifie les fonctions de l'app. Par prudence, garde EAS Update pour les corrections de bugs et les petits ajustements. Pour une nouvelle fonction, envoie un nouveau build en revue. C'est aussi la consigne de notre guide Préparer techniquement une app iOS avant App Review.

Erreurs fréquentes

  • Garder l'identifiant app.briksell.… du code exporté au lieu du tien, ou en mettre un autre que celui de la fiche App Store Connect.
  • Envoyer deux fois le même numéro. Expo cite l'envoi d'un build avec un numéro de version déjà utilisé parmi les causes courantes de refus. Active autoIncrement.
  • Mettre des mots de passe ou des clés dans env de eas.json : Expo le déconseille, ce fichier fait partie de ton code.
  • Envoyer une nouvelle autorisation par EAS Update : il faut un nouveau build.
  • Changer le code natif sans changer le numéro de compatibilité avec la règle appVersion.

Vérification

Avant d'envoyer ton build, coche chaque point. La liste est enregistrée seulement dans ton navigateur.

Ta checklist0/9

Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.

Sources Apple et date de vérification

Vérifié le 23 octobre 2026 sur les pages officielles :

FAQ

EAS est-il payant ?

EAS Build est ouvert à tout compte Expo, y compris sur le plan gratuit. Le 23 octobre 2026, la page tarifs d'Expo affiche un plan Free à 0 $ avec jusqu'à 15 builds iOS et 15 builds Android, une file d'attente basse priorité, et des mises à jour EAS Update pour 1 000 utilisateurs actifs par mois. Le plan Starter est à 19 $/mois, plus l'usage. Ces conditions changent : vérifie-les sur expo.dev/pricing avant de te lancer.

Faut-il créer la fiche App Store avant d'utiliser EAS Submit ?

Oui. Apple indique d'ajouter l'app à ton compte avant d'envoyer un build, et la fiche complète se remplit de toute façon dans App Store Connect. Ensuite, renseigne son Apple ID (ascAppId) dans eas.json.

Peut-on corriger un bug sans repasser par Apple ?

Oui, avec EAS Update, si la correction ne touche que le JavaScript, les styles ou les images, et si ton build publié contient expo-updates. Pour du code natif, une nouvelle autorisation ou une nouvelle fonction, il faut un nouveau build et une nouvelle revue.

Passer à l'action

Arrive à EAS Build avec une app déjà testée. Avec Briksell, tu l'essaies sur ton téléphone pendant la construction ; App Store Readiness repère dans ton code les points surveillés par Apple. L'envoi sur TestFlight depuis Briksell arrive bientôt ; en attendant, exporte ton code et suis ce guide, depuis ton propre compte Apple Developer. Si tu n'as pas encore commencé : Créer mon app.

Sources officielles

À lire ensuite

← Tous les guides « Parcours techniques »Tous les thèmes