iOS-Build-Server zu wenig Speicherplatz? Xcode 27 2026 bereinigen oder erweitern

Der iOS-Build-Server meldet kurz vor einem Archive plötzlich zu wenig Speicherplatz, obwohl Quellcode und Entwicklerkonto unverändert sind.

Schnellste Lösung: Prüfen Sie zuerst laufende Build-, Test- und Archive-Aufgaben und ordnen Sie danach DerivedData, Simulator-Komponenten, Abhängigkeiten und Veröffentlichungsartefakte getrennt zu; bereinigen Sie nur regenerierbare Daten. Erst wenn der Speicher trotz kontrollierter Bereinigung wiederholt knapp wird, sollten Sie erweitern oder einen zusätzlichen Remote Mac einplanen.

Diese Anleitung ist für Sie gedacht, wenn Sie nur einen Remote Mac betreiben und wiederkehrende Speicherwarnungen bei Xcode 27 sicher untersuchen möchten. Sie hilft außerdem, wenn mehrere Xcode-Versionen, Simulator Runtime-Komponenten oder historische Archive erhalten bleiben müssen. Kleine Teams mit mehreren Apps erhalten eine Entscheidungsgrundlage für Einzelserver, Speichererweiterung oder die Aufteilung der Build- und Testumgebung.

Die richtige Reihenfolge beginnt nicht mit dem Löschbefehl

Ein voller Datenträger ist zunächst ein Diagnoseproblem. Ein fehlgeschlagenes Archive kann durch regenerierbare Build-Daten, eine neu installierte Simulator-Komponente, wachsende Paket-Caches oder bewusst aufbewahrte Archive verursacht werden. Diese Kategorien haben jedoch nicht dieselbe Wiederherstellbarkeit.

Für die Prüfung sollten Sie den Zustand des Remote Mac dokumentieren, bevor Sie Dateien entfernen:

1. Prüfen Sie, ob aktuell ein Build, Test, Archive, Export oder Upload läuft.
2. Erfassen Sie den freien Speicher und die größten Verzeichnisse, ohne zunächst Inhalte zu löschen.
3. Ordnen Sie jeden großen Bestand einem Projekt, einer Xcode-Version, einem Simulator oder einem Veröffentlichungsprozess zu.
4. Markieren Sie Daten als „regenerierbar“, „erst nach Sicherung löschbar“ oder „nicht direkt löschen“.
5. Führen Sie erst danach eine begrenzte Bereinigung durch und validieren Sie anschließend einen vollständigen Archive-Ablauf.

Die Trennung entspricht dem Xcode-Build-System: Abhängigkeiten, Build-Einstellungen und Ausgabepfade beeinflussen, wo Zwischenprodukte entstehen und wie ein Build wiederholt werden kann. Die offizielle Dokumentation zum Xcode Build System ist deshalb die bessere Referenz als eine pauschale Löschanleitung.

Ein Remote Mac darf während dieser Prüfung nicht gleichzeitig von mehreren Automatisierungen verändert werden. Sonst lässt sich später nicht mehr feststellen, ob ein Fehler durch den Speichermangel, eine gelöschte Abhängigkeit oder einen unterbrochenen Build entstanden ist.

Wenn nur Release-Archive laufen: DerivedData zuerst prüfen

Ein Server, der ausschließlich signierte Release-Archive erstellt, hat andere Speicheranforderungen als ein Entwicklungsrechner mit inkrementeller Kompilierung, Debugging und SwiftUI Preview. Bei der reinen Veröffentlichung sind bestimmte Build-Zwischendaten oft leichter regenerierbar. Daraus folgt aber nicht, dass jeder Ordner mit „DerivedData“ ohne Prüfung gelöscht werden darf.

DerivedData enthält projektbezogene Build-Zustände. Die tatsächliche Ablage kann über die Xcode-Einstellungen oder den Build-Aufruf beeinflusst werden. Mit xcodebuild lässt sich ein eigener Derived-Data-Pfad festlegen; die dafür dokumentierte Option und das Pfadprinzip finden Sie im Apple-Beispiel für abgeleitete Build-Daten.

Vor einer Bereinigung gelten folgende Bedingungen:

• Kein Build-, Test- oder Archive-Prozess darf mehr laufen.
• Ein aktiver CI/CD-Auftrag muss abgeschlossen oder kontrolliert angehalten sein.
• Sie müssen wissen, welchem Projekt der Pfad gehört.
• Der nächste Build muss Abhängigkeiten erneut auflösen können.
• Ein laufender Entwicklerprozess darf nicht auf dieselben Zwischenprodukte angewiesen sein.

Bei einem selten veröffentlichten Einzelprojekt können Sie alte DerivedData nach dieser Prüfung entfernen oder gezielt neu erzeugen lassen. Bei mehreren Projekten ist eine globale Löschung riskanter, weil damit die Vergleichbarkeit eines laufenden Fehlers verloren gehen kann. Wenn ein bestimmter Build bereits untersucht wird, sichern Sie zuerst Logs, Build-Einstellungen und das verwendete Commit.

Die Apple-Referenz zu Build Settings ist für die Zuordnung wichtig. Sie zeigt, dass Ausgabepfade und Build-Parameter nicht unabhängig vom Projekt betrachtet werden sollten. Eine Bereinigung ist also erst dann sauber, wenn Sie den konkreten Auftrag reproduzieren können.

Was bei den Build-Produkten anders ist

Build Products sind Ergebnisse eines konkreten Build-Vorgangs, aber nicht automatisch identisch mit einem veröffentlichungsfähigen Archive. Temporäre Produkte können bei einem neuen Build entstehen. Ein für die Fehleranalyse benötigtes Ergebnis sollten Sie jedoch erst nach der Dokumentation entfernen.

Prüfen Sie deshalb:

• Gehört der Bestand zu einem abgeschlossenen oder noch laufenden Auftrag?
• Gibt es bereits ein verifiziertes Ersatzartefakt?
• Können Sie denselben Commit mit denselben Signatur- und Abhängigkeitseinstellungen erneut bauen?
• Wird das Ergebnis noch für einen Vergleich zwischen Xcode-Versionen benötigt?

Wenn Sie eine dieser Fragen nicht beantworten können, ist „erst sichern, dann löschen“ die richtige Entscheidung. Das gilt besonders auf einem einzigen Server, der zugleich Entwicklungs-, Test- und Veröffentlichungsaufgaben übernimmt.

Xcode 27 auf dem Build-Server: Welche Komponenten bleiben?

Ein Xcode-Build-Server kann neben dem eigentlichen Entwicklungswerkzeug zusätzliche Plattform- und Simulator-Komponenten enthalten. Diese Komponenten sind nicht dasselbe wie ein angelegtes Simulator-Gerät, dessen App-Daten oder ein Testresultat.

Die Dokumentation zur Verwaltung zusätzlicher Xcode-Komponenten eignet sich als Referenz für installierte Bestandteile. Prüfen Sie dort nicht nur, ob eine Komponente vorhanden ist, sondern ob Ihre Build- und Testmatrix sie tatsächlich benötigt.

Für einen Server mit reinem Release-Archive ist eine vollständige Sammlung von Simulator Runtime-Versionen häufig schwer zu begründen. Für UI-Tests, Regressionen und mehrere unterstützte Betriebssystemversionen kann sie dagegen erforderlich sein. Die Entscheidung muss aus den tatsächlich ausgeführten Testaufträgen kommen, nicht aus der Annahme, dass jede installierte Runtime automatisch gebraucht wird.

Simulator Runtime, Geräte und Testdaten getrennt behandeln

Unter Simulator-Daten fallen mindestens mehrere unterschiedliche Objekte:

• installierte Simulator Runtime-Komponenten,
• angelegte virtuelle Geräte,
• App-Daten innerhalb dieser Geräte,
• Screenshots und Testausgaben,
• Testresultate und Protokolle.

Eine Runtime zu entfernen, kann eine komplette Testumgebung unbrauchbar machen. Alte App-Daten eines nicht mehr verwendeten virtuellen Geräts sind dagegen anders zu bewerten. Auch Testresultate können für einen Regressionnachweis oder eine Fehleranalyse relevant sein.

Apple weist ausdrücklich darauf hin, dass ein simuliertes Gerät kein physisches Gerät ersetzt. Die Apple-Erklärung zu simulierten und physischen Geräten ist deshalb bei jeder Aufbewahrungsentscheidung zu berücksichtigen. Ein kleinerer Simulator-Bestand spart nicht automatisch die Validierung auf echter Hardware ein.

Wie lange Simulator Runtime und Archive bleiben sollten

Eine pauschale Aufbewahrungsdauer lässt sich ohne Ihre Testmatrix und Release-Richtlinie nicht seriös festlegen. Bewahren Sie eine Runtime so lange auf, wie ein aktiver Testauftrag sie benötigt. Ein Archive bleibt so lange relevant, wie Sie daraus erneut exportieren, einen Upload nachvollziehen oder einen Produktionsfehler untersuchen müssen.

Löschen Sie nicht zuerst die Runtime, nur weil sie groß erscheint, wenn ein geplanter UI-Test genau diese Version voraussetzt. Entfernen Sie umgekehrt keine historischen Archive, wenn Sie noch keine unabhängige Kopie der benötigten Nachweise besitzen.

Mehrere Apps und Abhängigkeiten verlangen eine Zuordnung

Bei mehreren Projekten entsteht der größte Fehler oft nicht durch das Löschen selbst, sondern durch fehlende Eigentümerschaft. Ein globaler Cache kann von mehreren Apps, Xcode-Versionen oder Abhängigkeiten verwendet werden. Swift Package Manager, CocoaPods und private Pakete sollten deshalb getrennt nach Quelle und Projekt betrachtet werden.

Für jeden Bestand sollten Sie mindestens diese Angaben festhalten:

• Projekt oder Repository,
• verwendete Xcode-Version,
• Commit oder Release-Zweig,
• Abhängigkeitsquelle,
• geplanter Build-Typ,
• Zeitpunkt der letzten erfolgreichen Wiederherstellung.

Eine Bereinigung von Paketdaten ist erst belastbar, wenn eine erneute Auflösung möglich ist. Führen Sie danach nicht nur einen schnellen Kompilierungstest aus, sondern prüfen Sie die vollständige Kette: Abhängigkeiten auflösen, Build durchführen, Archive erzeugen, Signatur verwenden und das Resultat exportieren.

Das ist besonders wichtig bei privaten Abhängigkeiten. Wenn ein Paket nur über einen internen Zugriff erreichbar ist, kann ein scheinbar harmloser Cache-Löschvorgang aus einem kurzfristigen Platzproblem ein Wiederherstellungsproblem machen. Dokumentieren Sie daher den Zugriff, bevor Sie den lokalen Bestand entfernen.

Veröffentlichungsartefakte nicht wie Cache behandeln

Ein xcarchive ist kein gewöhnlicher Zwischenstand. Je nach Arbeitsablauf können daraus Exportvarianten erzeugt, Uploads nachvollzogen oder Debugging-Informationen für spätere Fehleranalysen verwendet werden. Eine IPA-Datei kann für TestFlight- oder interne Verteilung relevant sein. Eine dSYM-Datei kann für die Zuordnung symbolischer Absturzberichte benötigt werden. Ein xcresult-Bestand kann Testresultate und Protokolle enthalten.

Die Apple-Dokumentation zu Debugging-Informationen erklärt die Rolle der Debug-Symbole. Die Dokumentation zu Testergebnissen ist maßgeblich, wenn Sie xcresult-Dateien für Testnachweise oder Fehleranalyse aufbewahren.

Ordnen Sie deshalb die Bestände in getrennte Regeln ein:

• Vorläufig löschbar: nicht mehr benötigte temporäre Build-Ausgaben nach abgeschlossener Prüfung.
• Erst sichern: Archive, IPA, dSYM und xcresult, wenn noch ein Release-, Support- oder Analysebedarf besteht.
• Nicht als Cache behandeln: Signaturmaterial, Schlüsselbund, Zertifikate und Provisioning-Profile.
• Separat dokumentieren: Upload-Logs und Exportprotokolle, wenn ein Store- oder Kundenprozess nachvollziehbar bleiben muss.

Die Signatur selbst ist kein Speicher-Cache. Löschen Sie niemals den Schlüsselbund oder sämtliche Signaturdateien, nur weil der Datenträger voll ist. Vor einer Bereinigung muss mindestens eine überprüfbare Wiederherstellungsquelle für Quellcode, Signatur und Build-Kette existieren. Eine Apple-Erklärung zum Archive-Export kann bei der Einordnung des Veröffentlichungsprozesses helfen.

Fünf Schritte für eine kontrollierte Rückgewinnung

Erster Schritt: Auftrag sperren und Zustand erfassen

Stoppen Sie neue Build- und Testaufträge für die Dauer der Prüfung. Lassen Sie bereits laufende Prozesse entweder sauber fertigstellen oder brechen Sie sie kontrolliert ab. Notieren Sie freien Speicher, laufende Prozesse, verwendete Projekte und den zuletzt erfolgreichen Archive-Auftrag.

Zweiter Schritt: Speicher nach Besitzer statt nach Dateiendung ordnen

Suchen Sie nicht nur nach großen Dateien. Ermitteln Sie, ob der Platz von DerivedData, Simulatoren, Paketdaten, Archiven, Testergebnissen oder Logs belegt wird. Ein großes Verzeichnis ohne Projektzuordnung darf nicht automatisch gelöscht werden.

Dritter Schritt: Erneuerbare Daten begrenzt bereinigen

Beginnen Sie mit klar zugeordneten DerivedData- und temporären Build-Beständen abgeschlossener Aufträge. Entfernen Sie nicht gleichzeitig Simulator Runtime, Archive und Abhängigkeiten. So bleibt der Ursache-Wirkungs-Zusammenhang nachvollziehbar.

Vierter Schritt: Kaltstart des Build-Prozesses prüfen

Lösen Sie die erforderlichen Abhängigkeiten erneut auf und führen Sie den Build mit dem vorgesehenen Schema aus. Prüfen Sie, ob der Build-Aufruf denselben Derived-Data- und Ausgabeort verwendet wie die Automatisierung. Die Apple-Dokumentation zur Scheme-Konfiguration hilft bei dieser Zuordnung.

Fünfter Schritt: Vollständiges Archive und Rückfallweg verifizieren

Ein erfolgreicher Kompilierungsschritt reicht nicht. Erzeugen Sie ein vollständiges Archive, prüfen Sie Signatur und Export und kontrollieren Sie die erzeugten Nachweise. Wenn das Archive nicht reproduzierbar erstellt werden kann, stoppen Sie weitere Löschungen und stellen Sie den vorherigen Bestand wieder her.

Entscheidung: weiter bereinigen, erweitern oder den Server aufteilen

Nutzen Sie diese Bedingungen statt einer pauschalen Speicherregel:

• Wenn der belegte Platz überwiegend aus abgeschlossenen DerivedData- und temporären Build-Beständen besteht, dann bereinigen Sie projektbezogen und führen Sie danach einen vollständigen Archive-Test aus.
• Wenn der Platz hauptsächlich aus benötigten Simulator Runtime-Versionen und aktiven Testdaten besteht, dann behalten Sie die Testmatrix und entfernen höchstens nicht mehr zugeordnete Geräte- oder App-Daten.
• Wenn historische Archive, dSYM-Dateien und xcresult-Bestände für Release-Nachweise benötigt werden, dann verschieben Sie sie auf eine überprüfte Ablage, bevor Sie lokalen Speicher freigeben.
• Wenn mehrere Apps regelmäßig dieselbe Speichergrenze erreichen, dann ist eine dauerhafte Speichererweiterung sinnvoller als wiederholte Notbereinigung.
• Wenn Entwicklung, UI-Tests und automatisierte Veröffentlichung einander blockieren, dann trennen Sie die Rollen auf mehrere Remote Macs.
• Wenn der Platzbedarf nur während einer kurzfristigen Release- oder Validierungsphase steigt, dann kann ein zusätzlicher, zeitlich begrenzter Build-Server leichter zurückgebaut werden als ein Eingriff in den einzigen Produktionsserver.

Speicherstrategie für den laufenden Betrieb

Für einen einzelnen, selten genutzten Build-Server genügt meist eine dokumentierte Bereinigungsroutine mit klaren Stop-Bedingungen. Entscheidend ist nicht ein starres Löschdatum, sondern die Frage, ob ein Bestand regenerierbar und sein Ersatz bereits geprüft ist.

Bei mehreren Apps sollten Sie Speicherwarnungen nicht erst beim fehlgeschlagenen Archive bearbeiten. Erfassen Sie regelmäßig die Verteilung nach Projekt, Xcode-Komponente, Simulator, Abhängigkeit und Veröffentlichungsartefakt. Die konkrete Warnschwelle muss zu Ihrem Build-Verhalten passen; eine allgemeine Prozentangabe wäre ohne Ihre Datengrundlage nicht belastbar.

Datenschutz und Zugriff gehören ebenfalls zur Entscheidung. Logs, Archive und Testresultate können Quellcode, Paketnamen, interne Endpunkte oder Nutzungsdaten enthalten. Wenn Sie Artefakte auf eine externe Ablage verschieben, prüfen Sie Zugriffskontrolle, Verschlüsselung und DSGVO-Anforderungen. Eine größere Festplatte löst keine unklare Berechtigungspolitik.

Wenn der Speicherbedarf nur durch eine zeitlich begrenzte Version, zusätzliche Simulatoren oder einen Release-Höhepunkt entsteht, kann ein separater Remote Mac die risikoärmere Lösung sein. Sie behalten den bestehenden Produktionsserver unverändert, testen die neue Umgebung mit einem kontrollierten Auftrag und können sie nach der Phase wieder freigeben. Informationen zu verfügbaren Remote-Mac-Konfigurationen finden Sie bei VPSMAC.

Bewertung der drei Wege

• Weiter bereinigen – Bewertung: 4/5: geeignet für seltene Einzelprojekte mit klar regenerierbaren Daten; ungeeignet, wenn Archive und mehrere Testmatrizen dauerhaft wachsen.
• Speicher erweitern – Bewertung: 4/5: sinnvoll bei einem stabilen, gut zugeordneten Arbeitsablauf; weniger geeignet, wenn unterschiedliche Rollen und Projekte denselben Host blockieren.
• Zusätzlichen Remote Mac mieten – Bewertung: 5/5: besonders passend für kurzfristige Release-Spitzen, neue Xcode-Versionen oder getrennte Testaufgaben; nicht ideal, wenn Sie dauerhaft hohe Last auf einer eigenen, unveränderten Infrastruktur benötigen.

Wenn Ihr aktueller Server durch wiederkehrende Löschaktionen instabil wird, entstehen neben dem Speicherproblem weitere Kosten: unterbrochene Builds, fehlende Debug-Symbole, nicht nachvollziehbare Exporte und ein höheres Risiko für die einzige Produktionspipeline. Ein zusätzlicher Mietzeitraum bei VPSMAC kann dann die sauberere Zwischenlösung sein, weil Sie eine neue Umgebung parallel prüfen, statt den bestehenden Host bis zur Grenze zu bereinigen. Prüfen Sie dafür die passende M4-Knoten-Konfiguration für Ihren Build-Einsatz und testen Sie zuerst einen vollständigen Archive- und Exportlauf.

Für Ihren aktuellen iOS-Build-Server gilt damit: erst den belegten Speicher nach Funktion trennen, dann regenerierbare Daten kontrolliert entfernen und anschließend die gesamte Build-Kette validieren. Wenn derselbe Speicherengpass trotz dieser Ordnung wiederkehrt, ist eine Erweiterung oder ein zusätzlicher Remote Mac die nachvollziehbarere Entscheidung als das wiederholte Löschen von Archive-, Signatur- oder Testnachweisen.