2026 — Expo EAS iOS à cycle court : eas build --local, Mac cloud à la journée et matrice minutes vs semaine

Quand une équipe Expo livre plusieurs correctifs iOS par semaine, la file EAS devient vite un point de contention : profil de build déjà prêt, reviewers App Store en attente, mais minutes macOS consommées ou runners saturés. En 2026, la bonne question n'est plus « EAS ou local ? » ; c'est « à quel moment basculer eas build --local sur un Mac cloud loué à la journée, avec les mêmes secrets et les mêmes caches que le pipeline principal ? »

Quand basculer EAS vers un runner Mac cloud ?

Le build local n'est pas un remplacement permanent du service EAS : c'est une soupape lorsque le cycle court impose de maîtriser l'heure de départ, les certificats et le cache. On le déclenche surtout pour les hotfixes iOS, les validations de signature avant soumission et les branches où le coût d'attente dépasse le coût d'une journée de Mac dédié. Pour le contexte budgétaire, voir aussi Builds d'urgence et revue App Store en 2026 : acheter un Mac ou louer un Mac cloud à la journée ou à la semaine ?.

Injection des identifiants sans polluer le dépôt

Le runner doit recevoir exactement les mêmes secrets que le build EAS distant, mais jamais sous forme de fichiers committés. Le schéma le plus robuste combine un trousseau macOS éphémère, une clé App Store Connect API avec portée minimale, les profils de provisioning téléchargés au début du job et des variables Expo injectées depuis le coffre CI. Les certificats sont importés, utilisés, puis supprimés avec le trousseau de session.

# Les secrets arrivent du coffre CI, pas du dépôt
security create-keychain -p "$KEYCHAIN_PASS" eas-build.keychain
security import "$IOS_CERT_P12" -k eas-build.keychain -P "$P12_PASS" -T /usr/bin/codesign
mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
cp "$IOS_PROVISIONING_PROFILE" ~/Library/MobileDevice/Provisioning\ Profiles/

npm ci
npx expo prebuild --platform ios --clean
eas build --local --platform ios --profile production

Cette séquence doit rester lisible par l'équipe mobile. Si l'on ne sait pas rejouer un build à partir du log, la journée de Mac cloud se transforme en session de dépannage. La même logique vaut pour Flutter ou Android : isoler l'étape qui nécessite le matériel Apple, conserver le reste sur des agents moins chers ; l'article 2026 — sprint Flutter/Android à court cycle : Gradle sur Mac cloud à la journée face aux agents Linux auto-hébergés détaille cette séparation.

Clés de cache : Expo, Pods, DerivedData

Le piège classique consiste à ne cacher que node_modules. Pour un build iOS Expo, la clé utile doit relier quatre états : version de Xcode, lockfile npm ou pnpm, ios/Podfile.lock généré par prebuild et profil EAS. DerivedData peut accélérer une rafale sur la même branche, mais il devient toxique si la clé ignore Xcode ou les flags Swift.

expo-ios-${XCODE_VERSION}-${EAS_PROFILE}-${NODE_LOCK_HASH}-${PODFILE_LOCK_HASH}
pods-${XCODE_VERSION}-${PODFILE_LOCK_HASH}
deriveddata-${XCODE_VERSION}-${GIT_BRANCH_SLUG}-${NATIVE_HASH}

Pour une location à la journée, préchauffez les caches au début de la fenêtre : checkout, installation Node, prebuild et pod install. Ensuite, ne purgez DerivedData que lorsque app.json, les plugins Expo ou les dépendances natives changent. Pour une location à la semaine, versionnez une image de base et synchronisez seulement les deltas de branche.

Matrice : minutes EAS, journée Mac ou semaine louée ?

La décision doit combiner coût, risque de file et charge humaine. Les minutes EAS restent parfaites pour les builds réguliers et peu urgents. La journée Mac convient aux sprints de correction, aux validations de signature et aux tests avec plusieurs soumissions candidates. La semaine louée devient rationnelle dès qu'une équipe garde un rythme soutenu ou partage le runner entre plusieurs apps.

• Rester sur EAS minutes — moins de deux builds iOS urgents par semaine, queue stable, secrets déjà gérés
• Louer à la journée — fenêtre App Store courte, hotfix client, besoin de rejouer plusieurs archives
• Louer à la semaine — release train actif, plusieurs apps Expo, caches préchauffés rentables
• Runner dédié durable — conformité stricte, certificats long terme, nombreux jobs iOS parallèles

Le seuil pratique : si l'attente de file consomme plus de temps d'ingénierie que le prix d'un Mac cloud sur la période, la location gagne. Ajoutez aussi le coût des erreurs : certificat importé sur le mauvais poste, cache Pods incohérent, ou build local impossible à reproduire au moment de soumettre.

FAQ opérationnelle

Peut-on remplacer totalement EAS Build ? Pas forcément. Gardez EAS pour les chemins standards et utilisez le local build comme capacité de débordement contrôlée. L'objectif est de réduire la queue et de gagner de la visibilité, pas de maintenir une plateforme CI complète si vous n'en avez pas besoin.

Faut-il conserver le dossier ios/ dans Git ? Pour Expo managed, beaucoup d'équipes le régénèrent avec expo prebuild. Dans ce cas, la version des plugins et le lockfile deviennent critiques. Si vous commitez ios/, incluez son hash dans la clé de cache et documentez la version Xcode attendue.

Comment éviter les surprises de signature ? Utilisez une clé App Store Connect dédiée, des profils provisionnés par environnement, et un trousseau de job supprimé en fin de session. Vérifiez l'archive avec xcodebuild -exportArchive avant de considérer le build comme terminé.