Xcode aufräumen, ohne Release-Artefakte zu verlieren

Xcode verteilt Speicherplatz auf Build-Ausgaben, Indizes, Archive, Device Support, Simulator-Geräte und herunterladbare Plattform-Runtimes. Manches ist reproduzierbar; manches ist die einzige Kopie eines Release-Archivs oder seiner dSYMs. Der sichere Weg ist, jede Kategorie zu messen, sie nach Möglichkeit über Xcode zu entfernen und Artefakte zu bewahren, die an ausgelieferte Builds gebunden sind.

Wohin Xcodes Gigabyte wandern

Beginnen Sie mit den beiden wichtigsten Benutzerordnern:

du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h

Die üblichen Schwergewichte sind:

• DerivedData: Build-Produkte, Indizes und Modul-Caches, meist ein Ordner pro Projekt. Er ist neu erstellbar, aber ein vollständiges Leeren macht nachfolgende Indexierung und Builds teuer. Zielen Sie zuerst auf das veraltete Projekt.
• DeviceSupport: Symbole und Support-Artefakte, die für physische Geräte und OS-Builds erfasst wurden. Alte Einträge können für die Crash-Symbolisierung noch nützlich sein.
• Archives: gespeicherte Builds von jedem Export oder jeder Auslieferung einer App. Apple empfiehlt, das Archiv für jeden verteilten Build zu behalten, weil Binaries und passende dSYM-Dateien nötig sein können, um spätere Crash-Reports zu analysieren. Archive von Builds, die Ihren Mac nie verlassen haben, sind die sichereren Aufräumkandidaten.
• Simulator-Geräte und Plattform-Runtimes: Geräte liegen unter CoreSimulator, herunterladbare Runtimes werden als Xcode-Komponenten verwaltet. Das ist kein einziger Cache.

Sicher leeren, Kategorie für Kategorie

DerivedData bereinigen Sie am besten pro Projekt. Öffnen Sie Xcode > Settings > Locations, um den Derived-Data-Ordner des Projekts zu finden. Prüfen Sie, dass Quellcode, Toolchain und Abhängigkeiten für einen neuen Build verfügbar sind. Beenden Sie dann laufende Builds und Xcode, bevor Sie den veralteten Projektordner in den Papierkorb legen. Löschen Sie alles nur dann, wenn ein globales Index- oder Build-Problem den Rebuild-Aufwand rechtfertigt.

Nicht verfügbare Simulator-Geräte haben einen eigenen Befehl. Sichern Sie vorher noch benötigte Testdaten dieser Geräte:

xcrun simctl delete unavailable

Dieser entfernt Geräteeinträge, deren Runtimes nicht verfügbar sind; er deinstalliert nicht die Runtime-Images selbst. Nutzen Sie Xcode > Settings > Components, um installierte Plattformen und Simulator-Runtimes mit ihren freigebbaren Größen zu prüfen, und entfernen Sie Runtimes, die Sie erneut herunterladen können. Apples Xcode-Komponenten-Leitfaden beschreibt denselben verwalteten Entfernungsweg. Nutzen Sie Window > Devices and Simulators für Geräteeinträge.

Prüfen Sie Archives unter Window > Organizer. Bewahren Sie Archiv und dSYM für jeden verteilten Build, einschließlich älterer Produktionsversionen, die noch im Einsatz sind. Apples Leitfaden zu Debugging-Informationen weist darauf hin, dass Binaries und dSYMs nur zusammen funktionieren, wenn ihre Build-UUIDs übereinstimmen. Auch DeviceSupport verdient eine gezielte Prüfung statt einer pauschalen Löschung.

Beenden Sie Xcode, bevor Sie DerivedData verschieben, damit Indizes und Build-Datenbanken nicht mitten im Schreiben sind. Erwarten Sie, dass der nächste Start und Build neu indexiert, Abhängigkeiten auflöst und Ausgaben neu erzeugt; die Dauer hängt vom Projekt und dem ab, was noch verfügbar ist.

Unter der Haube: reproduzierbare Daten und aufbewahrte Artefakte

DerivedData ist reproduzierbare Build- und Index-Ausgabe. Für jedes Projekt legt Xcode einen Ordner an, der mit einem Hash des Projektpfads benannt ist, und füllt ihn mit kompilierten Objekten, Modul-Caches, Indizes und Build-Produkten aus Quellcode, Einstellungen, Toolchains und Abhängigkeiten. Löschen Sie ihn, und Xcode baut neu, was noch verfügbar ist – das kann Zeit und Netzwerkzugang brauchen. DeviceSupport ist anders geartet: Wenn Sie ein physisches Gerät debuggen, erfasst Xcode Support- und Symbol-Daten für diesen OS-Build. Simulator-Geräte und Runtime-Images sind ebenfalls eigenständige verwaltete Objekte und keine gewöhnlichen Cache-Ordner. Archives sind die eine Menge, die es gezielt zu behalten lohnt, weil sie die dSYMs enthalten, die Sie brauchen, um Crash-Reports von App-Store-Builds zu symbolisieren. Zu wissen, was ein neu erstellbarer Cache und was ein erfasstes Artefakt ist, ist die ganze Grenze zwischen sicher-zu-löschen und behalten.

Wo eine Speicherübersicht hilft

Eine Speicherübersicht wie die Ansicht Analyse von Mole kann zeigen, ob DerivedData, CoreSimulator oder Archives der eigentliche Druckpunkt ist. Die Entfernung sollten die Xcode-Ansichten Components, Devices und Organizer übernehmen, weil sie Runtimes, Geräte und Release-Artefakte verstehen.

Eine sichere Reihenfolge

Beenden Sie laufende Builds, messen Sie Xcode und CoreSimulator getrennt, entfernen Sie veraltete DerivedData pro Projekt, löschen Sie nicht verfügbare Simulator-Geräte und deinstallieren Sie ungenutzte Runtimes unter Components. Prüfen Sie Archives gegen ausgelieferte Versionen und Symbolisierungsbedarf, bevor Sie sie entfernen. Öffnen Sie ein wichtiges Projekt erneut und starten Sie einen Build, bevor Sie den Papierkorb leeren.