Warum machte WWDC 2026
iOS CI noch langsamer?

Am Montagmorgen, dem 9. Juni, schlugen in den Slacks von iOS-Verantwortlichen fast gleichzeitig drei Nachrichten auf: „Main-Archive ist über Nacht von 11 auf 34 Minuten gestiegen", „macos-latest wartet seit 18 Minuten und hat noch nicht angefangen", „Nach der Installation von Xcode 26 Beta ist DerivedData verschwunden." Das ist keine fehlerhafte Konfiguration in einem einzelnen Repository. Die WWDC-Saison provoziert jedes Jahr ein CI-Erdbeben. Die Ausgabe 2026 stapelt Speichermangel, keinen neuen Desktop-Mac und ein sichtbar schwereres Apple-Intelligence-SDK — die Erschütterungen sind diesmal stärker. Den Hintergrund zur Hardware-Abwesenheit findest du in Warum der M5 Mac mini bei der WWDC 26 fehlte. Dieser Artikel beantwortet genau eine Frage: warum deine Pipeline plötzlich langsamer ist — und was du jetzt ändern kannst.

1) Die drei typischen Symptome der CI-Verlangsamung nach WWDC

Öffne deine Actions-Logs. Triffst du mindestens zwei der folgenden Punkte zu, hast du es mit einer WWDC-Schockwelle zu tun — nicht mit einer Regression in deinem eigenen Code:

• Bootstrap-Phase explodiert: pod install, SPM-Auflösung und das Herunterladen des iOS-27-Simulator-Runtimes fressen jeweils mehrere Minuten — Hosted Runner starten jeden Job bei null, daher trifft es diese Phase am härtesten.
• Build fällt auf Vollkompilierung zurück: Nach einem Xcode-Major-Versionssprung sind ModuleCache und DerivedData-Format inkompatibel mit der alten Version. Inkrementelle Kompilierung bricht zusammen; die xcodebuild-Dauer nähert sich einem Kaltstart.
• Warteschlangen werden länger: Innerhalb von 72 Stunden nach WWDC aktualisieren Teams weltweit ihre Workflows, um die Beta zu testen, und überlasten den gemeinsam genutzten Pool an GitHub-gehosteten macOS-Minuten. Die Wartezeit kann den Build selbst übersteigen.

2) Xcode 26 Beta: erzwungene Cache-Bereinigungssaison

Apple hat die Xcode-26-Beta und das iOS-27-SDK am WWDC-Tag selbst veröffentlicht. Für einen lokalen Entwickler bedeutet das Upgrade Neu-Indexierung und kurzes Warten; für deine CI-Infrastruktur bedeutet es, dass der gesamte Disk-Zustand ungültig ist:

• Änderung des DerivedData-Pfads und Indexformats — alter Cache nicht wiederverwendbar; der erste Archive-Build nach dem Upgrade ist immer ein Vollbuild.
• Swift-Compiler-Versionswechsel — .swiftmodule-Binaries sind inkompatibel; alle Targets kompilieren von Grund auf neu.
• CocoaPods-/SPM-Lockfile-Instabilität — einige Pods unterstützen iOS 27 noch nicht, was pod install zu wiederholter Auflösung oder einem vollständigen repo-update veranlasst.
• Neues Simulator-Runtime — mehrere Gigabyte pro Runtime; Hosted Runner laden bei jedem Job neu herunter, was den Bootstrap um 5–15 Minuten verlängert.

Das tiefere organisatorische Risiko ist die druckgetriebene Beta-Übernahme: Am Tag nach dem Keynote fragt in jedem Unternehmen jemand „Unterstützen wir Siri AI?" — und das Team pusht Xcode 26 auf main, bevor es vorbereitet ist. Eine einzige Workflow-Änderung versetzt die gesamte CI-Flotte in den Kaltstart-Modus. Der richtige Ansatz ist die Pipeline-Trennung: Produktions-Release bleibt auf stabilem Xcode 16 gepinnt; nur ein ios-27-beta-Branch oder dedizierter Beta-Runner wird für Anpassungsarbeiten genutzt. Beachte die Xcode-Supportmatrix.

3) SDK-Aufblähung: Kompilieraufwand steigt, Rechenleistung bleibt gleich

Das Software-Narrativ der WWDC 26 dreht sich um Siri AI und die Apple-Intelligence-Erweiterung (MacRumors WWDC 26 Recap). Für App-Ingenieure bedeutet das konkrete Build-Mehrkosten:

• Neue Framework-Abhängigkeiten (App Intents, Vision/Speech-Pipeline-Abstraktionen) — mehr Module im Linker-Graphen.
• Strengere Swift-6-Concurrency-Prüfung — gleicher Quellcode, mehr Arbeit für den Compiler.
• Größere Asset Catalogs und Lokalisierungsressourcen — die Copy-Bundle-Resources-Phase wird merklich länger.

Auf einem lokalen M4 MacBook mit warmem Cache fühlen sich diese Ergänzungen vielleicht nach „zwei Minuten mehr" an. Auf einem Hosted Runner ohne persistenten Cache summieren sie sich mit der Kaltstart-Strafe und kippen „langsam" zu „inakzeptabel". Apple liefert KI-Features; die Rechnung zahlen Entwickler in der CI-Warteschlange.

4) Kein neuer Mac: der Rechenleistungs-Upgrade-Pfad ist blockiert

In vergangenen WWDC-Zyklen konnten sich Desktop-Teams zumindest damit trösten: „Wir kaufen nach der Konferenz einen neuen Mac mini fürs CI." 2026 gibt es keine Hardware-Ankündigungen; der M5 Mac mini wird für ein Herbstfenster erwartet, und globaler Speichermangel macht 24-GB-/32-GB-SKUs schwer beschaffbar. Die praktischen Folgen:

• Teams, die auf „Einkaufen als Weg aus langsamen Builds" gesetzt haben — Kaufentscheidung für 3–4 Monate eingefroren.
• Teams, die bereits M2-/M3-16-GB-Runner betreiben — nach dem SDK-Upgrade ist der Speicher enger; wenn swift-frontend und Simulator parallel laufen, setzt Swapping ein und Build-Zeiten verschlechtern sich nichtlinear.
• Teams, die einen zweiten Runner für mehr Parallelität hinzufügen wollten — Hardware-Lieferzeiten können die Beta-Anpassungs-Deadline nicht schlagen.

Das ist keine Behauptung, dass M4 zu schwach ist — für die überwiegende Mehrheit von iOS-CI ist M4 16 GB ausreichend. Der Punkt ist, dass die Hauptursache der Post-WWDC-Verlangsamung nicht die Chip-Leistung ist, sondern das Ausführungsmodell (Ephemeral vs. persistenter Disk). Auf den M5 zu warten, ersetzt ein Hardware-Narrativ durch ein echtes Engineering-Problem.

5) Der „WWDC-Massenansturm" auf Hosted Runner

Jedes Jahr im Juni erlebt der GitHub-gehostete macOS-Pool einen Nachfragespike. Die Besonderheit 2026: Das KI-Narrativ hat auch Nicht-iOS-Teams in macOS-Jobs gelockt — Core-ML-Konvertierungen durchführen, Apple-Intelligence-Beispielprojekte testen — die mit echten App-Release-Pipelines um denselben Pool konkurrieren.

Drei strukturelle Schwächen von Hosted Runnern werden in der WWDC-Saison verstärkt:

Auf macos-15- oder macos-latest-Labels zu wechseln hilft nicht — der Label-Wechsel tauscht das OS-Image aus, nicht „dein DerivedData bleibt morgen noch da". In unserer GitHub-Actions-iOS-CI-Geschwindigkeitsanalyse erreicht ein mittelgroßes Swift-Projekt auf Hosted Runnern ~28 min P50, wobei Warteschlange + Bootstrap meist mehr als die Hälfte ausmachen; eine Bootstrap-Inflation von +40 % post-WWDC ist in unseren Daten nicht ungewöhnlich.

6) Vor und nach WWDC: typische Zeitveränderungen am selben Repository (Sample)

Die folgenden Zahlen sind P50-Beobachtungen von Nuvcloud-Kunden, die ihr Runner-Modell nicht geändert haben — sie haben lediglich auf Xcode 26 Beta auf main umgestellt — Swift/UIKit-Projekt mit CocoaPods und Single-Scheme. Dies sind keine SLAs; validiere mit deinem eigenen Repository:

Dasselbe Repository auf einem self-hosted Mac mini M4 — Produktions-Jobs auf Xcode 16 gepinnt, nur der Beta-Runner auf Xcode 26 aktualisiert — hält den Produktions-P50 auf Pre-WWDC-Niveau. Die Beta-Linie braucht in der ersten Woche 20+ Minuten für den Vollbuild, berührt aber main nicht. Das ist der Wert der Runner-Trennung.

7) Was du jetzt tun solltest: Ausführungsmodell reparieren, nicht auf M5 warten

In den 48 Stunden nach WWDC priorisiere diese Maßnahmen:

1. Xcode-Version für Produktions-Release einfrieren — xcode-select oder DEVELOPER_DIR im Workflow hart kodieren; verhindern, dass main automatisch jeder Beta folgt.
2. Beta-Arbeit auf dediziertem Branch + Runner-Label — z. B. runs-on: [self-hosted, macos, xcode26-beta], isoliert vom Produktions-Label ios-ci.
3. Self-hosted Runner mit persistentem Disk nutzen — DerivedData, Pods und SPM-Caches überleben Job-Grenzen; der zweite Beta-Build fällt auf inkrementelle Zeiten zurück. Einrichtung: GitHub Self-hosted Runner Dokumentation.
4. Simulator-Runtimes nur einmal installieren — iOS-27-Runtime in das Runner-Image einbacken; nie mehr xcodebuild -downloadPlatform im Workflow-Schritt ausführen.
5. Mit 48-h-Tagesmietung validieren — bevor du ein Monatsabo abschließt, leih dir einen Cloud-Mac-mini für zwei Tage, um deinen echten Build zu benchmarken. Zur Regionswahl: Sechs-Regionen-Runner-TCO-Vergleich.

8) Häufige Fragen

Muss ich sofort nach WWDC auf Xcode 26 aktualisieren? Nein. App-Store-Einreichungen erfordern weiterhin eine stabile Xcode-Version; nutze die Beta nur für die frühe Adaption von iOS-27-APIs und halte sie auf einer dedizierten Pipeline isoliert.

Löst ein M5 Mac mini im Herbst das alles auf einen Schlag? Strukturell nicht. Ein neuer Chip kann einen Vollbuild um 10–15 % verkürzen, aber behebt nicht den Pro-Job-Kaltstart-Overhead. Angesichts des Speichermangels könnten 24-GB-/32-GB-M5-SKUs teuer sein — rechne den TCO durch, bevor dich der Launch-Hype mitreißt.

Reicht actions/cache für DerivedData nicht aus? In der WWDC-Saison normalerweise nicht. Cache-Keys werden nach einem Xcode-Major-Update invalidiert; zudem kostet die Netzwerkzeit für das Upload/Download von Gigabytes an DerivedData oft mehr, als es gegenüber einem lokal persistenten Disk einspart.

Was tue ich, wenn die Beta instabil ist und CI komplett rot wird? Das ist zu erwarten. Beta-Runner dürfen Main-Merges nie blockieren — markiere die Beta-Pipeline als optionalen Status-Check oder scheduliere sie nur als Nightly-Run.

Was macht WWDC 2026 schlimmer als die Vorjahre? Drei Faktoren gleichzeitig: KI-getriebene SDK-Aufblähung, Fehlen neuer Desktop-Hardware und Speicher-Lieferkettendruck. Jeder für sich ist beherrschbar; zusammen führen sie dazu, dass Verlangsamungen fälschlicherweise als „Hardware zu schwach" diagnostiziert werden — und zu falschen Hardwarekäufen oder blindem Zukauf von Hosted-Minuten.