Apple bestätigt in den Xcode-27-Release Notes, dass Xcode 27 nur auf Apple-Silicon-Macs installiert und ausgeführt werden kann. Das ist keine reine Upgrade-Frage. Ihre bisherige Intel-Kapazität fällt als Zielplattform aus. Entscheidend ist nun, welche Aufgaben gleichzeitig eintreffen, wie lange sie Ressourcen belegen und welche Jobs nicht gemeinsam mit anderen Jobs laufen dürfen.

Ein typischer Kapazitätsfehler sieht so aus: Die Zahl der Pull Requests steigt, die Pipeline meldet mehr Jobs, aber die CPU-Auslastung der Mac-Knoten bleibt wechselhaft. Die eigentliche Blockade liegt dann vielleicht in einer seriellen Signierungsphase, einem begrenzten Runner-Pool, fehlenden privaten Netzwerkfreigaben oder wiederholten Jobs nach Testfehlern. Mehr Rechenleistung pro Knoten senkt in diesem Fall die Wartezeit nicht zuverlässig.

Trennen Sie deshalb mindestens diese Messgrößen:

• Ankunftsrate: Wie viele PR-Builds, Testläufe, Archive und Veröffentlichungsjobs treffen je Zeitfenster ein?
• Laufzeit: Wie lange belegt ein Job den Knoten tatsächlich, einschließlich Checkout, Cache-Wiederherstellung und Aufräumen?
• Spitzenparallelität: Wie viele Aufgaben laufen während des kritischsten Fensters gleichzeitig?
• Wartezeit: Wie lange darf ein Job in der Queue bleiben, bevor der Entwicklungs- oder Veröffentlichungsprozess beeinträchtigt wird?
• Fehlerwiederholung: Wie viele zusätzliche Ausführungen entstehen durch flaky Tests, Timeouts oder fehlende Artefakte?
• Ressourcenprofil: Benötigt die Aufgabe vor allem CPU, Arbeitsspeicher, Speicher-I/O, Simulatoren oder Netzwerkzugriff?
• Sicherheitsgrenze: Darf der Job auf einen gemeinsam genutzten Knoten oder benötigt er eine isolierte Signierungsumgebung?

Für die Kapazitätsrechnung verwenden Sie Variablen statt erfundener Durchschnittswerte:

Grundparallelität =
Spitzenlast je Aufgabentyp × durchschnittliche belegte Zeit
÷ betrachtetes Zeitfenster

Die Spitzenkapazität ergibt sich aus der maximal beobachteten Gleichzeitigkeit. Die Sicherheitsreserve darf nicht pauschal gesetzt werden. Sie muss aus Ihrer zulässigen Wartezeit, den Wiederholungen und der Ausfallstrategie abgeleitet werden. Wenn Sie diese Faktoren nicht dokumentieren können, ist die Kapazitätszahl noch keine Einkaufsgrundlage.

Hinweis: Die Entwicklerzahl ist nur ein indirekter Einflussfaktor. Zehn Entwickler mit seltenen Builds können weniger CI-Kapazität benötigen als ein kleineres Team mit vielen Simulator-Tests und mehreren täglichen Release-Fenstern.

PR-Builds, Tests und Archive

Ein PR-Build erzeugt typischerweise eine andere Last als ein Clean Build oder ein Simulator-Test. Für jedes Profil sollte Ihre CI mindestens folgende Felder speichern:

1. Startzeit des Wartens.
2. Zeitpunkt der Runner-Zuweisung.
3. Beginn des eigentlichen Builds.
4. Ende des Tests oder Archivs.
5. Ergebnis und Fehlerklasse.
6. Cache-Hit oder Cache-Miss.
7. Signierungs- und Upload-Phasen.
8. Wiederholung desselben Jobs.

Damit lässt sich erkennen, ob Sie ein Kapazitätsproblem oder ein Pipelineproblem lösen müssen. Steigt die Queue-Zeit, während die Ausführungszeit stabil bleibt, spricht das für zusätzliche Knoten. Steigt dagegen die Ausführungszeit nach Cache-Verlusten, lohnt sich zuerst eine Analyse von Cache-Schlüsseln, DerivedData, Dependency-Auflösung und Workspace-Bereinigung.

Bei Archive- und Release-Jobs kommt eine weitere Grenze hinzu: Ein erfolgreicher Build ist nicht gleichbedeutend mit einer verfügbaren Veröffentlichungskapazität. Zertifikate, Provisioning-Profile, Schlüsselbundzugriff, App-Store-Verbindung und Freigabeprozesse können den Durchsatz begrenzen. Diese Jobs sollten daher nicht einfach als weitere PR-Builds gezählt werden.

Messung der Spitzen

Erfassen Sie nicht nur Tagesmittelwerte. Ein Durchschnitt kann eine kurze, aber geschäftskritische Release-Spitze vollständig verdecken. Teilen Sie die Daten mindestens in Grundlast, normale Arbeitslast und das größte beobachtete Veröffentlichungsfenster auf. Die Zeitfenster müssen zu Ihrem Geschäft passen: Ein SaaS-Team mit globalen Entwicklungsstandorten hat andere Spitzen als ein Unternehmen mit zentralem Release-Termin.

Für die Planung von Apple-Silicon-CI-Knoten brauchen Sie außerdem eine Baseline je Aufgabentyp. Verwenden Sie dasselbe Commit, dieselbe Dependency-Auflösung und dieselben Testdaten. Vergleichen Sie anschließend:

• Clean Build gegen Incremental Build.
• Einzeltest gegen parallele Simulator-Tests.
• Archiv ohne Signierung gegen signiertes Archiv.
• Signierung im gemeinsamen Pool gegen Signierung im isolierten Pool.
• Cache-Hit gegen absichtlich ungültigen Cache.
• Fester Knoten gegen zusätzlich bereitgestellten Remote Mac.

Die Ergebnisse sind keine allgemeinen Leistungsversprechen. Sie gelten nur für Ihr Projekt, Ihre Xcode-Version, Ihre Test-Suite und Ihre Pipeline-Konfiguration.

Eine belastbare Architektur trennt Kapazität nach Risiko. Drei Pools sind dafür ein nützliches Entscheidungsmodell:

• Gemeinsamer Build-Pool: PR-Builds, normale Unit-Tests und wiederholbare Aufgaben.
• Signierungs-Pool: Archive, Codesignierung, notariserte Artefakte und kontrollierte Veröffentlichungen.
• Elastischer Spitzen-Pool: Migrationsläufe, Release-Spitzen, Backfills und zeitlich begrenzte Projekte.

Bei GitHub Actions kann das Routing über passende Runner-Labels erfolgen. Die offizielle Dokumentation führt das Label xcode-27 und beschreibt die Auswahl geeigneter Runner; die genaue Verfügbarkeit, das Image-Verhalten und Organisationslimits müssen Sie am Bereitstellungstag prüfen. Für größere Runner gelten eigene Eigenschaften und Abrechnungsregeln, die in der Dokumentation zu GitHub Larger Runners beschrieben sind.

Für selbstverwaltete Mac-Buildknoten gelten andere Grenzen. Sie müssen Betriebssystem, Xcode, Runner-Software, Zertifikate, Benutzerkonten, Updates, Neustarts, Monitoring und Ersatzkapazität selbst betreiben. Ein Remote Mac verschiebt diese Aufgaben teilweise zum Betreiber, beseitigt aber nicht Ihre Verantwortung für Pipeline-Routing, Geheimnisse und Datenklassifizierung.

Signierungsgrenzen

Ein Signierungs-Pool sollte mindestens diese Grenzen besitzen:

• eigener Zugriff auf Schlüsselbund und Provisioning-Profile;
• keine Übernahme beliebiger Arbeitsbereiche aus dem PR-Pool;
• definierte Bereinigung nach jedem Auftrag;
• protokollierter Zugriff auf Zertifikate;
• blockierbares Release-Routing;
• geprüfter Rückfall auf einen zweiten Knoten oder einen manuellen Prozess.

Die GitHub-Dokumentation zu Concurrency zeigt, wie konkurrierende Workflows kontrolliert werden können. Das ersetzt keine Signierungsisolation, verhindert aber, dass sich bestimmte Release-Abläufe unkontrolliert überholen.

Cache, Netzwerk und Startzeit

Elastische Kapazität ist nur dann nutzbar, wenn ein neuer Knoten rechtzeitig arbeitsfähig wird. Prüfen Sie deshalb vier Zeitabschnitte getrennt:

1. Bereitstellung des Mac.
2. Installation oder Aktivierung der benötigten Umgebung.
3. Zugriff auf Repository, Artefakte, Secrets und private Dienste.
4. Erster reproduzierbarer Build mit verwertbarem Cache.

Ein Knoten, der online erscheint, aber noch keine private Registry erreicht oder kein gültiges Zertifikat laden kann, erhöht Ihre echte Kapazität nicht. Auch ein Cache-Miss kann einen elastischen Knoten für die erste Aufgabe deutlich weniger wirksam machen. Planen Sie daher bei der Auswertung nicht nur „Runner verfügbar“, sondern „Aufgabe erfolgreich innerhalb der Zielwartezeit“.

Wenn Sie einen Remote Mac als temporäre Ergänzung prüfen, können Sie die verfügbaren KVMNODE-Mac-Standorte als Ausgangspunkt für einen PoC vergleichen. Die konkrete Kapazität muss jedoch mit Ihrer Pipeline gemessen werden. Eine Standortliste ist kein Nachweis für Durchsatz, private Netzwerkanbindung oder Signierungsfähigkeit.

Die Kostenrechnung sollte auf Kosten je erfolgreicher Aufgabe basieren. Die Zahl der Geräte allein sagt wenig aus. Für jede Option erfassen Sie fixe Ausgaben, variable Nutzung, Leerkapazität, Betriebsaufwand, Ausfallrisiko und Rückfallkosten.

Für GitHub Actions müssen Sie die veröffentlichten Abrechnungsregeln und Runner-Kategorien verwenden. Die Actions-Runner-Preisdokumentation und die Übersicht zu Abrechnung und Nutzung sind maßgeblich. Verwenden Sie keine alte interne Preisliste. Wenn sich Runner-Größe, Abrechnung oder Organisationslimit ändern, ändert sich auch Ihre TCO-Rechnung.

Ein einfaches Modell lautet:

Kosten je erfolgreicher Aufgabe =
(fixe Poolkosten + variable Nutzung + Betrieb + Ausfallrisiko)
÷ erfolgreiche Aufgaben

Bei einem Kauf müssen Sie zusätzlich Abschreibung, Ersatzgerät, Strom, Stellplatz, Wartung, Sicherheitskontrollen und die Zeit des Plattformteams ansetzen. Bei einer Miete oder einem verwalteten Runner zählen dagegen Nutzungsdauer, Mindestlaufzeit, Bereitstellung, Datenübertragung und mögliche Leerlaufzeiten. Rechnen Sie für Grundlast und Spitzenlast getrennt.

Beschaffungsentscheidung nach Lastprofil

• Wenn die Grundlast dauerhaft hoch und zeitlich vorhersehbar ist, wählen Sie einen festen Mac-Pool. Ergänzen Sie nur die nachgewiesene Spitzenlücke elastisch.
• Wenn die Last vor allem bei Releases, Migrationen oder Testkampagnen entsteht, wählen Sie einen kleineren festen Pool mit Remote-Mac-Erweiterung.
• Wenn Signierung und Veröffentlichung regulatorisch oder organisatorisch isoliert werden müssen, reservieren Sie einen separaten Signierungs-Pool. Teilen Sie nicht einfach den schnellsten Knoten.
• Wenn Queue-Zeit nur nach Cache-Verlusten oder fehlerhaften Wiederholungen steigt, optimieren Sie zuerst Pipeline und Cache.
• Wenn die Plattform private Netzwerkdienste benötigt, testen Sie den vollständigen Datenpfad vor der Bestellung. Fällt dieser Test durch, ist zusätzliche Rechenkapazität keine Lösung.
• Wenn die elastische Bereitstellung nicht innerhalb Ihres Veröffentlichungsfensters einsatzbereit wird, halten Sie feste Reservekapazität vor oder verschieben Sie die Spitzenlast in ein planbares Zeitfenster.

Die passende Antwort auf „Wie viele Mac-Buildmaschinen braucht unser Unternehmen?“ ist daher eine Messreihe mit mehreren Zahlen: Grundparallelität, Spitzenparallelität, Laufzeit je Aufgabentyp, zulässige Queue-Zeit, Signierungsbedarf und Wiederherstellungszeit.

Nehmen Sie neue Mac-Buildknoten nicht ab, weil sie erreichbar sind. Führen Sie eine reale Pipeline mit repräsentativen PR-Builds, Simulator-Tests, Archiven und Signierungsjobs aus. Prüfen Sie außerdem einen absichtlich fehlgeschlagenen Job, einen Neustart und die erneute Bereitstellung einer sauberen Umgebung.

Dokumentieren Sie für jeden Test:

• Commit und Dependency-Stand;
• Xcode- und macOS-Version;
• Runner-Route und Pool;
• Aufgabentyp und Parallelität;
• Queue-Zeit und Laufzeit;
• Cache-Zustand;
• Signierungsstatus;
• Netzwerkzugriffe;
• Fehler, Wiederholung und Rückfall;
• Zeitpunkt und Verantwortlicher der Messung.

Ihre Abnahme sollte eine von vier Entscheidungen ergeben:

1. Freigabe: Queue, Erfolgsrate, Signierung und Wiederherstellung erfüllen die festgelegten Bedingungen.
2. Befristete Freigabe: Der Pool darf für klar begrenzte Aufgaben starten, offene Risiken haben aber einen Termin und Verantwortlichen.
3. Elastische Ergänzung: Die Grundlast ist tragfähig, doch Spitzen erfordern zusätzliche Remote-Mac-Kapazität.
4. Beschaffung zurückstellen: Daten fehlen, Netzwerk- oder Signierungsgrenzen sind ungeklärt oder die gemessene Leistung erfüllt die Zielwartezeit nicht.

Prüfen Sie die Kapazität erneut, wenn sich Xcode 27, macOS, Runner-Images, GitHub-Limits, Abrechnung, Testumfang oder Ihr Releaseprozess ändern. Die GitHub-Limits-Dokumentation ist dabei wichtiger als eine alte Kapazitätsfolie, weil Organisations- und Plattformgrenzen die theoretische Knotenzahl begrenzen können.

Wenn Sie neben einem PoC auch einen physischen Vergleich benötigen, können Sie die verfügbaren Mac-mini-Bereitstellungsoptionen von KVMNODE gegen den festen Pool in Ihrer TCO-Tabelle stellen. Prüfen Sie dabei nicht nur den Miet- oder Kaufbetrag, sondern auch Lieferzeit, Administration, Austausch, Datenlöschung und die Zeit bis zum ersten erfolgreichen Build.

Wie viele Mac-Buildmaschinen sind für Xcode 27 erforderlich?

Eine feste Anzahl folgt nicht aus der Teamgröße. Entscheidend sind Spitzenparallelität, Laufzeit je Aufgabenklasse, Wiederholungen und die zulässige Wartezeit. Berechnen Sie den stabilen Bedarf aus realen Pipeline-Daten. Für schwankende Release-Spitzen ist ein fester Basispool mit zusätzlicher elastischer Kapazität meist sinnvoller als ein dauerhaft überdimensionierter Einzelknoten.

Wie berechnet man die parallele iOS-CI-Kapazität?

Messen Sie Ankunftsrate, belegte Laufzeit und Gleichzeitigkeit getrennt für PR-Builds, Simulator-Tests, Archive und Releases. Dividieren Sie die Spitzenarbeit durch die verifizierte Leistung eines Knotens. Ergänzen Sie keine pauschale Reserve, sondern begründen Sie sie mit Queue-Toleranz, Wiederholungen, Wartung und Ausfallfällen.

Wie erweitert man einen Mac-Packaging-Server bei Spitzenlast?

Definieren Sie zuerst, welche Jobs priorisiert werden. Erweitern Sie den gemeinsamen Build-Pool für PR-Spitzen, den Signierungs-Pool nur kontrolliert und den elastischen Pool für zeitlich begrenzte Last. Messen Sie die Zeit von der Bereitstellung bis zum ersten erfolgreichen Build. Ohne Netzwerk-, Geheimnis- und Cache-Test zählt ein online angezeigter Server nicht als nutzbare Kapazität.

Wie viele Apple-Silicon-CI-Knoten sollte man einplanen?

Planen Sie nach Aufgabentyp und Spitzenfenster. Ein Knoten für schnelle PR-Builds ist nicht automatisch eine ausreichende Basis für parallele Simulator-Tests oder signierte Archive. Erstellen Sie je Aufgabenklasse eine Baseline und entscheiden Sie anschließend zwischen festem Pool, isoliertem Signierungs-Pool und elastischer Ergänzung.

Können Remote Macs die Xcode-27-Warteschlange lösen?

Sie können die Kapazität erweitern, sofern Runner-Routing, Bereitstellung, private Netzwerkpfade, Cache und Signierungsgrenzen funktionieren. Für unregelmäßige Spitzen sind Remote Macs besonders interessant. Bei dauerhaft hoher Grundlast müssen Sie dagegen die laufenden Kosten, Wartezeit bis zur Bereitstellung und die notwendige feste Reserve mit einem eigenen Pool vergleichen.

Für die meisten Unternehmen ist die Entscheidung damit klarer: Eine einzelne, sehr große Maschine verschiebt Engpässe oft nur von CPU zu Signierung, Queue, Cache oder Netzwerk. Ein fester Pool deckt die planbare Grundlast ab, während ein elastischer Remote-Mac-Pool kurzfristige Spitzen und Migrationstests auffängt. Wenn Sie heute ausschließlich auf eigene Geräte setzen, binden Sie Kapital in Leerkapazität, tragen Austausch- und Betriebsrisiken selbst und reagieren langsamer auf neue Xcode- oder Release-Anforderungen. Wenn Sie ausschließlich auf gemeinsam genutzte externe Runner setzen, verlieren Sie unter Umständen Kontrolle über Umgebung, private Abhängigkeiten und Signierungsgrenzen. KVMNODE eignet sich deshalb vor allem als kontrollierbare Ergänzung für einen Kapazitäts-PoC oder zeitlich begrenzte Spitzen — vorausgesetzt, Sie prüfen die reale Pipeline vor der langfristigen Zusage.