Wie viele Macs braucht ein paralleler GitHub-Actions-iOS-Build 2026? Schätzung nach Teamgröße

Ein iOS-Workflow wartet, obwohl einzelne Builds ordentlich durchlaufen? Mehr Macs sind nicht automatisch die Lösung: Erfassen Sie zuerst gleichzeitige macOS-Jobs, Wartezeit und belegte Runner-Zeit und erweitern Sie danach in kleinen, überprüfbaren Schritten.

Für die Mac-Kapazität paralleler iOS-Builds mit GitHub Actions gibt es keine feste Zahl für alle Teams.
Für Einzelprojekte zählt, ob Wartezeiten regelmäßig auftreten; kleine Teams sollten ihre gewünschten Wartezeiten mit der tatsächlichen Parallelität abgleichen; Teams mit mehreren Repositories müssen zusätzlich die Verteilung auf gemeinsame oder getrennte Runner prüfen.

Dieser Leitfaden richtet sich an kleine iOS-Teams, die entscheiden möchten, ob eine Warteschlange zusätzliche Ausführungskapazität rechtfertigt, an Verantwortliche für mehrere Repositories sowie an Plattformteams, die selbst verwaltete Runner mit überprüfbaren Daten planen. Wenn Sie keine verzögerte macOS-Ausführung betreiben und auch keine planen, ist eine Mac-Kapazitätsschätzung für Ihre aktuelle CI wahrscheinlich nicht der nächste sinnvolle Schritt.

Einzelprojekte: sporadische Warteschlange oder dauerhafter Engpass?

Bei einem persönlichen Projekt wirken wenige gleichzeitig gestartete Workflows schnell wie ein Kapazitätsproblem. Entscheidend ist jedoch nicht, ob ein einzelner Lauf einmal warten musste, sondern ob sich die Verzögerung in einer repräsentativen Arbeitsperiode wiederholt und ob sie tatsächlich vor der Runner-Zuweisung entsteht.

Erfassen Sie pro Workflow mindestens den Auslöser, den Zeitpunkt des Starts, den Beginn der Ausführung, das Ende, den gewählten Runner und den Status. Die REST-Schnittstelle für Workflow-Jobs und ihre Laufzeitinformationen kann dabei helfen, Laufdaten strukturiert auszuwerten. Ergänzen Sie eigene Kennzahlen für die Zeit zwischen Auslösung und tatsächlichem Jobstart, denn die reine Ausführungsdauer beantwortet nicht, wie lange ein Job zuvor gewartet hat.

Achten Sie auf den Unterschied zwischen einem kurzfristigen Ausschlag und einer wiederkehrenden Belastung. Ein gebündelter Commit, eine manuell ausgelöste Testreihe oder ein Release kann vorübergehend mehrere Jobs anstoßen. Wenn die Warteschlange danach wieder verschwindet und der nächste Arbeitszyklus nicht erneut betroffen ist, wäre dauerhaft bereitgestellte Spitzenkapazität möglicherweise ungenutzt. Wenn Jobs dagegen regelmäßig auf freie Runner warten, während diese den passenden Workflow tatsächlich bedienen könnten, spricht das eher für einen echten Engpass.

Hinweis: Ein langsamer Workflow ist nicht zwangsläufig ein Warteschlangenproblem. Vergleichen Sie den Zeitpunkt der Auslösung mit dem Jobstart und trennen Sie diese Wartephase von der Zeit, in der der Runner den Job ausführt.

Für eine erste Entscheidung genügen keine Einzelwerte ohne Kontext. Führen Sie die Messung über eine für das Projekt repräsentative Arbeitsperiode und markieren Sie ungewöhnliche Ereignisse, etwa einen großen Release oder einen kurzfristig wiederholten Workflow. Ziehen Sie solche Ausreißer nicht stillschweigend in den Normalbetrieb hinein. Prüfen Sie sie separat: Sind sie erwartbarer Bestandteil des Release-Prozesses, müssen sie bei der Kapazitätsplanung berücksichtigt werden; waren sie einmalig, sollten sie die dauerhafte Auslegung nicht allein bestimmen.

Kleine Teams: Wartezeit und zeitgleiche Builds zusammen betrachten

Die Teamgröße ist kein direkter Umrechnungsfaktor für die Anzahl der Macs. Mehrere Personen können ihre Arbeit zeitlich versetzt einreichen, während wenige Personen gleichzeitig Commits, Pull Requests und Release-Prüfungen auslösen können. Für kleine Teams ist daher die Überlappung der Workflows in den tatsächlich wichtigen Zeitfenstern relevanter als die Zahl der Teammitglieder.

Legen Sie zunächst fest, welche Wartezeit für welche Art von Job akzeptabel ist. Ein schneller Prüflauf, der Rückmeldung vor dem Merge geben soll, kann eine andere Priorität haben als ein vollständiger Build, der vor einer Veröffentlichung laufen muss. Die Zielwartezeit ist eine Entscheidung des Teams, keine von GitHub garantierte Eigenschaft. Erfassen Sie anschließend, wie viele passende macOS-Jobs in den entsprechenden Zeitfenstern gleichzeitig auf Ausführung warten oder bereits einen Runner belegen.

Wie lässt sich die Runner-Anzahl aus der GitHub-Actions-Wartezeit ableiten?

Verwenden Sie die Wartezeit als Signal, nicht als alleinige Formel. Eine lange Verzögerung spricht für fehlende verfügbare Kapazität, wenn ein Job einem Runner zugewiesen werden könnte, aber alle geeigneten Runner mit anderen Jobs belegt sind. Wartet der Workflow dagegen auf eine Abhängigkeit, einen manuellen Freigabeschritt oder eine vorgelagerte Aufgabe, behebt ein zusätzlicher Mac die Ursache nicht.

Ordnen Sie deshalb die Zeit eines Jobs in unterscheidbare Abschnitte: Zeit bis zur Auslösung, Zeit in der Warteschlange, Zeit vom Start bis zum Ende und gegebenenfalls Zeit in manuellen oder abhängigen Schritten. Die GitHub-Dokumentation zur Überwachung und Fehlerbehebung bei selbst verwalteten Runnern bietet Anhaltspunkte, um Runner-Zustände und typische Ausführungsprobleme zu untersuchen.

Für die Kapazitätsabschätzung kann das Team eine nachvollziehbare Näherung bilden:

benötigte gleichzeitige Slots ≈ gleichzeitig anfallende macOS-Jobs × durchschnittliche belegte Zeit im betrachteten Zeitraum, angepasst an das gewünschte Wartezeit-Ziel

Das ist ein Planungsmodell, keine Zusage für ein bestimmtes Ergebnis. Für die Rechnung muss „gleichzeitig anfallend“ aus den eigenen Workflow-Daten hervorgehen; „belegte Zeit“ meint die tatsächliche Zeit, in der ein Runner einen Job ausführt. Die Zielwartezeit dient anschließend dazu, zu prüfen, ob die vorhandene Kapazität die beobachteten Spitzen ausreichend abfängt. Verwenden Sie keine aus anderen Teams übernommenen Laufzeiten: Build-Schritte, Abhängigkeiten, Caches und Runner-Zustand unterscheiden sich.

Eine kleine Vergleichsmatrix hilft, den Bedarf nach Arbeitsweise statt nach Teamgröße zu ordnen:

Teamprofil	Typisches Messproblem	Kapazitätsentscheidung
Einzelprojekt	Einzelne Spitzen werden mit dauerhaftem Engpass verwechselt	Erst bei wiederholter Warteschlange außerhalb einzelner Sonderereignisse erweitern
Kleines Team	Mehrere Beiträge treffen im gleichen Arbeitsfenster ein	Zeitgleiche Jobs und akzeptable Wartezeiten zusammen auswerten
Mehrere Repositories	Unterschiedliche Jobtypen konkurrieren um dieselben Runner	Gemeinsame Kapazität und gezielte Projektzuweisung gegeneinander abwägen
Plattformbetrieb	Aggregierte Werte verdecken einzelne blockierte Workflows	Daten nach Runner-Gruppe, Label, Repository und Jobtyp aufschlüsseln

Die Tabelle ersetzt keine Messung. Sie verhindert aber einen verbreiteten Kurzschluss: Aus einer größeren Zahl von Entwicklern folgt nicht automatisch ein entsprechend größerer Runner-Pool. Ausschlaggebend sind die tatsächlich überlappenden Ausführungen und die Priorität der Jobs, die warten.

Teams mit mehreren Repositories: gemeinsame Kapazität gezielt routen

In einer Organisation mit mehreren iOS-Repositories können sich die Arbeitslasten deutlich unterscheiden. Ein schneller Testjob belegt einen Runner möglicherweise kürzer als ein vollständiger Build oder ein Release-Workflow; wie stark, muss die eigene CI messen. Werden alle Aufgaben in einen gemeinsamen Pool geleitet, lassen sich Kapazitätsspitzen grundsätzlich zusammen betrachten. Gleichzeitig kann ein Projekt mit vielen Builds die für zeitkritische Abläufe anderer Projekte benötigte Kapazität beanspruchen.

Die Alternative ist eine gezieltere Zuweisung nach Repository, Workflow oder Jobart. Das schafft mehr Kontrolle, erhöht aber den Aufwand für Pflege und Kapazitätsverteilung: Ein isolierter Pool kann ausgelastet sein, während ein anderer freie Runner hat. Eine gemeinsame Gruppe kann die Auslastung bündeln, benötigt jedoch transparente Regeln dafür, welche Repositories und Workflows darauf zugreifen dürfen. GitHub beschreibt Runner-Gruppen zur Organisation und Steuerung des Runner-Zugriffs; deren konkrete Verwendung sollte mit der jeweiligen Organisationsstruktur und den Sicherheitsanforderungen abgeglichen werden.

Wie verteilen Sie macOS-CI-Kapazität auf mehrere iOS-Repositories?

Starten Sie mit einer Übersicht der Last, statt früh feste Kontingente zu verteilen. Ordnen Sie Jobs nach Repository und Zweck: Prüfläufe, vollständige Builds und Release-Aufgaben gehören in getrennte Kategorien, sofern ihr Laufzeit- oder Prioritätsprofil erkennbar abweicht. Markieren Sie außerdem, welche Aufgaben auf eine zeitnahe Rückmeldung angewiesen sind und welche sich zeitlich verschieben lassen.

Prüfen Sie dann, ob eine gemeinsame Runner-Gruppe alle erforderlichen Jobs sicher und zuverlässig ausführen kann. Runner-Auswahl und Label-Regeln müssen mit der Workflow-Konfiguration übereinstimmen; die Referenz zu selbst verwalteten Runnern erläutert die Auswahl und Eigenschaften dieser Runner. Wenn Projekte unterschiedliche Zugriffsrechte, Abhängigkeiten oder Betriebsanforderungen haben, kann eine getrennte Zuordnung sinnvoller sein als ein einziger gemeinsamer Pool. Die Entscheidung sollte aus den beobachteten Konflikten folgen, nicht aus einer pauschalen Regel „ein Repository, ein Mac“.

Erfahrungshinweis: Wenn ein Job nicht startet, obwohl ein Runner scheinbar frei ist, prüfen Sie zuerst, ob dessen Labels und Gruppenzugriff zur Workflow-Anforderung passen. Eine Erweiterung des Pools hilft nicht, wenn der Workflow die verfügbaren Runner nicht auswählen kann.

GitHub-Actions-Parallelität ist zudem nicht automatisch gleichbedeutend mit Runner-Kapazität. Die Dokumentation zu Concurrency-Gruppen beschreibt, wie gleichzeitige Läufe über eine Gruppe gesteuert werden können; für eine Gruppe kann dabei jeweils ein Lauf aktiv und ein weiterer ausstehend sein, während ein neuerer ausstehender Lauf einen bereits wartenden ersetzen kann. Wenn eine solche Konfiguration Builds zusammenfasst oder ältere Läufe verwirft, sehen Sie unter Umständen weniger gleichzeitig ausgeführte Jobs, ohne dass ein zusätzlicher Mac die eigentliche Ursache behebt. Prüfen Sie daher auch die Workflow-Syntax für Concurrency und Job-Auswahl, bevor Sie gemessene Auslastung als tatsächlichen Bedarf interpretieren.

Messwerte in eine überprüfbare Kapazitätsschätzung übersetzen

Die Schätzung sollte auf Daten beruhen, die zu den eigenen Workflows gehören und von anderen Personen nachvollzogen werden können. Führen Sie Zeitstempel, Runner-Zuordnung und Jobstatus in einer Auswertung zusammen. Notieren Sie zugleich Änderungen an Cache-Verhalten, Abhängigkeiten oder Build-Schritten: Eine veränderte belegte Zeit kann die errechnete Kapazität beeinflussen, ohne dass sich die Zahl der ausgelösten Workflows geändert hat.

Messgröße	Erfassung	Verwendung in der Entscheidung
Zeit bis zum Jobstart	Auslösung und tatsächlicher Beginn gegenüberstellen	Zeigt, ob die Wartephase vor dem Runner problematisch ist
Runner-Belegungszeit	Start und Abschluss des Jobs erfassen	Zeigt, wie lange ein Slot für diesen Job gebunden ist
Gleichzeitige Jobs	Überlappende Ausführungen je Zeitfenster auswerten	Liefert die beobachtete Last statt einer Schätzung aus Teamgröße
Jobtyp und Repository	Daten nach Zweck und Herkunft gruppieren	Macht Konkurrenz zwischen Tests, Builds und Releases sichtbar
Status und Abbruch	Fehlgeschlagene, abgebrochene und wiederholte Jobs markieren	Verhindert, dass Sonderfälle als normaler Kapazitätsbedarf gelten
Cache- und Workflow-Änderungen	Änderungen mit dem Auswertungszeitraum dokumentieren	Erklärt, warum Laufzeit und Runner-Belegung schwanken können

Sollen Sie nach durchschnittlicher Auslastung oder nach Spitzen parallelisieren?

Der Durchschnitt allein bildet kurze, aber wichtige Spitzen nicht ab. Umgekehrt würde eine Auslegung auf jede beobachtete Höchstlast dauerhaft Runner bereitstellen, die außerhalb dieses Fensters möglicherweise kaum genutzt werden. Entscheiden Sie deshalb, welche Spitzen regelmäßig auftreten und welche Jobs in ihnen Vorrang haben. Eine Kapazitätsschätzung als Bereich ist meist ehrlicher als eine scheinbar genaue Einzelzahl: Der untere Bereich beschreibt, was bei gewöhnlicher Last ausreicht; der obere Bereich berücksichtigt wiederkehrende, für das Team relevante Spitzen.

Trennen Sie dabei drei Fragen: Wie viele Jobs kommen im Zielzeitraum gleichzeitig an? Wie lange bleibt ein Runner mit einem solchen Job belegt? Welche Wartezeit darf der Job haben, bevor ein Teamprozess darunter leidet? Die Antworten sollten aus den eigenen Messdaten und der festgelegten Priorität hervorgehen. Die Formel liefert keine universelle Mac-Zahl und ersetzt auch keine Entscheidung darüber, welche Jobs zeitkritisch sind.

Berücksichtigen Sie außerdem, dass eine Stichprobe durch Sonderereignisse verzerrt sein kann. Ein Release, eine ungewöhnliche Serie manueller Ausführungen oder ein Wechsel des Caches beeinflusst die beobachtete Auslastung. Halten Sie den Zeitraum und solche Ausnahmen fest und vergleichen Sie nach Möglichkeit gleichartige Arbeitsphasen. Das Ziel ist keine wissenschaftliche Vorhersage jedes künftigen Commits, sondern eine transparente Entscheidung, die bei veränderten Daten aktualisiert werden kann.

Runner-Bedarf in kontrollierten Schritten verifizieren

Ein Kapazitätsmodell wird erst dann belastbar, wenn ein begrenzter Erweiterungsschritt im realen Betrieb geprüft wurde. Gehen Sie dabei in einer Reihenfolge vor, die Ursachen sichtbar lässt:

1. Ausgangslage festhalten. Dokumentieren Sie Wartezeiten, belegte Runner-Zeit, gleichzeitige Jobs und Jobfehler für die betroffenen Repositories. Halten Sie auch fest, welche Workflows bei Engpässen besonders wichtig sind.
2. Workflow-Regeln prüfen. Kontrollieren Sie Runner-Labels, Gruppenberechtigungen, Concurrency-Einstellungen, Abhängigkeiten und manuelle Freigaben. Vergleichen Sie die Anforderungen in den Workflows mit den tatsächlich verfügbaren Runnern.
3. Messdaten segmentieren. Trennen Sie Prüf-, Build- und Release-Aufgaben und markieren Sie Ausreißer. Dadurch wird sichtbar, ob ein bestimmter Jobtyp oder ein einzelnes Repository die Warteschlange prägt.
4. Eine begrenzte Kapazitätsänderung wählen. Leiten Sie den nächsten Schritt aus wiederkehrenden Spitzen und der gewünschten Wartezeit ab. Vermeiden Sie, den höchsten beobachteten Ausschlag ungeprüft als dauerhaften Bedarf zu übernehmen.
5. Nach der Änderung dieselben Kennzahlen vergleichen. Nutzen Sie eine vergleichbare Arbeitsperiode und prüfen Sie neben der Wartezeit auch Runner-Auslastung, Jobstatus und Verteilung zwischen den Workflows.
6. Bei ausbleibender Verbesserung die Ursache neu bestimmen. Wenn die Warteschlange nicht kürzer wird, prüfen Sie Routing, Abhängigkeiten und serielle Schritte, bevor Sie weitere Macs hinzufügen.
7. Die Entscheidung dokumentieren. Notieren Sie, welche Daten die Erweiterung ausgelöst haben, welche Workflows davon profitieren sollten und wann eine erneute Auswertung sinnvoll ist.

Woran erkennen Sie Runner-Mangel statt problematischer Build-Schritte?

Ein Runner-Mangel ist plausibel, wenn passende Runner mit Jobs belegt sind und neue Jobs nachweislich auf freie Kapazität warten. Ein Problem im Workflow ist wahrscheinlicher, wenn Runner verfügbar bleiben, Jobs aber wegen nicht passender Labels, fehlender Berechtigung, Abhängigkeiten oder einer Concurrency-Regel nicht starten. Ebenfalls getrennt zu betrachten sind Jobs, die früh starten, aber lange laufen: In diesem Fall kann die Build-Ausführung selbst – einschließlich unnötiger serieller Schritte oder wiederholter Arbeit – die belegte Zeit erhöhen.

Kontrollieren Sie deshalb nicht nur die durchschnittliche Ausführungsdauer. Stellen Sie für einzelne Jobs den Zeitpunkt der Auslösung, den Beginn, den Abschluss und den Zustand des zugewiesenen Runners gegenüber. Die offizielle Anleitung zur Fehlerbehebung bei selbst verwalteten Runnern ist dafür eine technische Referenz; Ihre Kapazitätsentscheidung sollte zusätzlich auf den eigenen Workflow-Daten beruhen. Wenn zusätzliche Kapazität die Wartezeit nicht verändert, ist das ein Anlass, die Diagnose zu überprüfen – kein Beleg dafür, dass noch mehr Macs benötigt werden.

Prüfliste vor einer Kapazitätserweiterung

• [ ] Die Auswertung umfasst eine für die betroffenen Workflows repräsentative Arbeitsperiode.
• [ ] Wartezeit bis zum Jobstart und tatsächliche Runner-Belegungszeit sind getrennt erfasst.
• [ ] Gleichzeitige Jobs sind nach Repository und Jobtyp ausgewertet.
• [ ] Einzelne Release-Spitzen, manuelle Wiederholungen und andere Ausnahmen sind markiert.
• [ ] Runner-Labels, Gruppenzugriff und Workflow-Anforderungen passen zusammen.
• [ ] Concurrency-Regeln und Abhängigkeiten sind geprüft, bevor zusätzliche Kapazität eingeplant wird.
• [ ] Das Team hat festgelegt, welche Wartezeiten für zeitkritische Jobs akzeptabel sind.
• [ ] Ein begrenzter Erweiterungsschritt lässt sich anhand derselben Kennzahlen vor und nach der Änderung beurteilen.
• [ ] Bei unveränderter Warteschlange wird die Workflow- oder Routing-Ursache erneut untersucht.

Eine realistische Planung trennt außerdem Mac-Build-Kapazität von anderen Kosten. API-Aufrufe eines Modells, externe Dienste und CI-Ausführung sind unterschiedliche Kostenarten; sie sollten nicht in einer gemeinsamen „Build-Kapazität“ verrechnet werden. Für Runner zählen die benötigte Verfügbarkeit, die belegte Ausführungszeit, die Betriebsverantwortung und die Anforderungen an den Zugriff auf Quellcode und Artefakte. Bewerten Sie sensible Daten nach Ihren Datenschutzvorgaben und prüfen Sie, ob Zugriffsrechte, Protokolle und Datenaufbewahrung zur eigenen Organisation passen.

Vom Kapazitätsmodell zur passenden Mac-Betriebsform

Wenn ein Team die Schätzung zuerst auf einer eigenen Hardwarebasis verifizieren kann und diese dauerhaft für den CI-Betrieb benötigt, kann ein eigener Mac die passendere Wahl sein. Das ist besonders dann plausibel, wenn konstante Verfügbarkeit, langfristige Auslastung oder physische Anschlüsse entscheidend sind. Der Betrieb bringt allerdings eigene Aufgaben mit sich: Hardware muss bereitgestellt und gewartet, der Runner sicher in die Organisation eingebunden und die tatsächliche Auslastung überwacht werden.

Eine gemietete Remote-Mac-Umgebung kann sinnvoll sein, wenn zunächst eine zeitlich begrenzte Kapazität für Tests, einen Release-Zyklus oder eine kontrollierte Erweiterungsprobe benötigt wird. Sie beseitigt weder fehlerhafte Workflow-Regeln noch ungeeignete Runner-Labels; ihre Eignung hängt außerdem davon ab, ob verfügbare Konfiguration, Bereitstellung und Mietzeitraum zum gemessenen Bedarf passen. Prüfen Sie diese Angaben anhand der tatsächlich veröffentlichten Informationen, statt aus einer Kapazitätsformel eine nicht belegte Zusage abzuleiten.

Wer die eigene Schätzung in eine konkrete Remote-Mac-Auswahl übersetzen möchte, kann die auf der Zutcloud-Seite zum Mieten eines Mac mini in Hongkong veröffentlichten Angaben mit den gemessenen Anforderungen vergleichen. Für Fragen zur Verfügbarkeit und zum Ablauf bietet das Zutcloud-Hilfezentrum einen passenden nächsten Anlaufpunkt. Entscheidend bleibt, zuerst die eigenen Actions-Daten auszuwerten und erst danach zu entscheiden, ob ein zusätzlicher Runner dauerhaft, projektbezogen oder nur für einen begrenzten Test benötigt wird.

Weiterlesen

• Team-iOS-CI/CD: Xcode Cloud und Remote-Mac-Build-Farm vergleichen
• iOS-Builds auf M4-Cloud-Knoten beschleunigen und parallelisieren
• M6 Mac mini für Xcode und Entwickler-Workloads bewerten