Wie prüft man iOS-CI-Build-Timeouts? Mac-Kapazitätsleitfaden 2026

Ein selbstverwalteter Runner erhält einen CI-Auftrag nur dann, wenn seine Labels und die Workflow-Anforderung zusammenpassen. Das ist in der offiziellen Dokumentation zu selbstverwalteten Runnern ausdrücklich beschrieben. Deshalb gilt für das Prüfen von iOS-CI-Build-Timeouts: Nicht sofort weitere Mac-Knoten bestellen. Zuerst muss die Zeitachse zeigen, ob der Auftrag wartet, keinen Runner erreicht, Abhängigkeiten lädt, in xcodebuild steckt, den Simulator startet, signiert oder beim Upload blockiert. Erst wenn gesunde Knoten dauerhaft ausgelastet sind, die Warteschlange mit der Parallelität wächst und einzelne Builds nicht auffällig langsam sind, ist eine Erweiterung oder eine elastische Mac-Lösung begründet.

Diese Anleitung richtet sich an:

• IT-Verantwortliche, die entscheiden müssen, ob zusätzliche Mac-Ressourcen das CI-Problem tatsächlich lösen.
• Plattformverantwortliche, die eine Beweiskette vom Runner-Zustand bis zum einzelnen Build-Schritt benötigen.
• Verantwortliche für Developer Productivity und Releases, die Wartezeiten in Spitzenphasen reduzieren müssen.

[ SECTION_01 ] Die Gesamtzeit ist kein Fehlerbild

Ein Timeout am Ende der Pipeline beschreibt zunächst nur ein Ergebnis. Es sagt nicht, welcher Teil der Kette versagt hat. Für die Kapazitätsentscheidung muss die Pipeline deshalb in beobachtbare Zustände zerlegt werden:

1. Auftrag wurde erzeugt.
2. Auftrag wartet auf eine passende Ausführungsbedingung.
3. Ein Mac Runner nimmt den Auftrag an.
4. Repository und Unterprojekte werden geladen.
5. Abhängigkeiten und Artefakte werden aufgelöst.
6. xcodebuild kompiliert oder testet.
7. Simulator oder physisches Testgerät wird vorbereitet.
8. Zertifikate und Provisioning-Profile werden verwendet.
9. Artefakt wird signiert und hochgeladen.

Diese Zustände gehören in eine gemeinsame Zeitachse. Die Quelle muss dabei nicht nur die CI-Oberfläche sein. Relevant sind auch Runner-Log, Workflow-Log, xcodebuild-Ausgabe, Netzwerkfehler, Cache-Status und gegebenenfalls der Zustand des Keychains.

Apple beschreibt xcodebuild als Kommandozeilenwerkzeug für Build-, Test- und Archivierungsaufgaben. Die Apple-Referenz zu xcodebuild ist daher die geeignete Grundlage, um zwischen „Build wurde nicht gestartet“ und „Build läuft, aber ein konkreter Schritt hängt“ zu unterscheiden.

Ein minimales Beweisprotokoll

Für jeden fehlgeschlagenen Auftrag sollten folgende Felder erfasst werden:

Beweisfeld	Zu erfassende Information	Aussage für die Kapazität
Auftrag	Startzeit, Workflow, Branch, Auslöser	Zeigt den tatsächlichen Lastzeitpunkt
Routing	angeforderte Labels, Runner Group, Status	Trennt Fehlrouting von Überlastung
Annahme	Zeitpunkt der Runner-Zuweisung	Macht Queue-Zeit sichtbar
Vorbereitung	Git, LFS, Swift Package, Artefakte	Zeigt Abhängigkeits- und Netzwerkprobleme
Build	xcodebuild-Phasen, DerivedData, Tests	Zeigt Einzelaufgaben und Ressourcenkonflikte
Signierung	Keychain, Zertifikate, Profile	Trennt Sicherheitsfehler von Rechenlast
Abschluss	Upload, Release-Service, Retry	Verhindert falsche Zuordnung zum Mac

Ein Auftrag ohne Annahmezeitpunkt darf nicht als Beweis für zu geringe Mac-Kapazität gelten. Ebenso ist ein einzelner langsamer Build kein Beweis für eine zu kleine Runner-Flotte. Erst wiederholte Beobachtungen unter vergleichbarer Last erlauben eine belastbare Entscheidung.

[ SECTION_02 ] Wenn der Mac Runner frei ist und die Pipeline trotzdem wartet

Ein „Idle“-Status auf dem Mac bedeutet nicht automatisch, dass der konkrete Auftrag sofort laufen kann. Häufige Ursachen liegen außerhalb der Rechenleistung:

• Das Workflow-Label passt nicht zum Label des Runners.
• Der Runner ist zwar online, gehört aber zur falschen Runner Group.
• Die Gruppe darf den Workflow oder das Repository nicht verwenden.
• Eine Parallelitätsregel hält den Auftrag zurück.
• Ein vorheriger Job oder ein benötigtes Artefakt ist noch nicht abgeschlossen.
• Der Runner wird als verfügbar angezeigt, kann aber den benötigten Toolchain-Zustand nicht bereitstellen.

Die Dokumentation zur Label-Zuweisung bei selbstverwalteten Runnern zeigt, wie Labels für die Auswahl verwendet werden. Für die Diagnose genügt deshalb nicht die Frage, ob ein Knoten frei aussieht. Entscheidend ist, ob er die exakt geforderten Eigenschaften besitzt und für den betreffenden Workflow zugelassen ist.

Auch die Workflow-Dokumentation zur Auswahl selbstverwalteter Runner sollte gegen die tatsächliche Konfiguration geprüft werden. In der Beweistabelle stehen mindestens angeforderte Labels, tatsächliche Labels, Runner Group, Online-Status und Zeitpunkt der Auftragserteilung.

So lässt sich eine Routing-Störung von Kapazitätsmangel trennen

Eine Routing-Störung liegt nahe, wenn ein Auftrag wartet, obwohl ein kompatibler Knoten frei ist. Ein Kapazitätsproblem wird wahrscheinlicher, wenn mehrere passende Knoten gesund sind, Aufträge korrekt angenommen werden und die Wartezeit mit steigender gleichzeitiger Last zunimmt.

Die Bewertung sollte pro Workflow erfolgen. Ein Produktions-Workflow mit Signierung kann andere Labels und Berechtigungen benötigen als ein Pull-Request-Build. Werden beide Kategorien in einer gemeinsamen Gruppe betrachtet, kann die sichtbare Leerlaufzeit einzelner Knoten irreführend sein.

Die offizielle Beschreibung von Concurrency in GitHub Actions ist für diesen Prüfschritt relevant. Eine absichtlich begrenzte Ausführung kann wie fehlende Mac-Kapazität aussehen, obwohl die Begrenzung aus der Workflow-Logik stammt.

[ SECTION_03 ] Abhängigkeiten erzeugen häufig ein falsches Kapazitätssignal

Vor dem eigentlichen Kompilieren können mehrere externe Systeme die Pipeline verlangsamen. Dazu zählen Git-Server, Git LFS, Swift Package Manager, private Paketquellen, Proxy-Regeln, Artefakt-Repositories und Apple-Dienste. Ein Mac mit niedriger CPU-Auslastung kann währenddessen trotzdem einen belegten Runner darstellen.

Die Diagnose sollte zwischen drei Fällen unterscheiden:

• Erster Abruf: Daten fehlen lokal und müssen vollständig geladen werden.
• Cache-Miss: Wiederverwendbare Daten sind nicht vorhanden oder wurden verworfen.
• Externer Dienst langsam oder nicht erreichbar: Der Cache kann das Problem nicht zuverlässig beheben.

Ein Cache ist kein Ersatz für korrekte Zugangsdaten, eine erreichbare private Registry oder eine stabile Versionsauflösung. Wird eine Abhängigkeit bei jedem Lauf neu aufgelöst, muss zunächst die Ursache der fehlenden Wiederverwendung geklärt werden. Ein zusätzlicher Mac würde dann nur mehr parallele Warteprozesse erzeugen.

Fünf Prüfschritte für Abhängigkeiten und Netzwerk

1. Zeitstempel vergleichen: Der Beginn des Dependency-Schritts muss gegen den ersten xcodebuild-Aufruf gestellt werden.
2. Cache-Zustand dokumentieren: Für jeden Lauf wird festgehalten, ob der Cache vorhanden, gültig und tatsächlich verwendet wurde.
3. Retry-Muster erfassen: Wiederholte Netzwerkversuche sprechen eher für Erreichbarkeit oder Servicequalität als für fehlende Mac-Leistung.
4. Private Quellen isolieren: Ein öffentlicher Abruf und ein Zugriff auf das interne Repository sollten getrennt bewertet werden.
5. Versionen fixieren: Driftende Paketversionen können sowohl längere Auflösung als auch unterschiedliche Build-Ergebnisse verursachen.

Erst wenn die Abhängigkeitszeit stabil und der Auftrag tatsächlich im Build-Schritt angekommen ist, besitzt ein Vergleich der Mac-Ressourcen Aussagekraft.

[ SECTION_04 ] Xcode, Simulator und Signierung getrennt bewerten

Ein langsamer iOS-Build kann mehrere technische Ursachen haben. Die Dokumentation zum Apple-Build-System liefert den Rahmen für die Analyse von Build-Aufgaben. In der Praxis sollte die Pipeline jedoch nicht nur die Gesamtzeit von xcodebuild protokollieren, sondern die einzelnen Phasen und deren Ergebnisstatus.

Einzelaufgabe oder gegenseitige Konkurrenz?

Wenn derselbe Build auf einem unbelasteten Knoten ebenfalls auffällig lange läuft, liegt die Ursache eher im Projekt, in der Abhängigkeitsauflösung oder im Build-Schritt selbst. Wenn ein einzelner Lauf normal ist, mehrere parallele Läufe auf demselben Mac jedoch deutlich schlechter werden, spricht das eher für Ressourcen- oder I/O-Konkurrenz.

Zu prüfen sind:

• Speicherplatz für Quellcode, DerivedData und temporäre Archive.
• Arbeitsspeicherdruck während Kompilierung und Tests.
• Gleichzeitige Jobs auf demselben Knoten.
• Größe und Lebensdauer von DerivedData.
• Prozesszustände während xcodebuild.
• Abbruch- und Wiederholungsmuster.

CPU-Auslastung allein reicht nicht als Nachweis. Ein Build kann auf I/O, Paketauflösung, Prozesssynchronisation oder Simulator-Kommunikation warten, während die CPU nicht voll beschäftigt ist.

Simulator und Testausführung

Simulatorprobleme müssen separat erfasst werden. Die Apple-Dokumentation zum Ausführen einer App auf simulierten oder physischen Geräten beschreibt den relevanten Ausführungskontext. Für die CI-Analyse gehören daher Simulatorstart, Gerätezustand, Testbeginn und Testabschluss jeweils als eigene Zeitpunkte in das Protokoll.

Die Apple-Anleitung zum Interpretieren von Testergebnissen hilft dabei, Testfehler nicht mit einem allgemeinen Build-Timeout zu vermischen. Ein Test, der nicht startet, ein Test, der lange läuft, und ein Test, der wegen eines Gerätezustands scheitert, benötigen unterschiedliche Maßnahmen.

Signierung ist ein eigener Fehlerbereich

Signierung und Distribution verlangen einen kontrollierten Zugriff auf Zertifikate, Profile und Keychain. Apple beschreibt den Prozess in der Dokumentation zur Erstellung signierter Distributionssoftware. Für die Kapazitätsentscheidung ist wichtig: Ein blockierter Signierungsschritt wird nicht automatisch durch mehr allgemeine Build-Knoten gelöst.

Produktive Signaturknoten sollten daher von gewöhnlichen Pull-Request-Knoten getrennt bewertet werden. Wenn die Build-Phase gesund ist, aber der Signaturzugriff auf Berechtigungen, Keychain-Kontext oder Profile wartet, liegt die richtige Maßnahme in der Zugriffskette und nicht in einer größeren Runner-Flotte.

Hinweis: Ein neuer Mac-Knoten kann eine fehlerhafte Signaturkonfiguration vervielfachen. Vor der Erweiterung muss ein echter Testlauf mit demselben Zertifikats-, Profil- und Berechtigungskontext erfolgreich abgeschlossen werden.

[ SECTION_05 ] Entscheidung nach Beweislage statt nach Bauchgefühl

Die folgende Tabelle ordnet die häufigsten Befunde einer Maßnahme zu. Die Bewertung bezieht sich auf die Aussagekraft für eine Kapazitätsentscheidung, nicht auf die technische Schwere des Fehlers.

Befund	Wahrscheinlicher Fehlerbereich	Erste Maßnahme	Eignung für sofortige Erweiterung
Auftrag wartet ohne passende Runner-Zuweisung	Label, Gruppe oder Berechtigung	Routing korrigieren	Niedrig
Runner nimmt Auftrag an, Vorbereitung bleibt stehen	Git, Paketquelle, Proxy oder Cache	Abhängigkeiten und Netzwerk prüfen	Niedrig
Einzelner xcodebuild-Lauf ist auf jedem Knoten langsam	Projekt oder Build-Konfiguration	Build- und Dependency-Analyse	Niedrig
Einzelne Läufe sind normal, parallele Läufe konkurrieren	Knoteninterne Ressourcen	Job-Isolation oder Parallelität anpassen	Mittel
Signierung wartet bei gesunder Build-Phase	Keychain, Profile oder Zertifikate	Signaturpfad isolieren	Niedrig
Gesunde Knoten sind dauerhaft beschäftigt und Queue wächst	Reale Kapazitätsgrenze	Kapazität, Pool oder Elastizität planen	Hoch
Last tritt nur in Release-Fenstern auf	Spitzenlast	Zeitweise Zusatzkapazität prüfen	Hoch für elastische Lösung

Entscheidungsbedingungen für die nächste Maßnahme

• Wenn die Aufgabe keinen passenden Runner erreicht, dann Labels, Runner Group und Berechtigungen korrigieren. Zusätzliche Macs warten auf dieselbe falsche Route.
• Wenn der größte Zeitanteil beim Repository, bei Paketen oder bei einem Proxy entsteht, dann Abhängigkeitstopologie und Cache-Verhalten untersuchen.
• Wenn ein einzelner Build unabhängig von der Parallelität langsam bleibt, dann Projekt, xcodebuild-Phasen und Testaufteilung optimieren.
• Wenn Signierung oder Upload blockieren, dann Produktionsknoten und Berechtigungen separat prüfen.
• Wenn kompatible und gesunde Runner kontinuierlich beschäftigt sind, dann Queue-Wachstum, Spitzenparallelität und akzeptable Wartezeit in ein Kapazitätsmodell übernehmen.
• Wenn die Last nur bei Releases, Migrationen oder kurzfristigen Testphasen auftritt, dann elastische Mac-Kapazität oder einen zeitlich begrenzten Miettest bewerten.
• Wenn die Last dauerhaft und planbar ist, dann feste Knoten, einen gemeinsamen Build-Pool oder einen dedizierten Signaturknoten mit den laufenden Betriebsaufgaben vergleichen.

Das Modell benötigt keine erfundenen Leistungswerte. Es arbeitet mit Variablen:

• (P): Spitzenparallelität,
• (T): typische Ausführungsdauer,
• (Q): akzeptable Wartezeit,
• (F): feste Runner-Anzahl,
• (R): Reserve für Wartung und Ausfälle.

Diese Variablen müssen aus Unternehmensaufzeichnungen stammen. Herstellerwerte oder allgemeine Benchmarks ersetzen keine Messung der eigenen Pipeline.

[ SECTION_06 ] Erweiterung in sieben Schritten abnehmen

Eine Erweiterung ist erst abgeschlossen, wenn der neue Knoten nicht nur online erscheint, sondern einen vollständigen Unternehmens-Workflow zuverlässig durchläuft.

1. Routing prüfen: Der Knoten besitzt nur die Labels und Gruppen, die tatsächlich benötigt werden.
2. Echten Auftrag senden: Ein produktionsnaher Workflow muss den neuen Knoten erreichen. Ein bloßer Health-Check genügt nicht.
3. Abhängigkeiten vergleichen: Repository-Zugriff, Paketquellen, Cache und Proxy verhalten sich wie auf dem Referenzknoten.
4. Build ausführen: xcodebuild muss mit dem vorgesehenen Workspace, Scheme und der definierten Toolchain laufen.
5. Simulator oder Gerät prüfen: Teststart, Testausführung und Ergebnisexport werden separat protokolliert.
6. Signierung und Upload testen: Zertifikate, Profile, Keychain-Kontext und Artefaktübergabe werden im vorgesehenen Sicherheitsbereich geprüft.
7. Wiederanlauf nach Störung testen: Nach einem kontrollierten Neustart muss der Knoten wieder registriert werden und ein Auftrag muss erneut nachvollziehbar angenommen werden.

Für jeden Schritt sollte die Plattform einen Beleg speichern: Logauszug, Zeitstempel, Auftrag-ID oder Ergebnisartefakt. Dadurch wird aus „der neue Mac ist verfügbar“ die belastbare Aussage „der neue Mac verarbeitet den relevanten Workflow“.

[ SECTION_07 ] Was die Ergebnisse für Kauf, Pool oder Mac-Miete bedeuten

Ein fester Mac-Pool passt zu einer konstanten Last, klaren Wartungsfenstern und einer Organisation, die Betrieb, Ersatzgeräte, Updates und Sicherheitskontrollen selbst tragen kann. Ein dedizierter Signaturknoten passt zu einem Workflow, dessen Schlüsselmaterial nicht mit gewöhnlichen Build-Aufgaben geteilt werden soll.

Ein gemeinsamer Pool ist sinnvoll, wenn Jobs technisch gleichartig sind und die Parallelität schwankt. Die Labels müssen dann präzise genug sein, damit ein Produktionsjob nicht versehentlich auf einem ungeeigneten Knoten landet.

Eine elastische Remote-Mac-Lösung eignet sich vor allem für kurze Spitzen, Pilotprojekte und Release-Fenster. Sie sollte nicht als Ausweg für ungeklärte Routing-, Keychain- oder Dependency-Fehler verwendet werden. Für eine seriöse Bewertung muss mindestens eine reale Pipeline durchlaufen: Annahme, Abhängigkeiten, xcodebuild, Tests, Signierung, Upload und Wiederherstellung.

Wer zunächst die Beschaffung statt die Diagnose vergleichen möchte, kann die verfügbaren Mac-Beschaffungsoptionen für Unternehmen gegen einen zeitlich begrenzten Test stellen. Für eine elastische Variante ist die NOVAKVM-Übersicht für Remote-Mac-Zugriff der passende nächste Einstieg. Entscheidend bleibt dabei nicht die Anzahl der angebotenen Knoten, sondern der Nachweis, dass die konkrete Pipeline korrekt geroutet wird und die Sicherheitsgrenzen eingehalten werden.

Bei einer vorhandenen Mac-Flotte sind zusätzliche Geräte langfristig oft die bessere Wahl, wenn die Last gleichmäßig anfällt, lokale Peripherie benötigt wird oder das Unternehmen die gesamte Betriebsverantwortung bewusst intern halten will. Die Nachteile liegen in Kapitalbindung, Beschaffung, Austausch, Wartungsfenstern und ungenutzter Reserve außerhalb der Spitzenzeiten.

Bei einer kurzfristigen Erweiterung kann NOVAKVM die angenehmere Option sein, weil kein zusätzlicher physischer Bestand für eine vorübergehende Lastspitze aufgebaut werden muss. Das ersetzt keine TCO-Prüfung und keine Sicherheitsfreigabe. Es erlaubt jedoch, eine echte CI/CD-Kette zunächst unter kontrollierten Bedingungen zu testen, bevor das Unternehmen weitere Macs kauft oder einen dauerhaften Pool dimensioniert. Als nächster Schritt sollte die Plattformverantwortung die eigene Beweismatrix ausfüllen und genau einen repräsentativen Workflow für einen begrenzten Remote-Mac-PoC auswählen.