# Xcode aufräumen, ohne Release-Artefakte zu verlieren > DerivedData, Simulator-Geräte, Runtimes, DeviceSupport und Release-Archive trennen, bevor Xcode-Speicher freigegeben wird. Published: 2026-07-12 | Updated: 2026-08-08 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** erledigen Sie am besten pro Projekt. Beenden Sie Xcode, öffnen Sie **Xcode > Settings > Locations**, um Derived Data anzuzeigen, identifizieren Sie den veralteten Projektordner und legen Sie ihn in den Papierkorb. 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: ``` 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](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) 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](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) 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: warum DerivedData sicher ist und DeviceSupport etwas anderes 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.
Der Xcode-Developer-Ordner aufgeteilt in neu erzeugbare Caches, DerivedData und Module Cache, sowie festgehaltene Artefakte: DeviceSupport, Archives und Simulatoren
Xcodes Speicherbedarf teilt sich in reproduzierbare Ausgaben und erfasste Artefakte. Archives und dSYMs können lange nach dem Ausliefern eines Builds noch operativ wichtig bleiben.
## Wo eine Speicherübersicht hilft Eine Speicherübersicht wie die Analyze-Ansicht von [Mole](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/de/blog/how-to-clean-up-xcode-mac Blog index for agents: https://mole.fit/de/blog/llms.txt Site index for agents: https://mole.fit/llms.txt