fastlane vs EAS Submit en 2026 : lequel publie votre app Expo ou React Native ?

Publié le : 31 octobre 2026

Si vous développez avec Expo ou React Native, deux noms reviennent au moment de publier : EAS Submit d'Expo, et fastlane, l'outil d'automatisation open source. Ils ont l'air concurrents. En réalité, pas vraiment : ils couvrent des parties différentes d'une release, et beaucoup d'équipes finissent par utiliser l'un pour le binaire et autre chose pour tout le reste.

Ce guide détaille ce que fait chaque outil, d'après sa propre documentation, et où chacun s'arrête.

La réponse courte

EAS Submit envoie un .ipa ou un .aab déjà buildé vers App Store Connect et Google Play. C'est tout. Sa doc précise qu'il ne gère ni les métadonnées, ni les captures, ni les notes de version, et qu'il ne soumet pas l'app à la review Apple.
fastlane peut aussi envoyer le binaire, mais ses actions deliver et supply poussent aussi métadonnées, captures et notes de version, et deliver peut soumettre à la review Apple.
La vraie question n'est donc pas « lequel », mais « qui gère la fiche et la soumission une fois le build envoyé ».

Ce que fait EAS Submit

EAS Submit est l'étape d'envoi d'Expo Application Services. Vous lui indiquez un build et il l'envoie au store :

eas submit --platform ios --path ./my-app.ipa
eas submit --platform android --latest --non-interactive

iOS : le .ipa part vers App Store Connect et apparaît dans TestFlight après traitement (la doc d'Expo parle en général de 10 à 15 minutes). Il n'est pas publié automatiquement sur l'App Store : vous devez encore choisir le build dans App Store Connect et le soumettre à la review.
Android : le .aab part sur la piste Google Play choisie (interne, alpha, bêta ou production). Pour une app neuve, la piste par défaut est le test interne. Avec releaseStatus à draft dans eas.json, le build est envoyé sans déploiement.
Identifiants : Android exige une clé de compte de service Google. En CI (--non-interactive), EAS ne peut rien demander, donc la clé Google ou une clé d'API App Store Connect doit déjà être configurée.
Enchaînement : eas build --auto-submit soumet juste après le build, avec le profil de soumission du même nom que le profil de build.

Expo propose aussi EAS Metadata, qui pousse les textes de la fiche App Store depuis un fichier store.config.json. Sa doc le classe en bêta, il ne gère pas encore Google Play et ne peut pas envoyer de captures.

Ce que fait fastlane

fastlane est un outil Ruby open source, aujourd'hui maintenu par sa communauté au sein de la Mobile Native Foundation. On décrit des lanes dans un Fastfile et on enchaîne des actions. Les deux qui comptent pour publier :

deliver (alias de upload_to_app_store) : envoie métadonnées, captures, vidéos d'aperçu et le .ipa vers App Store Connect. submit_for_review soumet après l'envoi, automatic_release publie après validation, phased_release active le déploiement progressif d'Apple sur 7 jours. Il lance precheck avant de soumettre.
supply (alias de upload_to_play_store) : envoie le .aab ou .apk, les textes de la fiche, les images, captures et notes de version vers Google Play, avec les options track, rollout et release_status.

Le prix, c'est la mise en place : Ruby et Bundler sur chaque machine qui lance la lane, un dossier de métadonnées à garder aligné avec les stores, et un terminal quand ça casse.

Côte à côte

	EAS Submit	fastlane
Envoi .ipa / .aab	Oui	Oui (`deliver`, `supply`)
Textes de la fiche	App Store seulement, via EAS Metadata (bêta)	Oui, les deux stores
Captures	Non	Oui, les deux stores
Notes de version	Non	Oui, les deux stores
Soumission à la review Apple	Non	Oui (`submit_for_review`)
Piste et déploiement Google Play	Piste et statut brouillon	Piste, pourcentage, statut
Mise en place	eas.json, compte Expo	Ruby, Fastfile, dossiers de métadonnées
Interface	CLI et tableau de bord Expo	CLI

Lequel choisir ?

Vous buildez déjà avec EAS et voulez juste le binaire dans le store : EAS Submit. Une commande, et il connaît vos builds EAS.
Vous voulez toute la release scriptée en CI, fiche et soumission comprises : fastlane, si maintenir des lanes Ruby et des dossiers de métadonnées ne vous gêne pas.
Vous buildez avec EAS sans vouloir scripter la fiche : gardez EAS pour le build, et un outil avec une interface pour le reste.

C'est dans ce dernier cas que OneStore trouve sa place. Il ne build pas votre app. Vous envoyez le .ipa et le .aab que vous avez buildés (avec EAS ou autre chose), et il gère la fiche dans toutes les langues sur les deux stores, les captures à toutes les tailles exigées, les notes de version, la soumission à Apple et le déploiement progressif Google Play depuis un seul écran. Le .ipa part chez Apple via un worker macOS qui lance xcrun altool, le .aab via l'API Google Play Developer.

Si vous venez de fastlane, le guide des alternatives à fastlane et le comparatif OneStore vs fastlane vont plus loin.

Questions fréquentes

EAS Submit envoie-t-il les métadonnées et les captures ?

Non. La documentation d'Expo indique qu'EAS Submit envoie les binaires et ne gère ni les métadonnées, ni les captures, ni les notes de version. EAS Metadata peut pousser les textes de la fiche App Store depuis store.config.json, mais il est en bêta, ne gère pas Google Play et ne peut pas envoyer de captures.

EAS Submit soumet-il mon app iOS à la review Apple ?

Non. Le build arrive dans App Store Connect et TestFlight. Vous le choisissez ensuite sur la version dans App Store Connect et le soumettez vous-même, ou avec un outil qui le fait, comme fastlane deliver avec submit_for_review ou OneStore.

Peut-on utiliser EAS Build avec fastlane ?

Oui. Buildez avec EAS, téléchargez l'artefact, puis lancez fastlane deliver ou supply dessus. Beaucoup d'équipes font le build sur EAS et le travail sur les stores ailleurs.

fastlane est-il encore maintenu en 2026 ?

Oui. fastlane est open source et maintenu par sa communauté au sein de la Mobile Native Foundation, depuis que Google a cessé de le financer.