Ein Build kann fast gleich lange dauern wie ein anderer und trotzdem an einer völlig anderen Stelle ausgebremst werden: einmal durch die Abhängigkeitsinstallation, einmal durch die Testmatrix. Wenn Ihr Xcode Cloud-Build zu langsam ist, migrieren Sie deshalb nicht nach einem einzelnen schlechten Lauf. Teilen Sie den Ablauf zuerst in vier Zeitabschnitte auf: Warteschlange, Umgebungsvorbereitung, eigentliche Kompilierung und Tests beziehungsweise Archivierung. Optimieren Sie anschließend Trigger, Cache und Testumfang. Erst wenn wiederholte Läufe an der temporären Umgebung, an dauerhaften Diensten oder fehlender Host-Kontrolle scheitern, verschieben Sie die betroffene Aufgabe auf einen Remote Mac. Xcode Cloud kann dabei weiterhin für Standard-Builds und Veröffentlichungsprüfungen bestehen bleiben.

Diese Woche sollten Sie einen normalen und einen auffälligen Build desselben Commits sichern, die Aktionsprotokolle nebeneinanderlegen und jede Phase separat markieren. Kaufen Sie nicht sofort zusätzliche Rechenzeit und verschieben Sie nicht die gesamte CI/CD-Pipeline, bevor diese Zuordnung abgeschlossen ist.

Diese Anleitung ist für drei Gruppen gedacht:

  • Apple-Plattform-Entwickler, deren Xcode-Cloud-Builds stetig länger werden, ohne dass die Engstelle bekannt ist.
  • CI-Ingenieure, die komplexe Abhängigkeiten, Caches oder dauerhafte Dienste verwalten müssen.
  • Entwicklungsleiter, die zwischen weiterer Nutzung, Remote-Mac-Migration und einem parallelen CI-Betrieb entscheiden.
01

Xcode Cloud-Build zu langsam: die vier Zeitabschnitte

Die Gesamtdauer eines Workflows ist zunächst nur ein Symptom. Öffnen Sie den betreffenden Build in Xcode oder App Store Connect und prüfen Sie Aktionsprotokoll, Build-Bericht und Nutzungsdaten. Apple beschreibt in der Dokumentation zu Xcode-Cloud-Nutzungsdaten, wie Sie die verbrauchte Nutzung nachvollziehen. Für die technische Diagnose brauchen Sie zusätzlich die zeitliche Abfolge der einzelnen Aktionen.

Markieren Sie für mindestens einen normalen und einen auffälligen Lauf:

  1. Warteschlange: Zeit bis zur tatsächlichen Ausführung.
  2. Umgebungsvorbereitung: Checkout, Tool-Installation, Abhängigkeiten und Skripte.
  3. Kompilierung und Archivierung: Xcode, Scheme, Targets und Signing-Schritte.
  4. Tests: Simulatoren, UI-Tests, Wiederholungen und Ergebnisexport.

Das ist keine von Apple vorgegebene universelle Grenzwerttabelle. Es ist ein Diagnosemodell, mit dem Sie nicht versehentlich die falsche Ursache optimieren. Apple veröffentlicht keinen allgemeinen Wert, ab dem ein Projekt offiziell als „zu langsam“ gilt. Eine Migration muss deshalb aus Ihren Logs, dem erfolgreichen Abschluss, dem Wartungsaufwand und den Nutzungskosten abgeleitet werden.

Wo finden Sie die tatsächliche Build-Zeit?

Verwenden Sie nicht nur die Zeitangabe aus dem CI-Übersichtsbildschirm. Öffnen Sie den konkreten Build, speichern Sie die Aktionsprotokolle und notieren Sie für jede Phase Start und Ende. Vergleichen Sie denselben Commit oder zumindest dieselbe Änderung, dasselbe Scheme und denselben Testumfang.

Ein sinnvoller Datensatz enthält:

  • Commit-ID oder einen anderen eindeutigen Build-Bezeichner.
  • Workflow-Name und Scheme.
  • Startbedingung, etwa Pull Request, Branch-Änderung oder manueller Start.
  • Zeit für Checkout, Abhängigkeiten, Build, Tests und Archivierung.
  • Ergebnis des Builds sowie sichtbare Warnungen und Wiederholungen.

Die Apple-Referenz für Xcode-Cloud-Workflows ist dabei die maßgebliche Grundlage für Workflow-Aktionen und Ausführungsbedingungen. Eine einzelne Gesamtdauer ohne diese Aufteilung reicht nicht für eine Migrationsentscheidung.

02

Erste Entscheidung vor der Migration

Die folgende Tabelle ist kein Preisvergleich, sondern ein Werkzeug für die technische Zuordnung. Sie hilft Ihnen, den nächsten Schritt anhand der Ursache zu wählen.

Befund im Build-Bericht Erstes Gegenmittel Wann ein Remote Mac sinnvoll wird Geeignete Betriebsform
Lange Warteschlange, eigentliche Ausführung unauffällig Trigger prüfen, parallele Ausführungen reduzieren, automatische Abbrüche aktivieren Wenn reproduzierbare Spitzen die Rückmeldung dauerhaft blockieren Xcode Cloud weiter nutzen, Trigger überarbeiten
Abhängigkeiten werden bei jedem Lauf neu vorbereitet Lock-Dateien, Berechtigungen, Post-Clone-Skripte und Cache prüfen Wenn Installationen dauerhaft umfangreich sind oder interne Dienste benötigen Einzelne Build-Aufgaben auf Remote Mac
Kompilierung bleibt trotz stabiler Vorbereitung langsam Scheme, Targets und Clean-Build-Verhalten prüfen Wenn Sie vollständige Host-Kontrolle oder eigene Werkzeuge benötigen Vergleichstest, danach gezielte Migration
Tests dominieren die Laufzeit Pull-Request-, Hauptbranch- und Nacht-Workflows trennen Wenn ein eigener Simulatorbestand oder gemeinsam genutzte Testdaten erforderlich ist Mischbetrieb mit separatem Testknoten
Netzwerk- oder Skriptfehler erzeugen lange Pausen Timeout-Schutz, Wiederholungen, Exit-Codes und Protokollierung ergänzen Wenn interne Netzwerke, dauerhafte Prozesse oder persistente Dateien zwingend sind Remote Mac oder selbstverwalteter CI-Knoten

Der wichtigste Unterschied: Ein Remote Mac löst nicht automatisch eine übergroße Testmatrix oder einen unnötigen Workflow-Trigger. Er gibt Ihnen mehr Kontrolle über den Host. Wenn die eigentliche Ursache eine falsche Ausführungspolitik ist, bleibt die Pipeline auch nach der Migration ineffizient.

03

Abhängigkeiten und Initialisierung

Warum werden Abhängigkeiten bei jedem Xcode-Cloud-Build erneut installiert?

Xcode Cloud arbeitet mit temporären Build-Umgebungen. Eine neue Ausführung darf daher nicht stillschweigend von einem dauerhaft veränderten Dateisystem ausgehen. Abhängigkeiten müssen über die Projektkonfiguration, Lock-Dateien, Repository-Berechtigungen und definierte Skripte verfügbar gemacht werden. Die Apple-Anleitung zur Bereitstellung von Abhängigkeiten in Xcode Cloud beschreibt diese Voraussetzungen.

Prüfen Sie zuerst das Post-Clone-Skript. Häufige Zeitverluste entstehen nicht durch Xcode selbst, sondern durch Schritte wie:

  • Installation von Werkzeugen, die im konkreten Workflow gar nicht gebraucht werden.
  • Wiederholtes Auflösen von Swift Packages ohne Prüfung der Sperrdateien.
  • Erneutes Herunterladen von CocoaPods- oder Carthage-Abhängigkeiten.
  • Authentifizierungsversuche gegen private Repositories, die bei jedem Lauf neu ausgeführt werden.
  • Aufbau von generierten Dateien, obwohl sie für den aktuellen Test gar nicht erforderlich sind.

Trennen Sie Vorbereitung und Build logisch. Ein Skript sollte klar ausweisen, ob es prüft, installiert, generiert oder nur validiert. Verwenden Sie feste Versionen, damit ein schneller Lauf nicht durch eine spätere Auflösung unbemerkt reproduzierbar wird.

Achtung: Ein Cache ist kein Ersatz für eine deterministische Umgebung. Wenn ein Build nur wegen alter Dateien erfolgreich ist, haben Sie Geschwindigkeit gegen schwer sichtbare Fehler eingetauscht.

Ein Remote Mac ist an dieser Stelle erst dann gerechtfertigt, wenn die Vorbereitung nachweisbar den wiederkehrenden Hauptanteil bildet und die Aufgabe von einem persistenten Dateisystem, einem internen Dienst oder speziellen Administratorrechten profitiert. Benötigt Ihr Workflow lediglich eine sauberere Dependency-Konfiguration, ist eine Migration unnötig.

04

Cache, Clean Build und reproduzierbare Ergebnisse

Ein Clean Build kann für Fehleranalyse und Release-Kontrolle sinnvoll sein. Wird er jedoch bei jeder kleinen Änderung erzwungen, vergleichen Sie nicht mehr die normale Entwicklungsrückmeldung mit einem Sonderfall. Beobachten Sie getrennt:

  • einen vollständigen Neuaufbau,
  • einen Lauf mit wiederverwendbaren Abhängigkeiten,
  • einen inkrementellen Lauf nach einer begrenzten Quellcodeänderung.

Derived Data, Paket-Cache und von Skripten erzeugte Dateien sind unterschiedliche Zustände. Wenn ein Workflow nur pauschal „Cache aktiviert“ meldet, wissen Sie noch nicht, welcher Zustand tatsächlich wiederverwendet wird. Prüfen Sie deshalb, welche Dateien ein Skript erzeugt, wann sie ungültig werden und ob ein neuer Commit sie korrekt ersetzt.

Die offizielle Workflow-Referenz von Apple sollte als Abgleich für die tatsächlich gewählten Workflow-Optionen dienen. Dokumentieren Sie für jeden Cache:

  • Inhalt und Zweck,
  • Erzeugungszeitpunkt,
  • Invalidierungsbedingung,
  • Verhalten nach einem fehlgeschlagenen Lauf,
  • Verhalten nach einer Änderung der Xcode- oder Dependency-Version.

Ein Remote Mac bietet Ihnen mehr Kontrolle über Derived Data, lokale Artefakte und installierte Werkzeuge. Das ist ein Vorteil, aber auch eine Betriebsaufgabe. Sie müssen Arbeitsverzeichnisse bereinigen, Zugriffsrechte prüfen und nach einem Neustart feststellen, ob der Build noch reproduzierbar ist. Ein langlebiger Host ist nicht automatisch sauberer als eine temporäre Umgebung.

05

Testmatrix und Workflow-Trigger

Wenn ein Commit mehrere Geräteklassen, UI-Tests, Archive und wiederholte Integrationsprüfungen startet, steigt die Ausführungsmenge durch die Struktur des Workflows. Ein langsamer Testabschnitt sollte nicht mit einem langsameren Compiler verwechselt werden.

Ordnen Sie die Aufgaben nach Zweck:

  • Pull Request: kurze Kompilierung und ausgewählte Tests für schnelles Feedback.
  • Hauptbranch: vollständigerer Regressionstest nach dem Merge.
  • Geplante Ausführung: breite Testmatrix, UI-Tests und zusätzliche Archive.
  • Veröffentlichung: reproduzierbarer Release- und Signierungsprozess.

Prüfen Sie außerdem, ob ältere Builds nach einer neuen Änderung weiterlaufen. Automatische Abbrüche können veraltete Ausführungen aus dem Weg nehmen, wenn nur der neueste Commit relevant ist. Die Dokumentation zu Xcode-Cloud-Workflow-Aktionen liefert den offiziellen Rahmen für solche Aktionen.

Weniger Geräte oder getrennte Workflows?

Reduzieren Sie die Geräteauswahl nicht blind. Wenn ein bestimmtes Gerät eine reale Fehlerklasse abdeckt, gehört es in den passenden Regressionstest. Verschieben Sie stattdessen die Frage nach dem Zeitpunkt:

  • Welche Tests müssen vor dem Review-Ergebnis abgeschlossen sein?
  • Welche Prüfungen reichen auf dem Hauptbranch?
  • Welche Fälle können in einen geplanten Lauf?
  • Welche UI-Tests brauchen eine eigene Umgebung oder Testdaten?

Eine getrennte Pipeline ist meist besser als das willkürliche Entfernen wichtiger Geräte. Sie verkürzt die Rückmeldung, ohne die Abdeckung dauerhaft zu verlieren. Ein eigener Remote-Mac-Testpool wird erst interessant, wenn Sie Simulatorzustände, Testdaten oder parallele Aufgaben kontrolliert verwalten müssen. Auch dann sollten Sie zuerst einen einzelnen Testtyp verschieben, nicht die gesamte Matrix.

06

Skripte, Netzwerk und Sicherheitsgrenzen

Temporäre Umgebungen machen Netzwerkabhängigkeiten sichtbar. Ein Post-Clone-Skript, das auf ein internes Repository, einen Artefaktspeicher oder eine externe API wartet, kann lange stillstehen, bevor Xcode überhaupt startet. Prüfen Sie deshalb jede externe Operation auf:

  • klaren Timeout,
  • begrenzte Wiederholungen,
  • sichtbare Protokollierung,
  • eindeutigen Exit-Code,
  • sichere Behandlung von Zugangsdaten.

Apple beschreibt in der Dokumentation zu benutzerdefinierten Build-Skripten die Rolle solcher Skripte in Xcode Cloud. Zusätzlich sollten Sie die Referenz der Xcode-Cloud-Umgebungsvariablen prüfen, bevor Sie Netzwerk- oder Proxy-Annahmen in ein Skript einbauen.

Geben Sie keine Tokens, privaten Schlüssel oder vollständigen Umgebungsvariablen in das Log aus. Achten Sie bei DSGVO-relevanten Projekten darauf, welche Quellbestandteile, Testdaten und Protokolle in externen Diensten verarbeitet werden. Ein Remote Mac kann den Zugriff auf interne Ressourcen vereinfachen, erhöht aber die Verantwortung für Festplattenlöschung, Benutzerrechte, SSH-Schlüssel und Protokollaufbewahrung.

Ein Prozess sollte als Migrationskandidat gelten, wenn er mindestens eine dieser Eigenschaften besitzt:

  • Er benötigt ein internes Netzwerk, das in der temporären Umgebung nicht zuverlässig erreichbar ist.
  • Er muss einen Hintergrunddienst über mehrere Schritte hinweg aktiv halten.
  • Er verwendet Dateien, die zwischen Builds bewusst erhalten bleiben müssen.
  • Er erfordert vollständige Kontrolle über installierte Werkzeuge oder Systemdienste.
  • Er lässt sich mit den vorhandenen Workflow-Aktionen nicht transparent und reproduzierbar abbilden.
07

Fünf Schritte zur belastbaren Entscheidung

1. Vergleichsfall festlegen

Wählen Sie einen Commit, ein Scheme und einen definierten Testumfang. Verwenden Sie keinen Release-Build als Vergleich zu einem kleinen Pull-Request-Lauf. Notieren Sie Build-ID, Trigger, Xcode-Version und relevante Abhängigkeiten.

2. Zeitabschnitte aus den Logs extrahieren

Übertragen Sie Warteschlange, Vorbereitung, Kompilierung, Tests und Archivierung in eine einfache Tabelle. Wenn eine Zeitangabe nicht direkt im Log steht, kennzeichnen Sie sie als unbekannt. Schätzen Sie keine fehlende Phase aus der Gesamtdauer.

3. Einen Engpass isoliert verändern

Ändern Sie immer nur eine Ursache: etwa ein Post-Clone-Skript, einen unnötigen Clean Build, eine Testgruppe oder eine Trigger-Bedingung. Sonst können Sie nicht erkennen, welche Maßnahme die Rückmeldung verändert hat.

4. Erfolg und Wiederherstellung prüfen

Ein schnellerer Lauf zählt nur, wenn der Build erfolgreich bleibt, die Protokolle vollständig sind und ein Fehlschlag sauber endet. Für einen Remote Mac testen Sie zusätzlich Neustart, erneute Runner-Anmeldung, Bereinigung des Arbeitsverzeichnisses und erneuten Build.

5. Aufgabe statt Plattform migrieren

Verschieben Sie nur die nachweislich problematische Aufgabe. Standard-Builds und Veröffentlichungsvalidierung können in Xcode Cloud bleiben, während komplexe UI-Tests, interne Integrationen oder dauerhaft vorbereitete Archive auf einem Remote Mac laufen. Nach dem Vergleich entscheiden Sie zwischen weiterer Optimierung, Teilmigration und Dual-Track-CI.

08

Wann Remote Mac und Xcode Cloud gemeinsam sinnvoll sind

Ein Dual-Track-Modell passt zu Projekten mit zwei klar unterschiedlichen Betriebsprofilen. Xcode Cloud bleibt praktisch für standardisierte Builds, Pull-Request-Prüfungen und Veröffentlichungsabläufe, bei denen die temporäre Umgebung ausreicht. Ein Remote Mac übernimmt Aufgaben, die Host-Kontrolle, persistente Werkzeuge, interne Netzwerke oder spezielle Testzustände verlangen.

Bevor Sie einen Knoten anmieten, definieren Sie eine kleine Abnahme:

  • Der gleiche Commit baut mit demselben Scheme erfolgreich.
  • Die Signierungs- und Zertifikatszugriffe sind getrennt geschützt.
  • Der Knoten kommt nach einem Neustart wieder in den erwarteten Zustand.
  • Arbeitsverzeichnisse und temporäre Artefakte werden kontrolliert bereinigt.
  • Fehlgeschlagene Jobs hinterlassen verwertbare Logs.
  • Der Wartungsaufwand ist dokumentiert und einer verantwortlichen Person zugeordnet.

Wenn Sie die Kostenoptionen für einen zeitlich begrenzten Vergleich prüfen möchten, finden Sie die Mietpreise für Mac-mini-Umgebungen. Für einen technischen Pilotbetrieb ist außerdem die Übersicht zu Remote-Mac-Entwicklungsumgebungen ein sinnvoller Ausgangspunkt. Vergleichen Sie dabei nicht nur Rechenzeit, sondern auch Einrichtung, Zugriffsschutz, Wiederherstellung und die Zeit Ihrer CI-Verantwortlichen.

Ein weiterer Vorteil des Remote Mac ist der vollständige Hostzugriff. Das erleichtert die Installation eigener Werkzeuge und die Verbindung zu internen Diensten. Der Nachteil ist eindeutig: Sie müssen Patchen, Bereinigung, Schlüsselverwaltung und Zustandskontrolle selbst in den Prozess aufnehmen. Für ein kleines, standardisiertes Projekt kann Xcode Cloud deshalb weiterhin die bessere Wahl sein.

Wenn Ihr aktueller Ansatz hauptsächlich an wiederholter Initialisierung, fehlender Persistenz oder eingeschränkter Netzwerkkontrolle leidet, ist ein Remote Mac die passendere technische Lösung als ein immer größerer Xcode-Cloud-Workflow. Ihre derzeitige Umgebung bleibt dabei nicht wertlos: Sie kann weiterhin für standardisierte Builds, Review-Prüfungen und Releases dienen. VpsMesh eignet sich für einen begrenzten Vergleich auf einem echten Remote Mac, bevor Sie eine dauerhafte Teilmigration oder einen parallelen CI-Betrieb festlegen. Beginnen Sie mit der langsamsten, klar abgegrenzten Aufgabe und entscheiden Sie erst nach reproduzierbaren Logs, erfolgreicher Wiederherstellung und bekanntem Wartungsaufwand.