Xcode 27: Kompilieren langsamer – Remote Mac 2026

Symptom: Nach dem Wechsel auf Xcode 27 dauert der Build deutlich länger, obwohl sich der Quellcode kaum geändert hat.

Schnellste Lösung: Löschen Sie nicht sofort den gesamten Cache und erweitern Sie nicht direkt die Hardware. Erfassen Sie zuerst getrennte Timing Summaries für kalte und inkrementelle Builds; prüfen Sie danach Cache-Invalidierung, Abhängigkeiten, Skripte, Indexierung sowie Arbeitsspeicher- und Festplattenauslastung.

Für wen diese Fehleranalyse gedacht ist

Dieser Leitfaden ist für Apple-Plattform-Entwickler gedacht, die nach dem Upgrade auf Xcode 27 veränderte Kompilierungs-, Indexierungs- oder CI-Zeiten beobachten.

Er richtet sich außerdem an DevOps- und Plattformteams, die einen dauerhaft verfügbaren Remote Mac betreiben und belastbar entscheiden müssen, ob ein Projekt korrigiert, die Toolchain zurückgesetzt oder ein separater Build-Knoten bereitgestellt werden sollte.

Für die Versionsbewertung ist eine wichtige Einschränkung zu beachten: Nach dem angegebenen Prüfstand vom 24.08.2026 führt Apple Xcode 27 als Beta. Systemanforderungen, bekannte Fehler und Verbesserungen können sich daher mit einer weiteren Beta, einem Release Candidate oder der endgültigen Version ändern. Prüfen Sie vor jeder Entscheidung die offiziellen Xcode Release Notes.

Warum „Xcode 27 kompiliert langsamer“ zunächst keine ausreichende Diagnose ist

„Langsamer“ kann mindestens fünf verschiedene Vorgänge meinen: den ersten Build nach einem Checkout, einen normalen inkrementellen Build, ein Archive, einen Testlauf oder die Indexierung im Editor. Diese Vorgänge verwenden nicht dieselben Caches und konkurrieren nicht immer um dieselben Ressourcen. Ein Vergleich nur der Gesamtzeit führt deshalb leicht zu einer falschen Maßnahme.

Ein kalter Build darf länger dauern, weil Module, Abhängigkeiten und generierte Dateien erstmals verarbeitet werden. Ein inkrementeller Build muss dagegen zeigen, dass unveränderte Targets und Eingaben wiederverwendet werden. Wenn beide Zeiten zusammengefasst werden, bleibt verborgen, ob der eigentliche Fehler in der Projektstruktur oder in der Umgebung liegt.

Halten Sie für jeden Vergleich diese Bedingungen fest:

• gleicher Commit oder exakt identischer Quellstand,
• gleiches Scheme und gleiches Zielgerät,
• gleiche Build-Konfiguration, etwa Debug oder Release,
• gleicher DerivedData-Pfad,
• gleiche Anzahl paralleler CI-Aufgaben,
• identischer Zustand der Paket- und Artefakt-Caches.

Xcode stellt mit „Build With Timing Summary“ eine geeignete Messung für einzelne Build-Phasen bereit. Für reproduzierbare CI-Messungen können Sie die entsprechende Timing-Zusammenfassung auch über xcodebuild anfordern. Apples Anleitung zur Messung inkrementeller Build-Zeiten beschreibt, wie diese Daten für die Diagnose verwendet werden.

Achtung: Die Größe des DerivedData-Ordners ist kein Beweis für einen defekten Cache. Entscheidend ist, welche Targets und Skripte im Build-Log erneut ausgeführt werden und warum.

Die erste Messung trennt Rückfall von normaler Mehrarbeit

Starten Sie nicht mit „Clean Build Folder“. Dadurch verlieren Sie gerade die Information, ob der inkrementelle Build vorher noch korrekt wiederverwenden konnte, was bereits kompiliert war. Erstellen Sie stattdessen eine kleine Messreihe aus demselben Projektzustand.

1. Werkzeugkette dokumentieren: Notieren Sie die genaue Xcode-Version, den ausgewählten Developer-Pfad und die Zielplattform. Bei mehreren Installationen muss klar sein, welcher Compiler tatsächlich verwendet wird. Die Xcode Release Notes von Apple sind die Referenz für den Beta-Status und die versionsbezogenen Hinweise.

2. Kalten Build ausführen: Entfernen Sie nur dann projektbezogene Build-Artefakte, wenn Sie den kalten Vergleich ausdrücklich benötigen. Erfassen Sie anschließend die Timing Summary und das vollständige Log. Markieren Sie die längsten Phasen, statt nur die Endzeit zu speichern.

3. Unveränderten Build wiederholen: Führen Sie danach einen Build ohne Quellcodeänderung aus. Wenn die gleichen Quellen erneut kompiliert werden, liegt ein Wiederverwendungs- oder Abhängigkeitsproblem nahe. Wenn dagegen nur der erste Durchlauf lang ist und der zweite normal verläuft, ist die Kaltstartzeit möglicherweise erwartbar.

4. Kleine Änderung testen: Ändern Sie eine klar abgegrenzte Quelldatei und führen Sie erneut einen inkrementellen Build aus. Beobachten Sie, ob nur das betroffene Target oder eine große Kette abhängiger Targets neu gebaut wird.

5. Editorlast ausschließen: Wiederholen Sie den Test über die Kommandozeile, ohne geöffnete Projektansicht, SwiftUI Preview oder Simulator. Ein Unterschied zwischen Kommandozeile und grafischer Sitzung zeigt, dass nicht zwingend der Build selbst die Ursache ist.

6. Archive und Tests separat messen: Ein Archive oder ein Testlauf darf nicht als Beleg für eine langsame Edit-and-Build-Schleife dienen. Erfassen Sie diese Aufgaben als eigene Baselines, weil Signierung, Kopieren, Testvorbereitung und zusätzliche Skripte die Zeit beeinflussen können.

7. Nach Neustart validieren: Führen Sie die Messung nach einem Neustart des Knotens erneut durch. Erst ein Vergleich vor und nach dem Neustart zeigt, ob ein langfristig laufender Prozess, eine festgefahrene Indexierung oder Swap-Aktivität beteiligt ist.

Für das Verständnis der Target-Reihenfolge und der Build-Abhängigkeiten hilft Apples Dokumentation zum Xcode-Build-System. Die entscheidende Frage lautet nicht „Wie groß ist der Cache?“, sondern „Welche Eingabe hat die erneute Ausführung ausgelöst?“.

Wenn inkrementelle Builds ihre Wiederverwendung verlieren

Wenn jede kleine Änderung fast dieselbe Target-Kette wie ein vollständiger Build auslöst, prüfen Sie zuerst die Abhängigkeitsgraphen. Ein Target kann indirekt neu gebaut werden, weil eine generierte Datei, eine Konfigurationsdatei oder ein übergeordnetes Target bei jedem Lauf einen veränderten Zeitstempel erhält.

Achten Sie im Log insbesondere auf diese Hinweise:

• unveränderte Quell-Dateien erscheinen wieder in der Kompilierung,
• generierte Dateien werden bei jedem Build neu geschrieben,
• ein Script erzeugt Ausgaben außerhalb der erwarteten Build-Verzeichnisse,
• bedingte Build-Einstellungen ändern sich zwischen zwei identischen Aufrufen,
• ein gemeinsamer DerivedData-Pfad wird von mehreren Jobs gleichzeitig verwendet.

Kontrollieren Sie die Target-Abhängigkeiten und prüfen Sie, ob ein Script Dateien als Eingabe behandelt, die es tatsächlich nicht benötigt. Bei komplexen Swift-Modulen kann zusätzlich die Abhängigkeitsauflösung die Reihenfolge und den Umfang der Arbeit beeinflussen. Für eine gezielte Diagnose bietet Apple Hinweise zu expliziten Modulabhängigkeiten.

Die Reparatur sollte so klein wie möglich sein. Korrigieren Sie zuerst eine fehlerhafte Eingabe- oder Ausgabedefinition, führen Sie danach zwei oder mehr unveränderte inkrementelle Builds aus und vergleichen Sie die betroffenen Targets. Erst wenn der Log weiterhin widersprüchliche Artefakte zeigt, löschen Sie den DerivedData-Ordner dieses Projekts. Ein globales Löschen aller Projekte verschiebt das Problem nur und macht die nächste Messung langsamer.

Abhängigkeiten und Run-Script-Phasen als versteckte Wartezeit

Ein Build kann sich langsam anfühlen, obwohl die Compilerphasen selbst nicht länger dauern. In diesem Fall wartet Xcode möglicherweise auf Paketauflösung, Netzwerkzugriffe, Generierung oder ein Run Script, das ohne verwertbare Eingabe- und Ausgabedateien bei jedem Durchlauf startet.

Vergleichen Sie den ersten und den zweiten Build im Log. Wird ein Paket bei jedem Lauf erneut aufgelöst, heruntergeladen oder generiert, untersuchen Sie den Paket-Cache und den CI-Arbeitsbereich. Bei einem Remote Mac kommt zusätzlich die Verbindung zu Quellcode- oder Artefaktdiensten hinzu. DNS-Probleme, ein langsamer Proxy oder nicht erreichbare interne Endpunkte können als „Kompilierungsproblem“ erscheinen, obwohl der Compiler wartet.

Für Run Script Phases nennt Apple ausdrücklich Eingabe- und Ausgabedateien als Grundlage dafür, dass Xcode unnötige Wiederholungen überspringen kann. Prüfen Sie die offizielle Dokumentation zu benutzerdefinierten Build-Skripten und tragen Sie nur Dateien ein, die den tatsächlichen Zustand des Scripts beschreiben. Ein pauschales „immer ausführen“ kann für bestimmte Generierungsschritte notwendig sein, sollte aber eine bewusste Ausnahme bleiben.

Bei Swift Packages müssen Sie zwischen einem einmaligen Checkout und einer wiederkehrenden CI-Auflösung unterscheiden. Apples Hinweise zu Swift Packages in CI-Workflows sind dafür die passende Referenz. Nach jeder Änderung testen Sie mindestens einen kalten Lauf und mehrere aufeinanderfolgende inkrementelle Läufe. Ein Script ist erst dann korrekt optimiert, wenn es bei unverändertem Input tatsächlich übersprungen wird.

Indexierung, Preview und Simulator vom Build isolieren

Eine dauerhaft laufende Indexierung kann die Bedienung von Xcode verschlechtern, ohne dass ein reiner Kommandozeilen-Build im gleichen Maß betroffen ist. SourceKit, SwiftUI Preview und Simulator greifen gleichzeitig auf CPU, Arbeitsspeicher und Festplattenzugriffe zu. Auf einem gemeinsam genutzten Remote Mac können zusätzlich andere CI-Jobs dieselben Ressourcen beanspruchen.

Beobachten Sie während der Verzögerung:

• ob die Indexierung ständig neue Dateien verarbeitet,
• ob SwiftUI Preview wiederholt neu startet,
• ob der Simulator parallel Builds oder Tests ausführt,
• ob der Arbeitsspeicher unter Druck gerät,
• ob die Festplattenaktivität dauerhaft hoch bleibt.

Führen Sie zunächst einen Kommandozeilen-Build mit geschlossenem grafischem Projektfenster aus. Läuft dieser normal, wiederholen Sie den Test mit geöffneter Arbeitsumgebung und aktivierter Preview. So erhalten Sie zwei unterschiedliche Befunde: eine Build-System-Ursache oder eine konkurrierende interaktive Last.

Schalten Sie die Indexierung nicht als dauerhafte „Reparatur“ ab. Damit verschwinden Navigation, Referenzsuche und ein Teil der Codeanalyse, während der eigentliche Ressourcenengpass bestehen bleiben kann. Besser ist es, unnötige Previews zu schließen, Simulator-Läufe aus dem Diagnosefenster zu entfernen und interaktive Entwicklungsaufgaben nicht zeitgleich mit einem stark ausgelasteten CI-Lauf auszuführen.

Wann der Remote Mac tatsächlich an seine Grenze kommt

Ein Remote Mac ist nicht automatisch die Ursache langsamer Builds, aber seine Ressourcenverteilung muss messbar sein. Prüfen Sie im Aktivitätsmonitor den Speicherdruck und die Swap-Aktivität; Apple erklärt diese Anzeigen in der Anleitung, ob ein Mac mehr Arbeitsspeicher benötigt. Für die Diagnose zählt der Zustand während des langsamen Vorgangs, nicht die Auslastung zehn Minuten später.

Typische Engpässe lassen sich so unterscheiden:

• Arbeitsspeicher: Der Speicherdruck steigt, Swap-Aktivität nimmt zu und mehrere Prozesse warten. Das spricht eher für konkurrierende Jobs, Indexierung oder zu viele offene Entwicklungsprozesse als für einen einzelnen fehlerhaften Quelltext.
• Festplatten-I/O: DerivedData, Paket-Cache und Arbeitsverzeichnis liegen auf einem stark beanspruchten Speicherpfad oder werden von parallelen Jobs gleichzeitig verändert. Ein einzelner Build kann normal wirken, während mehrere Jobs deutlich einbrechen.
• CPU: Die Compilerphasen laufen dauerhaft, während Speicher und I/O unauffällig bleiben. Dann muss die Timing Summary zeigen, ob tatsächlich mehr Quellcode kompiliert wird oder ob eine einzelne Phase ineffizient ist.
• Netzwerk: Paketauflösung, Artefaktabrufe oder externe Scripts warten auf entfernte Dienste. In diesem Fall hilft ein größerer Mac nicht, solange der Endpunkt oder die Cache-Strategie unverändert bleibt.

Vergleichen Sie auf einem gemeinsam genutzten Knoten einen einzelnen Job mit derselben Aufgabe unter paralleler Last. Wenn nur der parallele Lauf Speicherdruck oder I/O-Sättigung erzeugt, ist eine bessere Job-Isolierung oft sinnvoller als ein pauschales Hardware-Upgrade. Prüfen Sie außerdem, ob mehrere Xcode-Versionen, Projekte und Paket-Caches denselben Arbeitsbereich verwenden.

Welche Entscheidung nach der Messung vertretbar ist

Nutzen Sie die folgenden Punkte als abhakbare Entscheidungshilfe. Jeder Punkt sollte mit einem Log, einer Timing Summary oder einer Ressourcenaufzeichnung belegt werden:

• [ ] Kalt- und inkrementeller Build wurden mit demselben Commit, Scheme und Ziel getrennt erfasst.
• [ ] Die längste Build-Phase ist bekannt; die Gesamtzeit allein wurde nicht als Diagnose verwendet.
• [ ] Wiederholt kompilierte Targets und veränderte Eingabedateien wurden geprüft.
• [ ] Run Script Phases besitzen passende Eingabe- und Ausgabedefinitionen oder sind bewusst als immer auszuführen markiert.
• [ ] Paketauflösung, Downloads und Generierung wurden zwischen erstem und folgendem Build verglichen.
• [ ] Kommandozeilen-Build und grafische Sitzung wurden getrennt getestet.
• [ ] Indexierung, Preview, Simulator und parallele CI-Jobs wurden während der Messung berücksichtigt.
• [ ] Speicherdruck, Swap-Aktivität, CPU-Last und Festplatten-I/O stammen aus demselben Diagnosefenster.
• [ ] Ein einzelner Job wurde mit einem parallelen Job auf demselben Knoten verglichen.
• [ ] Nach einer Änderung wurden mehrere Folge-Builds und mindestens ein Test nach Neustart ausgeführt.

Treffen Sie die Entscheidung anschließend nach Ursache:

• Wenn ein bestimmtes Script, eine Paketauflösung oder eine Target-Abhängigkeit dominiert, korrigieren Sie zuerst das Projekt.
• Wenn der Fehler nur mit Xcode 27 Beta auftritt, halten Sie die stabile Produktionskette mit Xcode 26.6 getrennt und testen Sie Xcode 27 auf einem isolierten Knoten. Die Versionsentscheidung muss an den jeweils aktuellen offiziellen Release Notes ausgerichtet werden.
• Wenn der Build normal ist, aber Speicher oder I/O bei parallel laufenden Jobs dauerhaft gesättigt sind, reduzieren Sie zunächst die Parallelität. Bleibt der Engpass reproduzierbar, prüfen Sie einen zusätzlichen oder größeren Remote Mac.
• Wenn der Engpass bei Netzwerk- oder Artefaktzugriffen entsteht, optimieren Sie die Cache- und Dienstanbindung, bevor Sie Hardware bestellen.
• Wenn nur DerivedData eines Projekts widersprüchliche Artefakte enthält, löschen Sie gezielt diesen Projektbereich und dokumentieren Sie den Vorher-Nachher-Vergleich.

Für Teams, die mehrere Versionen parallel verwalten, ist ein separater Remote-Mac-Arbeitsablauf sinnvoller als ein ungeprüfter Wechsel auf allen Produktionsknoten. Wenn Sie die Umgebung zuerst reproduzierbar aufsetzen möchten, können Sie die Remote-Mac-Angebote von KVMFLUX als Option für einen isolierten Testknoten prüfen. Die Entscheidung sollte jedoch erst nach der Messung fallen.

FAQ zur langsamen Xcode-27-Kompilierung

Warum wirkt jede Codeänderung in Xcode 27 wie eine vollständige Kompilierung?

Prüfen Sie zunächst die Timing Summary und das Build-Log. Werden unveränderte Targets, generierte Dateien oder Run-Script-Phasen erneut ausgeführt, liegt meist ein Problem bei Abhängigkeiten oder Eingabe- und Ausgabedateien vor. DerivedData sollte erst nach dieser Prüfung gezielt gelöscht werden, nicht als pauschale erste Maßnahme.

Was tun, wenn die Indexierung auf dem Remote Mac nicht endet?

Isolieren Sie den Kommandozeilen-Build von Xcode, Preview und Simulator. Beobachten Sie gleichzeitig Speicherdruck, Swap und Festplattenzugriffe. Wenn der Build ohne grafische Sitzung normal läuft, reduzieren Sie die konkurrierenden Aufgaben. Eine dauerhaft deaktivierte Indexierung kaschiert lediglich die Ursache und beeinträchtigt Navigation sowie Codeanalyse.

Hilft das Löschen von DerivedData gegen langsame Builds?

Nur wenn konkrete Hinweise auf beschädigte oder inkonsistente Build-Artefakte bestehen. Das Löschen behebt keine fehlerhaften Target-Abhängigkeiten, wiederkehrenden Paketauflösungen oder unvollständig beschriebenen Scripts. Erfassen Sie zuerst die Build-Daten, löschen Sie nur den betroffenen Projektordner und vergleichen Sie anschließend mehrere inkrementelle Builds.

Wie unterscheide ich ein Projektproblem von einer zu schwachen Mac-Konfiguration?

Vergleichen Sie denselben Commit in einem kalten und mehreren inkrementellen Builds, zunächst ohne konkurrierende grafische Aufgaben. Eine dauerhaft dominante Projektphase spricht für Abhängigkeiten oder Scripts. Treten dagegen bei verschiedenen Aufgaben Speicherdruck, Swap oder I/O-Sättigung auf, ist die Knoten-Konfiguration oder die Parallelität der wahrscheinlichere Ansatzpunkt.

Fazit: Erst die Ursache isolieren, dann die Produktionsumgebung ändern

Wenn Xcode 27 langsamer kompiliert, liefert eine getrennte Timing Summary schneller verwertbare Informationen als das vollständige Leeren von DerivedData. Für ein Beta-Problem bleibt die saubere Produktionsentscheidung: Xcode 26.6 stabil weiterbetreiben, Xcode 27 auf einem isolierten Remote Mac prüfen und erst nach reproduzierbaren Messungen über Rückkehr, Projektkorrektur oder Erweiterung entscheiden.

Eine lokale Installation oder ein gemeinsam verwendeter Mac bleibt für langfristige, dauerhaft hohe Last oft wirtschaftlicher, sofern die Hardware bereits vorhanden ist. Sie bringt jedoch auch Kapitalbindung, Wartung, Stromversorgung, physische Ausfallrisiken und eine schlechtere Trennung zwischen Beta- und Produktions-Toolchain mit sich. Ein eigener Cloud- oder Linux-Knoten hilft bei vielen allgemeinen CI-Aufgaben, kann aber die macOS-spezifische Xcode-Toolchain nicht ersetzen.

Wenn Sie dagegen nur für die Doppelvalidierung, einen isolierten Beta-Knoten oder eine zeitlich begrenzte Kapazität eine zusätzliche Umgebung benötigen, kann ein gemieteter Remote Mac von KVMFLUX die Variablen sauberer trennen, ohne sofort neue Hardware zu kaufen. Prüfen Sie dafür vorab die Datenschutz- und Betriebsinformationen von KVMFLUX und verwenden Sie den Knoten zunächst als reproduzierbare Testumgebung, nicht als Ersatz für eine ungeprüfte Diagnose.

Weiterlesen

• Xcode-27-Installationsfehler systematisch prüfen
• Xcode-CI auf einem Cloud Mac zuverlässig einrichten
• Self-hosted Runner auf einem Remote Mac betreiben

Häufige Fragen