Xcode-Speicher freigeben: DerivedData, Archive und DeviceSupport richtig einordnen

Xcode legt fast alles, was beim Bauen, Archivieren und Debuggen entsteht, unter ~/Library/Developer/Xcode ab. Mit jedem Projekt, jedem Branch und jeder neuen Xcode-Version kommt etwas dazu, und nur ein Teil davon verschwindet von selbst wieder. Auf einem MacBook mit kleiner interner SSD stellt sich deshalb früher oder später die Frage, was davon weg kann. Die ehrliche Antwort: Einiges darfst du löschen, einiges solltest du behalten, und manches ist auf einer externen SSD besser aufgehoben als im Papierkorb.

Was in ~/Library/Developer/Xcode liegt

DerivedData enthält Build-Produkte, Zwischenstände des Compilers, Modul-Caches und den Index, den Xcode für Autovervollständigung und Suche nutzt. Bei Projekten mit Swift-Paketen liegen hier außerdem die ausgecheckten Paketquellen. Jedes Projekt bekommt einen eigenen Unterordner, auch Projekte, die du seit Monaten nicht mehr geöffnet hast.

Archives sammelt die Archive, die beim Archivieren für TestFlight, den App Store oder eine andere Verteilung entstehen. Ein Archiv enthält neben der App auch die Debug-Symbole, die du später brauchst, um Absturzberichte lesbar zu machen.

iOS DeviceSupport enthält Symboldateien für jede iOS-Version eines Geräts, das du einmal zum Debuggen verbunden hast. Für andere Plattformen wie watchOS gibt es entsprechende Ordner. Mit jedem größeren Systemupdate deiner Testgeräte kommt ein weiterer Satz hinzu.

Eine Ebene höher liegt ~/Library/Developer/CoreSimulator mit den Simulator-Geräten. Das ist ein eigenes Thema mit eigenen Regeln, dazu weiter unten mehr.

DerivedData: Löschen ist erlaubt, kostet aber Zeit

DerivedData ist vollständig regenerierbar. Beende Xcode, öffne den Ordner im Finder über „Gehe zu“ → „Gehe zum Ordner“ und lege seinen Inhalt in den Papierkorb. Im Terminal entfernst du den Inhalt mit rm -rf ~/Library/Developer/Xcode/DerivedData/*. Prüfe diesen Befehl besonders sorgfältig: rm legt nichts in den Papierkorb, und ein Tippfehler im Pfad kann an ganz anderer Stelle Daten löschen.

Der Preis zeigt sich beim nächsten Öffnen. Xcode indiziert das Projekt neu, der erste Build dauert länger, und Swift-Pakete werden erneut geladen, wofür du eine Internetverbindung brauchst. Geht es nur um ein einzelnes Projekt mit seltsamen Build-Fehlern, genügt oft „Product“ → „Clean Build Folder“. Das leert den Build-Ordner des geöffneten Projekts und lässt alle anderen Projekte unberührt.

Archive: nicht leichtfertig löschen

Archive sind der Teil, bei dem Aufräumen am teuersten werden kann. Für jede Version, die du ausgeliefert hast, brauchst du die passenden Debug-Symbole, um Absturzberichte dieser Version auszuwerten. Apple empfiehlt deshalb, die Archive verteilter Builds aufzubewahren. Archive von Testläufen, die nie ausgeliefert wurden, kannst du dagegen im Organizer von Xcode entfernen.

Belegen deine Archive viel Platz, ist Verlegen die bessere Antwort als Löschen. Sie gehören außerdem in dein Backup, denn die Debug-Symbole eines bereits ausgelieferten Builds lassen sich nicht einfach neu erzeugen.

iOS DeviceSupport: alte Versionen aussortieren

Die Ordner in iOS DeviceSupport sind nach Systemversionen benannt. Versionen, die auf keinem deiner Testgeräte mehr laufen, kannst du löschen. Verbindest du später ein Gerät mit einer gelöschten Version, legt Xcode die Symboldateien neu an. Das kostet beim ersten Verbinden etwas Wartezeit, aber keine Daten.

Verlegen statt löschen: drei Wege

Die Einstellung in Xcode

Unter Xcode → Settings → Locations legst du für DerivedData einen eigenen Speicherort fest und kannst auch den Ablageort für Archive ändern. Das ist der offiziell vorgesehene Weg und für DerivedData oft der einfachste. Er betrifft allerdings nur Xcode-Daten und nur den Benutzer, der die Einstellung setzt. Ist die SSD nicht angeschlossen, fehlt Xcode der eingestellte Ort.

Ein symbolischer Link

Alternativ kopierst du den Ordner auf die SSD, prüfst die Kopie und ersetzt den alten Ort durch einen symbolischen Link. Xcode und alle anderen Werkzeuge, die den Standardpfad erwarten, folgen dem Link ohne weitere Einstellung. Wie das mit Prüfung und Rückweg gelingt, zeigt die Schritt-für-Schritt-Anleitung zum Auslagern.

DevSpace Manager

DevSpace Manager, eine macOS-App von BRUNIQO, führt diesen Umzug mit einem Plan, einem vollständigen Dateivergleich und einem aufbewahrten Original durch. Der Plan prüft vorher unter anderem, ob Prozesse von Xcode oder Simulator laufen. Xcode DerivedData und Xcode-Archive gehören zu den typischen Kandidaten. Nach dem Umschalten bleibt das interne Original als Quarantäne für einen möglichen Rollback erhalten, bis du die Freigabe gesondert bestätigst. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht.

Worauf du bei DerivedData auf einer externen SSD achten solltest

Wie schnell Builds danach laufen, hängt von der SSD und ihrer Verbindung ab. Eine schnelle SSD, die direkt am Mac hängt, ist für Build-Ordner die richtige Wahl, ein langsamer USB-Stick nicht. In Apples Entwicklerforen gibt es außerdem Berichte, dass einzelne Test-Konstellationen mit DerivedData auf einem externen Laufwerk Probleme machen. Spiel nach dem Umzug deshalb deinen kompletten Ablauf einmal durch: bauen, testen, archivieren, auf einem Gerät starten.

Denk auch an den Alltag: Liegt DerivedData auf der SSD, brauchst du die SSD für jeden Build. Nimmst du das MacBook ohne SSD mit, kannst du unterwegs nur bauen, wenn du vorübergehend auf einen internen Ort zurückwechselst.

Was nicht hierher gehört: Simulatoren

Simulator-Runtimes und Simulator-Geräte verschiebst du nicht per Ordnerumzug. Runtimes verwaltest du in Xcode unter Settings → Components, einzelne Geräte im Fenster „Devices and Simulators“ oder mit xcrun simctl. Wie das im Detail geht und warum Docker Desktop in dieselbe Kategorie fällt, beschreibt der Beitrag Simulator-Runtimes und Docker.raw.

Die Ordner auf einen Blick

Muss es schnell gehen, bringt das Leeren von DerivedData meist den größten Sofortgewinn, denn dabei gehen keine Daten verloren, nur Build-Zeit. Willst du dauerhaft Ruhe, verlegst du DerivedData und die Archive auf eine SSD, die an deinem Arbeitsplatz angeschlossen bleibt, und räumst DeviceSupport und Simulatoren gelegentlich über die dafür vorgesehenen Wege auf.

Und das Backup?

Ob du löschst oder verlegst: Archive gehören in ein unabhängiges Backup, DerivedData nicht. Das Auslagern auf eine SSD ersetzt kein Backup, es verschiebt nur den Ort, an dem deine einzige Arbeitskopie liegt. Einen Überblick über den Funktionsumfang gibt die Seite zu DevSpace Manager.