2026-04-30 Migration iOS CI d Intel x86_64 vers Apple Silicon ARM64 avec xcodebuild sur Mac cloud loue (HK / JP / KR / SG / US)

Apple livre encore Xcode pour Intel, mais 2026 est l annee ou beaucoup d equipes mobiles cessent de payer la taxe cloud pour des tranches x86_64 qu elles n expedient plus. Si votre file pointe encore vers de vieux Mac mini Intel alors que vos binaires produit sont arm64 uniquement, vous financez des graphes de dependances dupliques et des demarrages a froid xcodebuild test plus lents que vos concurrents deja passes sur des builders Mac mini M4 a Hong Kong, Tokyo, Seoul, Singapour ou aux Etats Unis. Ce texte du 2026-04-30 est un memo de migration pour l ingenierie release : inventoriez les binaires gras, normalisez ARCHS, defaites les vendeurs CocoaPods sans tranche Apple Silicon, maintenez une double file assez longtemps pour mesurer la flakiness, puis routez par defaut vers ARM64 en gardant une voie secours Intel pour les CLI heritees. Il complete les patterns d Archive distante, les voies xcodebuild paralleles, la matrice multi Xcode, et les garde fous Swift 6 strict concurrency qui reagissent differemment sous charge parallele.

Vue 2026 : pourquoi ca compile sur mon M3 portable ne suffit pas

Les portables masquent des peches : caches modules tiedes, toolchains vues a travers Rosetta, patience humaine. La CI doit les exposer en minutes. Trois signaux que vous etes en migration plutot qu au bout du parcours :

• Erreurs linker mentionnant undefined symbols for architecture arm64 alors que lipo -archs liste encore x86_64 sur frameworks vendeurs.
• Derive des destinations simulateur : destinations d ere Intel restent dans le YAML alors qu Apple a retire des images dans les bundles Xcode recents.
• Labels menteurs : tags GitHub Actions ou Buildkite disent macos-intel alors que le shell est arm64 car les noms ont ete recycles.

Inventaire binaire : prouver le x86_64 restant avant d accuser Swift

Parcourez chaque .framework, .a et XCFramework precompile sous Carthage/Build, Pods/ ou ThirdParty/. Deux commandes a coller dans chaque ticket de migration :

find . \( -name "*.framework" -o -name "*.a" -o -name "*.xcframework" \) -print0 | xargs -0 -I@ sh -c 'echo "@:"; lipo -info "@" 2>/dev/null || file "@"'

Lorsqu un editeur n offre qu Intel, ouvrez un fil commercial plutot qu un bricolage EXCLUDED_ARCHS=arm64 qui livre silencieusement Rosetta a toute l equipe. Sur hotes loues partages avec runners self hosted, centralisez le script d inventaire dans un depot infra pour que chaque region execute le meme detecteur ; la derive entre nœuds JP et US fabrique des tickets vert a Tokyo rouge en Virginie.

Matrice runners : responsabilites file Intel versus file ARM

Pendant la transition, chaque file doit porter des garanties explicites : ne pretendez pas que les deux CI sont identiques.

File	Portee	Hors scope
ARM64 principale	Checks PR par defaut, tests simulateur, Archives TestFlight	Outils CLI legacy sans build arm64 sauf bac a sable
Intel secours	Binaires vendeurs en attente de refresh, controles de parite ponctuels	Signature long terme ; evitez d y melanger cles production
Hybride fumee	Scripts file verifiant les tranches gras la ou requis	Dependance Rosetta silencieuse pour cibles app iOS

Drapeaux xcodebuild et build settings a transformer en politique

Encodez ce qui suit en extraits xcconfig partages ou exports Fastlane : discutez une fois, heritez partout.

Reglage	Valeur CI ARM64 recommandee	Commentaire
ARCHS	arm64	Explicite bat standard quand schemes divergent entre app et extensions.
ONLY_ACTIVE_ARCH	NO pour CI style Release ; YES pour boucle Debug interne si tranches minces acceptees.	Desaccord ici cree deltas flakys simulateur contre appareil.
EXCLUDED_ARCHS[sdk=iphonesimulator*]	Souvent vide sur hotes Apple Silicon	Retirez exclusions d ere Intel qui tuent arm64 simulateur par erreur.

Accouplez les drapeaux a un DEVELOPER_DIR fige par job suivant le guide matrice xcode-select : rien ne brouille un post mortem migration comme deux Xcode qui interpretent le meme projet differemment.

CocoaPods, SwiftPM et graphes binaires qui resistent a ARM64

Cote CocoaPods, regenerez Pods/ sur un hote arm64 plutot que rsync depuis Intel pour que phases script compilent avec la bonne arch. Cote SwiftPM, verifiez que les cibles binaires de Package.resolved incluent bien arm64-apple-ios quand applicable. Quand les frameworks retardent, preferez build source temporaire ou pin fork ; les interets s accumulent quotidiennement.

Double file : profondeur, memoire, disque

Les Mac mini Apple Silicon brillent jusqu a ce que trois Archives lourdes plus tests UI concurrents saturent 16 Go. Pendant la migration, plafonnez les jobs xcodebuild simultanes par hote selon la pression memoire mesuree : labels distincts pour pool ARM compilation seule versus pool ARM Archive. Cote disque, ARM64 ne reduit pas DerivedData : couplez la migration avec l isolation DerivedData pour que les experiences ne s evictent pas mutuellement.

Huit etapes de bascule que votre SRE peut coller dans Jira

1. Geler les bumps dependances 72 heures avant le week end de bascule.
2. Executer le script inventaire sur chaque hote regional ; commiter les diffs dans le depot infra.
3. Appliquer la politique xcconfig a tous schemes y compris extensions.
4. Rebootstrap Pods ou SwiftPM depuis checkouts propres sur arm64.
5. Activer deux files avec memes graines ; comparer duree, flakiness, tailles artefacts.
6. Basculer routage PR par defaut vers ARM64 en laissant file Intel lecture seule.
7. Observer 14 jours ; en cas de pic d echecs, rollback des labels pas des secrets.
8. Decommissionner Intel ou le reléguer a taches de niche avec tags facturation hors chemins mobiles.

Table metriques : a quoi ressemble le succes sur M4 loue

Indicateur	Base Intel exemple	Cible ARM64
Build propre p50	19,5 min	12,0 min ou mieux sur meme commit
Tests UI simulateur p95	41 min	28 a 33 min apres normalisation destinations
Proxy cout energie hebdo	1,00 normalise	0,62 a 0,78 combine watts repos et debit

Remplacez les exemples par vos histogrammes Grafana ou Buildkite : jamais de deck migration sans courbes brutes.

FAQ : Rosetta, simulateurs, signature

Question	Reponse pratique au 2026-04-30
La CI doit elle tourner sous Rosetta pour la vitesse ?	Non pour compilation iOS : toolchains arm64 natives gagnent ; Rosetta reste pour outils peripheriques herites.
Faut il des identites de signature separees par arch ?	Les identites ne sont pas specifiques arch, mais profils et entitlements doivent correspondre aux binaires reellement expedies : reexportez apres changement de graphe.

Pour l automatisation signature, poursuivez avec trousseau et provisioning CI : les migrations d arch reveillent souvent des ecarts de profil latents.

Pourquoi le pari migration reste sur Mac mini M4 bare metal

La CI ARM64 n est pas seulement la vitesse d horloge : c est un comportement d outillage deterministe sans mensonges hyperviseur. Un Mac mini M4 loue avec 1 a 2 To NVMe sur les regions MacXCode laisse de la marge pour double file, plusieurs arbres DEVELOPER_DIR, et pics DerivedData pendant que vos ingenieurs dorment ailleurs. Cette marge transforme la migration en deploiement mesurable et reversible, surtout avec des tarifs transparents pour ajouter un second nœud plutot que surcharger le premier. Pour la conformite visuelle, VNC reste ponctuel ; le quotidien migration reste SSH et journaux greppables.