Déployer son app sur l'App Store : EAS Build vs Fastlane

Le vibe coding change la donne

En 2025, quelque chose a changé dans le monde du développement. Des milliers de personnes — designers, entrepreneurs, makers — ont commencé à construire de vraies applications mobiles sans avoir appris à coder. Le vibe coding, c'est ça : décrire ce qu'on veut à un LLM, itérer en langage naturel, et voir l'app prendre forme.

Claude, Cursor, Windsurf et les autres ont rendu ça possible. Et le résultat est souvent bluffant. Une app de cartographie avec de la simulation d'ombres 3D en temps réel ? Faite en quelques sessions.

Mais le vibe coding s'arrête généralement au moment où l'app tourne en local. Le déploiement sur l'App Store, c'est une autre histoire. Apple a ses propres règles, ses certificats, ses formats, sa review. Et là, les LLMs ne peuvent pas tout faire à votre place — du moins pas encore.

Cet article explique les deux approches principales pour soumettre une app iOS sur l'App Store, avec leurs avantages et leurs limites concrètes.

Le pipeline de déploiement iOS — vue d'ensemble

Quel que soit l'outil utilisé, le pipeline reste le même :

1. Compiler le code source en binaire iOS (.ipa)
2. Signer ce binaire avec un certificat Apple valide
3. Uploader le binaire sur App Store Connect
4. Remplir les métadonnées (description, screenshots, prix, etc.)
5. Soumettre pour la review Apple (2 à 7 jours)

C'est les étapes 1, 2 et 3 qui différencient les deux approches.

Approche 1 — EAS Build (pour React Native / Expo)

Si votre app est construite avec React Native — ce qui est le cas de la plupart des apps issues du vibe coding via Cursor ou Claude — alors EAS Build est la voie la plus directe.

EAS (Expo Application Services) est le service cloud d'Expo. Au lieu de compiler sur votre Mac, vous envoyez votre code vers leurs serveurs. Un Mac virtuel chez eux fait tout le travail : installation des dépendances, compilation Xcode, signature, production du .ipa.

Le schéma

Votre code local
      ↓ (push via CLI)
Serveurs Expo (Mac virtuel)
      ↓ (compile + signe)
Fichier .ipa
      ↓ (eas submit)
App Store Connect

Les avantages concrets

Pas besoin de Xcode sur votre Mac. C'est le principal. Xcode pèse 15 Go, demande macOS récent, et sa courbe d'apprentissage pour le déploiement est réelle. Avec EAS, vous n'en avez pas besoin.

Les certificats sont gérés automatiquement. Apple oblige chaque app à être signée avec un certificat de distribution. EAS peut le créer pour vous lors du premier build, le stocker sur ses serveurs, et le réutiliser à chaque nouveau build.

Une seule commande. Une fois configuré, déployer une nouvelle version se résume à :

eas build --platform ios --profile production
eas submit --platform ios --latest

Gratuit pour les projets personnels. Le free tier d'Expo inclut un quota mensuel de builds largement suffisant pour un projet solo ou une petite équipe.

La configuration minimale

Trois fichiers suffisent à configurer EAS :

app.json — l'identité de votre app :

{
  "expo": {
    "name": "Mon App",
    "slug": "mon-app",
    "owner": "votre-compte-expo",
    "version": "1.0.0",
    "ios": {
      "bundleIdentifier": "com.votreentreprise.monapp",
      "infoPlist": {
        "ITSAppUsesNonExemptEncryption": false
      }
    }
  }
}

eas.json — les profils de build :

{
  "cli": {
    "version": ">= 16.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {}
  }
}

Et voilà. Le reste (certificats, provisioning profiles, build numbers) est géré par EAS.

Les limites

Le premier build nécessite une interaction : EAS doit s'authentifier auprès d'Apple pour créer les certificats. Vous devrez entrer votre Apple ID, mot de passe, et valider un code 2FA. C'est une manipulation manuelle qui ne peut pas être entièrement automatisée.

EAS est aussi spécifique à l'écosystème Expo/React Native. Si votre app utilise des modules natifs très personnalisés ou du Swift pur, vous êtes hors périmètre.

Approche 2 — Fastlane (pour Swift natif et tous les projets Xcode)

Si votre app est en Swift natif — construite avec Xcode, sans React Native — alors Fastlane est l'outil de référence pour automatiser le déploiement.

Fastlane est un outil open source (en Ruby) créé en 2014, racheté par Google en 2017, et maintenant entièrement open source. Il automatise toutes les étapes du déploiement iOS (et Android) depuis votre Mac.

Le schéma

Votre code local
      ↓
Fastlane (sur votre Mac)
      ↓ gym (compile via Xcode)
Fichier .ipa signé
      ↓ deliver (upload)
App Store Connect

Contrairement à EAS, la compilation se fait sur votre propre Mac. Xcode est donc requis.

Les outils Fastlane

Fastlane est en fait une collection d'outils spécialisés, appelés "actions" :

Action	Ce qu'elle fait
gym	Compile et signe l'app (remplace "Product → Archive" dans Xcode)
deliver	Upload le .ipa, les métadonnées et les screenshots vers App Store Connect
snapshot	Prend les screenshots automatiquement sur tous les simulateurs iOS
match	Synchronise les certificats dans un repo git — idéal en équipe
pilot	Gère TestFlight : upload, invitations, groupes de bêta testeurs
cert + sigh	Crée et télécharge les certificats et provisioning profiles

Un Fastfile typique

La configuration Fastlane se fait dans un fichier Fastfile. Une "lane" est une séquence d'actions :

lane :release do
  # Incrémente le build number automatiquement
  increment_build_number

  # Compile et signe l'app
  gym(
    scheme: "MonApp",
    export_method: "app-store"
  )

  # Upload sur App Store Connect
  deliver(
    submit_for_review: true,
    automatic_release: false,
    force: true
  )
end

Pour lancer le déploiement complet :

fastlane release

La feature killer : snapshot

L'une des fonctionnalités les plus précieuses de Fastlane est la génération automatique de screenshots. L'App Store exige des screenshots en plusieurs formats (6.7", 6.5", 5.5" pour iPhone, plusieurs tailles pour iPad). Les faire manuellement prend du temps. Fastlane peut les générer automatiquement sur tous les simulateurs en une commande :

fastlane snapshot

Fastlane lance votre app sur chaque simulateur configuré, navigue automatiquement dans les écrans définis, et prend les screenshots. Résultat : 20-30 screenshots en quelques minutes.

Les limites

Fastlane nécessite Ruby et Xcode sur votre Mac. La configuration initiale prend du temps, surtout pour match (gestion des certificats en équipe). C'est un investissement qui se justifie si vous déployez régulièrement ou en équipe.

Comparatif direct

Critère	EAS Build	Fastlane
Pour quel type d'app	React Native / Expo	Swift, Flutter, React Native, tout
Compile sur	Serveurs cloud Expo	Votre Mac (Xcode requis)
Xcode requis	Non	Oui
Certificats	Gérés automatiquement	Match (repo git) ou manuels
Screenshots automatiques	Non	Oui (snapshot)
Config initiale	Simple	Modérée
Coût	Gratuit (free tier)	Gratuit (open source)
Idéal pour	Makers solo, vibe coders	Équipes, apps Swift natives

Ce que l'IA peut — et ne peut pas — faire

Le vibe coding a ses limites face aux stores Apple et Google, et il est utile d'être lucide là-dessus.

Ce que Claude ou un LLM peut faire pour vous :

• Configurer app.json et eas.json correctement
• Générer les icônes dans tous les formats requis
• Rédiger les descriptions, keywords et métadonnées en plusieurs langues
• Écrire le Fastfile adapté à votre projet
• Diagnostiquer les erreurs de build
• Remplir App Store Connect via un navigateur (avec les bons outils)

Ce qui reste manuel :

• L'authentification Apple (Apple ID, 2FA) — Apple bloque l'automatisation totale
• Les screenshots — ils doivent montrer votre app réelle, pas une simulation
• La review Apple — un humain chez Apple examine votre app
• Le compte Apple Developer ($99/an) — à créer soi-même

En pratique, avec EAS ou Fastlane, le déploiement se réduit à 3-4 interactions manuelles (authentification, validation des certificats, upload des screenshots). Tout le reste peut être automatisé ou délégué à un LLM.

Mon workflow actuel

Pour Sunny Terraces Brussels, une app React Native construite en vibe coding avec Claude Code, voici le workflow que j'utilise :

1. Claude Code génère les icônes (SVG → PNG en toutes tailles) depuis le code
2. Claude Code rédige toutes les métadonnées App Store en EN/FR/NL
3. Claude Code configure app.json et eas.json
4. Je lance eas build --platform ios --profile production dans mon terminal
5. Je valide les certificats en mode interactif (2 minutes)
6. EAS compile (~15 min sur leurs serveurs)
7. Je lance un prompt dans Claude (avec accès au navigateur) pour remplir App Store Connect automatiquement
8. Je soumets

La différence avec un déploiement manuel il y a deux ans : ce qui prenait une demi-journée (comprendre les certificats, configurer Xcode, rédiger les textes en plusieurs langues, générer les assets) se fait maintenant en 30 minutes.

Le vibe coding ne s'arrête pas au code. Il s'étend maintenant au pipeline entier.

Retour aux articles