Xcode DerivedData & Entwickler-Caches sicher löschen

Was DerivedData ist und warum es so groß wird

In DerivedData legt Xcode alles ab, was es aus deinem Quellcode ableitet: Zwischenobjekte des Builds, kompilierte Produkte, Modul-Caches, Symbolindizes für Codevervollständigung und Jump to Definition sowie Build-Logs. Standardmäßig liegt der Ordner unter ~/Library/Developer/Xcode/DerivedData, mit einem Unterordner für jedes Projekt und jeden Workspace, den du je geöffnet hast.

Dass er wächst, hat einen strukturellen Grund: Xcode legt für jedes Projekt, das du öffnest, einen DerivedData-Ordner an – auch für einmalige Klone, die du ein einziges Mal gebaut und nie wieder angefasst hast – und entfernt diese Ordner nicht von sich aus. Jeder Ordner enthält getrennte Build-Produkte pro Konfiguration und Ziel (Debug und Release, Simulator und Gerät). Miss deshalb die Projekt-Unterordner, statt zu schätzen, wie viel Platz dein Mac zurückbekommt.

Alles darin lässt sich per Definition neu erzeugen – genau das bedeutet „derived“ (abgeleitet). Wenn du DerivedData löschst, bleiben dein Quellcode, deine Projekteinstellungen und alles unter Versionskontrolle unangetastet. Der einzige Preis ist Zeit: Der nächste Build jedes Projekts ist ein kompletter Clean Build, und die Indizierung läuft ein paar Minuten lang erneut im Hintergrund.

DerivedData löschen

Der Xcode-Befehl Clean Build Folder (Product > Clean Build Folder oder Umschalt-Befehl-K) entfernt nur die Build-Produkte des gerade geöffneten Projekts – nützlich gegen einen seltsamen Build-Fehler, am Speicherplatz ändert er aber kaum etwas. Um wirklich Platz zurückzugewinnen, löschst du die DerivedData-Ordner selbst: Du öffnest sie über die Locations-Einstellungen von Xcode oder direkt im Finder oder entfernst sie im Terminal. Alle drei Wege führen zum selben Ergebnis.

Projektweise zu löschen ist die gezielte Variante: Behalte DerivedData für die zwei, drei Projekte, die du täglich baust, und entferne die Ordner aller anderen. Alles auf einmal zu löschen ist die schnelle Variante und ebenfalls in Ordnung – du zahlst dann eben bei allen Projekten gleichzeitig mit einem kompletten Neubau.

1. Beende zuerst Xcode. Löschst du DerivedData, während Xcode läuft, kann das den Indexer durcheinanderbringen, und Dateien, die Xcode geöffnet hat, lassen sich womöglich nicht sauber löschen.
2. Öffne den Ordner: Wähle in Xcode Settings > Locations und klicke auf den kleinen Pfeil neben dem DerivedData-Pfad, um ihn im Finder anzuzeigen. Oder drücke im Finder Umschalt-Befehl-G („Gehe zu Ordner“) und gib ~/Library/Developer/Xcode/DerivedData direkt ein.
3. Sortiere die Projekt-Unterordner nach Größe, wähle die aus, die weg sollen (oder mit Befehl-A alle), und lege sie in den Papierkorb. Der Umweg über den Papierkorb ist die sicherere Gewohnheit: Überlegst du es dir anders, holst du alles sofort zurück.
4. Alternativ im Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData löscht alles in einem Rutsch. Bei sehr großen Ordnern ist das schneller als der Finder – lies aber zuerst den Hinweis unten.
5. Öffne Xcode wieder und starte einen Build. Rechne damit, dass der erste Build jedes Projekts spürbar länger dauert und „Indexing“ eine Weile in der Statusanzeige oben im Xcode-Fenster läuft – beides kostet nur einmal Zeit.

Vorsicht mit rm -rf: Der Befehl umgeht den Papierkorb und löscht endgültig – rückgängig machen lässt sich das nicht. Gib den Pfad exakt ein, führe den Befehl für diese Aufgabe nie mit sudo aus, und wenn du dich im Terminal unsicher fühlst, erreichst du über den Finder dasselbe, nur umkehrbar.

Alte Simulator-Runtimes ausmisten

Simulatoren sind oft eine weitere große Kategorie im Entwicklerspeicher. Jede geladene iOS-, watchOS- oder tvOS-Runtime belegt eigenen Platz, und jedes simulierte Gerät speichert Daten unter ~/Library/Developer/CoreSimulator/Devices. Hast du schon einige Xcode-Upgrades hinter dir, prüfe die Runtimes von OS-Versionen, die nicht mehr zu deiner Testmatrix gehören.

Am schnellsten hilft der eingebaute Aufräumbefehl: Führe im Terminal xcrun simctl delete unavailable aus. Er löscht alle als „unavailable“ markierten Simulatorgeräte – meist verwaiste Geräte entfernter Runtimes und alter Xcode-Versionen – samt den Apps und Daten darin. Prüfe die Liste vorher mit xcrun simctl list devices, besonders wenn du mehr als eine Xcode-Version installiert hast.

Für die Runtimes selbst öffnest du in Xcode Settings > Components (in Xcode 14–15 hieß der Bereich „Platforms“). Dort siehst du jede installierte Simulator-Runtime mit ihrer Größe; wähle eine alte aus und lösche sie. Behalte pro Plattform nur die neueste Runtime, außer du testest aktiv auf älteren OS-Versionen.

Einzelne simulierte Geräte entfernst du unter Window > Devices and Simulators: Wechsle zum Tab „Simulators“, klicke mit der rechten Maustaste auf jedes Gerät, das du nie benutzt – etwa die sechs doppelten iPhone-Modelle mit Daten aus alten Testläufen – und wähle „Delete“. Die gespeicherten Daten und Apps des Geräts werden dabei mitgelöscht.

Archives, Device-Support-Dateien und Caches

Archive sammeln sich unter ~/Library/Developer/Xcode/Archives an – jedes Mal, wenn du mit Product > Archive einen Build zur Verteilung erstellst. Jedes Archiv enthält einen kompletten App-Build samt dSYM-Debugsymbolen, oft 100 MB bis 1 GB pro Stück. Bedenke vor dem Löschen den Preis: Mit den dSYMs darin symbolisierst du Absturzberichte genau dieses Builds. Behalte Archive für Versionen, die noch im App Store oder in TestFlight verfügbar sind (oder vergewissere dich, dass App Store Connect die dSYMs hat), und lösche den Rest – am sichersten im Xcode Organizer (Window > Organizer > Archives), wo du sie mit Kontext prüfen und löschen kannst.

iOS DeviceSupport unter ~/Library/Developer/Xcode/iOS DeviceSupport enthält Debugging-Symbole, die Xcode von jedem echten iPhone oder iPad kopiert, das du je angeschlossen hast – ein Ordner pro iOS-Version, typischerweise je 2–5 GB. Ordner für iOS-Versionen, die keines deiner Geräte mehr nutzt, sind reiner Ballast: Lösche sie. Verbindest du später doch wieder ein Gerät mit dieser Version, kopiert Xcode die Symbole einfach erneut (du siehst dann einmal „Preparing debugger support“). Entsprechende Ordner gibt es auch für watchOS- und tvOS-Geräte.

Xcode legt außerdem eigene Caches unter ~/Library/Caches/com.apple.dt.Xcode an, die Simulatoren ihre unter ~/Library/Developer/CoreSimulator/Caches. Beide werden bei Bedarf neu aufgebaut. Leere sie aber nur, während Xcode und die Simulator-App beendet sind, und lass Cache-Dateien in CoreSimulator, die du nicht zuordnen kannst, unangetastet.

Paketmanager-Caches (SwiftPM, CocoaPods, npm, Homebrew)

Paketmanager heben heruntergeladene Abhängigkeiten auf, damit künftige Installationen schnell gehen. Das ist nützlich, kann sich auf einem Rechner mit jahrelanger Projektarbeit aber trotzdem zu einer großen Speicherkategorie auswachsen. Diese Download-Caches lassen sich neu aufbauen, doch die nächste Installation muss die Pakete dann erneut herunterladen.

Der Swift Package Manager speichert heruntergeladene Pakete unter ~/Library/Caches/org.swift.swiftpm, und die aufgelösten Checkouts jedes Projekts liegen zusätzlich in dessen DerivedData-Ordner – wenn du DerivedData leerst, sind diese also schon mit entfernt. Den gemeinsamen Cache kannst du im Finder löschen oder mit rm -rf auf genau diesen Pfad.

CocoaPods legt heruntergeladene Pods unter ~/Library/Caches/CocoaPods ab. Am saubersten leerst du diesen Cache mit dem eingebauten Befehl pod cache clean --all. Die Pods-Ordner deiner Projekte bleiben unberührt; nur der Download-Cache verschwindet.

Der npm-Cache liegt unter ~/.npm und kann auf einem Rechner mit viel JavaScript-Arbeit etliche Gigabyte erreichen. Führe npm cache clean --force aus, um ihn zu leeren (npm besteht auf dem Flag, weil sich der Cache selbst repariert und normalerweise nie geleert werden muss; das Löschen ist trotzdem sicher – die Pakete werden bei der nächsten Installation einfach erneut heruntergeladen). Mit pnpm führst du stattdessen pnpm store prune aus.

Homebrew hortet alte Downloads und veraltete Paketversionen. brew cleanup entfernt veraltete Versionen und alte Downloads, und ein globaler Durchlauf deinstalliert außerdem Abhängigkeiten, die nichts mehr braucht (sofern HOMEBREW_NO_AUTOREMOVE nicht gesetzt ist); brew cleanup --prune=all leert zusätzlich den gesamten Download-Cache. Führe zuerst brew cleanup -n aus, wenn du vorab sehen willst, was entfernt würde.

Das Aufräumen automatisieren

Das alles funktioniert – nur hört es nie auf: DerivedData ist nach einer Woche normaler Arbeit wieder da, Caches füllen sich neu, und jedes Xcode-Update lässt eine weitere Runtime zurück. Wenn du nicht jeden Monat sechs Abläufe von Hand wiederholen willst, lohnt sich genau hier die Automatisierung – mit einem Tool, das seine Gründe offenlegt, statt stillschweigend massenhaft zu löschen.

AskClean behandelt Entwicklerdateien als eigene Kategorien: Ein Scan schlüsselt Xcode DerivedData pro Projekt auf, dazu alte Simulator-Runtimes (per simctl ausgelesen; die neueste je Plattform bleibt erhalten), Device-Support-Dateien und Paketmanager-Caches für npm, SwiftPM, cargo, uv und weitere. Auch die neueren Platzfresser erfasst AskClean – lokale KI-Modelle: Hugging-Face-Modelle listet es einzeln auf, die Ollama-Modellbibliothek als einen einzigen Eintrag; standardmäßig ist nichts davon ausgewählt.

Zu jedem Eintrag gibt es eine Erklärung – was er ist, ob er sich neu erzeugen lässt und was das Löschen kostet –, und nichts passiert, bevor du bestätigst. Bestätigte Einträge werden endgültig gelöscht und nicht in den Papierkorb gelegt; prüfe deshalb jede Auswahl, bevor du bestätigst. Dein Quellcode und deine Fotomediathek werden nie angerührt. Es ist dieselbe Checkliste wie in dieser Anleitung – nur ohne die Stunde im Terminal.

Was sich neu erzeugen lässt – und was nicht

Diese Tabelle zeigt, wo die Löschgrenzen liegen; sie verspricht keine bestimmte Ersparnis. Miss deinen Mac vor und nach jedem Schritt – das rein lesende Prüfskript aus der Anleitung zum Speicher der Xcode-Simulatoren listet diese Ordner auf, ohne etwas zu verändern.

FAQ