2026-04-30 iOS-CI-Migration von Intel x86_64 zu Apple Silicon ARM64 mit xcodebuild auf Miet-Cloud-Mac (HK / JP / KR / SG / US)

Apple liefert weiter Xcode fuer Intel, doch 2026 hoert der Grossteil der Mobile-Teams auf, Cloud-Kosten fuer x86_64-Slices zu zahlen, die die App gar nicht mehr ausliefert. Wenn Ihre Runner-Queue noch alte Intel-Mac-mini-Knoten nutzt, waehrend Produktbinaries nur noch arm64 tragen, finanzieren Sie doppelte Abhaengigkeitsgraphen und langsamere Kaltstarts von xcodebuild test als Teams, die bereits auf Mac mini M4-Builder in Hongkong, Tokio, Seoul, Singapur oder den USA standardisiert haben. Dieser Beitrag vom 2026-04-30 ist ein Migrationsbrief fuer Release Engineering, kein Verkaufsprospekt: Fette Binaerien inventarisieren, ARCHS vereinheitlichen, CocoaPods-Anbieter ohne Apple-Silicon-Slice abarbeiten, eine Zwei-Spuren-Matrix so lange fahren, bis Flakes statistisch erklaerbar sind, dann Standard-Routing auf ARM64 legen und eine Breaker-Leitung fuer seltene Legacy-CLIs behalten. Ergaenzen Sie ihn mit Remote-Archive-Workflows, parallelen xcodebuild-Jobs, mehreren Xcode-Versionen und xcode-select sowie Swift 6 Strict Concurrency, weil sich diese Pruefungen unter Last anders verhalten.

Lagebild: Warum „auf meinem M3-Notebook gruen“ nicht reicht

Notebooks verdecken warme Modul-Caches, Rosetta-transparente Toolchains und menschliche Geduld. CI soll Probleme in Minuten sichtbar machen. Drei Signale, dass Sie mitten in der Migration stecken statt fertig:

• Linkerfehler mit undefined symbols for architecture arm64, waehrend lipo -archs bei Vendor-XCFrameworks noch x86_64 listet.
• Simulator-Destination driftet: Intel-aera YAML bleibt liegen, Apple entfernt aber Geraetebilder aus neueren Xcode-Bundles.
• Runner-Labels luegen: Tags wie macos-intel in GitHub Actions oder Buildkite, obwohl die Shell bereits arm64 ist, weil Ops Namen wiederverwendet hat.

Binaer-Inventur: x86_64 belegen, bevor Swift die Schuld traegt

Gehen Sie jede .framework-, .a- und vorkompilierte XCFramework-Datei unter Carthage/Build, Pods/ oder ThirdParty/ durch. Zwei Kommandos gehoeren in jedes Migrations-Ticket:

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

Finden Sie Anbieter, die nur Intel liefern, oeffnen Sie einen kommerziellen Thread statt EXCLUDED_ARCHS=arm64 als Heilmittel zu tarnen und Rosetta still in Produktion zu schieben. Auf Miet-Hosts neben GitHub Actions Self-Hosted Runnern gehoert das Inventur-Skript in ein zentrales Infra-Repo, damit jede Region dieselbe Detektor-Version faehrt. Drift zwischen JP- und US-Knoten erzeugt Tickets der Sorte „Tokio gruen, Virginia rot“.

Runner-Matrix: Intel-Leitung versus ARM64-Primaerpfad

In der Uebergangsphase braucht jede Leitung klare Verantwortung statt der Illusion „dasselbe CI“.

Leitung	Uebernimmt	Darf nicht
ARM64 Primaer	Standard-PR-Checks, Simulator-Tests, TestFlight-Archive	Legacy-CLI ohne arm64-Build ausserhalb klarer Sandbox
Intel Breaker	Vendor-Binaerien bis Refresh, einmalige Paritaetspruefungen	Langfristige Signing-Pfade ohne klare Trennung von Produktionskeys
Smoke Hybrid	Skriptierte file-Pruefungen fuer Fat-Slices wo noetig	Stille Rosetta-Abhaengigkeit fuer iOS-App-Ziele

xcodebuild-Flags und Build-Settings als Policy

Legen Sie die folgenden Werte als gemeinsame xcconfig-Snippets oder Fastlane-Env-Exports fest einmal diskutieren, dann vererben.

Setting	PR-CI (arm64)	Release / Archive	Hinweis
ARCHS	arm64	arm64	Explizit schlaegt „Standard“, wenn App und Extensions unterschiedliche Schemes haben.
ONLY_ACTIVE_ARCH	YES moeglich fuer schnelle Debug-Schleifen	NO fuer release-nahe CI	Mismatch erzeugt flaky Geraet-versus-Simulator-Deltas.
EXCLUDED_ARCHS[sdk=iphonesimulator*]	Leer auf Apple Silicon	Leer pruefen	Intel-Aera-Ausschluesse koennen arm64-Sim-Builds unbrauchbar machen.

Kombinieren Sie Flags mit fixiertem DEVELOPER_DIR gemaess xcode-select-Matrix; nichts verwirrt Retros so sehr wie zwei Xcode-Versionen, die dasselbe Projekt unterschiedlich lesen.

CocoaPods, SwiftPM und Binaergraphen gegen ARM64

CocoaPods-Teams sollten Pods/ auf einem arm64-Host neu erzeugen statt per rsync von Intel zu kopieren, damit Script-Phasen mit der richtigen Architektur laufen. SwiftPM-Teams pruefen Package.resolved auf Binaerziele mit arm64-apple-ios wo noetig. Wenn Vendor-Frameworks hinterherhaengen, helfen temporaere Source-Builds oder Fork-Pins Zinsen laufen taeglich.

Zwei-Spuren-Scheduling: Queue-Tiefe, Speicher, Disk

Apple-Silicon-Mac-minis skalieren gut, bis drei schwere Archives plus UI-Tests parallel auf 16 GB laufen. Capen Sie xcodebuild-Parallelitaet nach gemessenem Speicherdruck und trennen Sie Labels fuer „ARM nur Compile“ versus „ARM Archive“. ARM64 verkleinert DerivedData nicht magisch koppeln Sie die Migration mit DerivedData- und xcresult-Isolation, damit Experimente sich nicht gegenseitig aus dem Cache werfen.

Acht-Schritte-Checkliste fuer SRE und Release

1. Einfrieren von Dependency-Bumps 72 Stunden vor Cutover-Wochenende.
2. Inventur-Skript auf jedem Regional-Host; Diff der Outputs ins Infra-Repo committen.
3. xcconfig-Policy auf alle Schemes inklusive Extensions anwenden.
4. Pods/SwiftPM aus sauberem Checkout auf arm64 neu bootstrappen.
5. Zwei Queues mit identischem Seed aktivieren Wandzeit, Flake-Rate, Artefaktgroessen vergleichen.
6. Standard-PR-Routing auf ARM64 Intel-Leitung nur noch read-only Breaker.
7. 14 Tage beobachten bei Spike Labels zurueckdrehen, nicht Secrets.
8. Intel dekommissionieren oder auf Spezialjobs mit klar getrennten Billing-Tags verweisen.

Kennzahlen: Erfolg auf gemietetem M4 messbar machen

KPI	Messung	Intel-Referenz (Beispiel)	ARM64-Ziel
Clean build p50	CI-Timer gleicher Commit-SHA	19,5 min	12,0 min oder besser
Simulator-UI-Test p95	Pipeline-Histogramm	41 min	28–33 min nach Destination-Normalisierung
Strom-Kosten-Proxy Woche	Normalisiert auf Intel=1	1,00	0,62–0,78 bei Idle-Watt plus Durchsatz

Ersetzen Sie Beispielwerte durch eigene Grafana- oder Buildkite-Exporte eine Migrations-Story ohne Rohhistogramme ist Marketing, kein Engineering.

FAQ: Rosetta, Simulatoren, Signing

Frage	Antwort (2026-04-30)
Soll CI unter Rosetta laufen fuer Speed?	Nein fuer iOS-Kompilat native arm64-Toolchains gewinnen Rosetta nur fuer alte Hilfs-CLIs.
Brauchen wir getrennte Signing-Identities pro Architektur?	Identities sind nicht architekturgebunden Profile und Entitlements muessen aber zu den tatsaechlich ausgelieferten Binaerien passen nach Graph-Aenderungen neu exportieren.

Fuer Signing-Automation lesen Sie Keychain und Provisioning in CI Architekturwechsel decken oft versteckte Profile-Mismatches auf.

Warum Mac mini M4 Bare Metal die Migration traegt

ARM64-CI geht nicht nur um Taktfrequenz, sondern um deterministisches Toolchain-Verhalten ohne Hypervisor-Ueberraschungen. Ein gemieteter Mac mini M4 mit 1–2 TB NVMe auf MacXCode-Regionen laesst Zwei-Spuren-Fahrplaene, mehrere DEVELOPER_DIR-Baeume und DerivedData-Spitzen zu, waehrend Ihr Team in einer anderen Zeitzone schlaeft. Dieser Puffer macht Migration messbar und rueckgaengig machbar besonders mit transparenten Preisen fuer einen zweiten Knoten statt Ueberlastung des ersten. VNC nur sparsam fuer Compliance-Sichtpruefungen der Alltag bleibt SSH-Logs, die Sie per ripgrep auswerten. Zugang und Haertung: Hilfe.