Xcode DerivedData & Entwickler-Caches sicher löschen

Was DerivedData ist und warum es riesig wird

DerivedData ist der Ort, an dem Xcode alles aufbewahrt, 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 es unter ~/Library/Developer/Xcode/DerivedData, mit einem Unterordner für jedes Projekt und jeden Workspace, den du je geöffnet hast.

Es wächst aus einem strukturellen Grund: Xcode legt für jedes geöffnete Projekt einen DerivedData-Ordner an — auch für einmalige Klone, die du ein einziges Mal gebaut und nie wieder angefasst hast — und löscht keinen davon jemals. Jeder Ordner enthält separate Build-Produkte pro Konfiguration und Ziel (Debug und Release, Simulator und Gerät), sodass ein einzelnes mittelgroßes Projekt mehrere Gigabytes belegen kann und der Ordner insgesamt auf einer aktiven Entwicklermaschine häufig 20–50 GB erreicht.

Alles darin ist per Definition neu erzeugbar — genau das bedeutet „derived“. DerivedData zu löschen rührt weder deinen Quellcode noch deine Projekteinstellungen noch irgendetwas unter Versionskontrolle an. Der einzige Preis ist Zeit: Der nächste Build jedes Projekts ist ein kompletter Clean Build, und die Indizierung läuft ein paar Minuten im Hintergrund erneut.

DerivedData löschen

Es gibt drei Wege, und alle enden am selben Ort. Xcodes Befehl „Clean Build Folder“ (Product > Clean Build Folder oder Umschalt-Befehl-K) leert nur die Build-Produkte des aktuell geöffneten Projekts — nützlich gegen einen kaputten Build, aber am Speicherplatz ändert er kaum etwas. Um echten Platz zurückzugewinnen, löschst du die DerivedData-Ordner selbst.

Projektweise zu löschen ist die chirurgische Variante: Behalte DerivedData für die zwei, drei Projekte, die du täglich baust, und entferne die Ordner für alles andere. Alles auf einmal zu löschen ist die schnelle Variante, und auch das ist in Ordnung — du zahlst nur die Kosten des kompletten Neubaus bei jedem Projekt gleichzeitig.

1. Beende zuerst Xcode. DerivedData zu löschen, während Xcode läuft, kann den Indexer durcheinanderbringen, und Dateien, die Xcode geöffnet hat, werden womöglich nicht sauber gelöscht.
2. Finde den Ordner: Öffne 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 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 bewege sie in den Papierkorb. Erst in den Papierkorb zu verschieben ist die sicherere Gewohnheit — falls du es dir anders überlegst, holst du alles sofort zurück.
4. Alternativ vom Terminal aus: rm -rf ~/Library/Developer/Xcode/DerivedData löscht alles in einem Rutsch. Das ist bei sehr großen Ordnern schneller als der Finder — lies aber erst den Hinweis unten, bevor du es nutzt.
5. Öffne Xcode wieder und baue. Rechne damit, dass der erste Build jedes Projekts spürbar länger dauert und „Indexing“ eine Weile in der Aktivitätsleiste läuft — beides sind einmalige Kosten.

Vorsicht mit rm -rf: Es umgeht den Papierkorb und löscht endgültig, ohne Rückgängig. Tippe den Pfad exakt, führe es für diese Aufgabe nie mit sudo aus, und wenn du dich im Terminal nicht wohlfühlst, erledigt der Finder-Weg denselben Job umkehrbar.

Alte Simulator-Runtimes ausmisten

Simulatoren sind nach DerivedData meist der zweitgrößte Platzfresser der Entwicklung. Jede iOS-, watchOS- oder tvOS-Runtime, die du je geladen hast, belegt 5–8 GB, und jedes simulierte Gerät führt einen eigenen Datenordner unter ~/Library/Developer/CoreSimulator/Devices. Wer ein paar Xcode-Upgrades hinter sich hat, besitzt vermutlich Runtimes für iOS-Versionen, die er seit Jahren nicht mehr unterstützt.

Der schnellste Gewinn ist der eingebaute Aufräumbefehl: Führe xcrun simctl delete unavailable im Terminal aus. Er löscht jedes Simulator-Gerät, dessen Runtime nicht mehr installiert ist — die Waisen alter Xcode-Versionen — und rührt nichts an, was du noch nutzen kannst.

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

Einzelne simulierte Geräte stutzt du in Window > Devices and Simulators zurecht: Wechsle zum Tab „Simulators“, klicke mit der rechten Maustaste auf jedes Gerät, das du nie benutzt — die sechs doppelten iPhone-Modelle mit Daten aus alten Testläufen — und wähle „Delete“. Die gespeicherten Daten und Apps jedes Geräts verschwinden mit.

Archive, Device-Support-Dateien und Caches

Archive sammeln sich unter ~/Library/Developer/Xcode/Archives an — jedes Mal, wenn du Product > Archive ausführst, um einen Build zu verteilen. Jedes Archiv enthält einen kompletten App-Build plus seine dSYM-Debugsymbole, oft 100 MB bis 1 GB pro Stück. Kenne vor dem Löschen den Trade-off: Die dSYMs darin sind das, womit du Absturzberichte genau dieses Builds symbolizieren kannst. Behalte Archive für Versionen, die noch im App Store oder in TestFlight live sind (oder vergewissere dich, dass App Store Connect die dSYMs hat), und lösch den Rest — der sicherste Weg ist Xcodes 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 physischen 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ösch sie, und falls du je wieder ein Gerät mit dieser Version verbindest, 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 hält außerdem eigene Caches unter ~/Library/Caches/com.apple.dt.Xcode, und die Simulatoren halten ihre unter ~/Library/Developer/CoreSimulator/Caches — beide lassen sich gefahrlos leeren, wenn Xcode und die Simulator-App nicht laufen, und beide werden bei Bedarf neu aufgebaut.

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

Paketmanager behalten jede Abhängigkeit, die sie je geladen haben, damit künftige Installationen schnell gehen. Das ist gute Technik und schlechte Festplattenhygiene: Die Caches wachsen nur, und auf einer Maschine mit ein paar Jahren an Projekten summieren sie sich still auf 10–20 GB. Alle lassen sich gefahrlos leeren — im schlimmsten Fall lädt deine nächste Installation die Pakete neu herunter.

Der Swift Package Manager cacht geladene Pakete unter ~/Library/Caches/org.swift.swiftpm, und die aufgelösten Checkouts jedes Projekts liegen zusätzlich in dessen DerivedData-Ordner — wer DerivedData leert, leert die also gleich mit. Den geteilten Cache kannst du im Finder löschen oder mit rm -rf auf diesem Pfad.

CocoaPods hält seine geladenen Pods unter ~/Library/Caches/CocoaPods. Der saubere Weg, ihn zu leeren, ist der eingebaute 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 einer JavaScript-lastigen Maschine viele Gigabytes erreichen. Führe npm cache clean --force aus, um ihn zu leeren (npm besteht auf dem Flag, weil der Cache sich selbst heilt und normalerweise nie geleert werden muss — löschen ist trotzdem völlig sicher). pnpm-Nutzer führen stattdessen pnpm store prune aus.

Homebrew hortet alte Downloads und veraltete Paketversionen. brew cleanup entfernt veraltete Versionen und abgestandene Downloads; brew cleanup --prune=all leert zusätzlich den gesamten Download-Cache. Führe zuerst brew cleanup -n aus, wenn du eine Probeliste dessen willst, was verschwinden würde.

Automatisier es

Alles oben funktioniert, aber Entwicklermüll ist ein Laufband: DerivedData ist nach einer Woche normaler Arbeit zurück, Caches füllen sich neu, und jedes Xcode-Update strandet eine weitere Runtime. Wenn du nicht jeden Monat sechs manuelle Prozeduren wiederholen willst, ist dies der Teil, den es sich zu automatisieren lohnt — mit einem Tool, das seine Überlegungen zeigt, statt still massenhaft zu löschen.

AskClean behandelt Entwicklerdateien als Kategorien erster Klasse: Ein Scan schlüsselt Xcode DerivedData pro Projekt auf, alte Simulator-Runtimes (per simctl ausgelesen, die neueste je Plattform bleibt), Device-Support-Dateien und Paketmanager-Caches für npm, SwiftPM, cargo, uv und mehr. Es erwischt auch die neueren Platzfresser — Hugging-Face- und Ollama-Modell-Caches — die es pro Modell auflistet und standardmäßig nicht auswählt.

Jeder Eintrag kommt mit einer Erklärung — was es ist, ob es sich neu erzeugen lässt, was das Löschen kostet — und nichts läuft, bevor du es bestätigst. Löschungen landen im Papierkorb, sodass sich ein falscher Klick mit einem kurzen Drag-and-drop rückgängig machen lässt, und dein Quellcode, deine Dokumente und Fotos bleiben unangetastet. Es ist dieselbe Checkliste wie diese Anleitung — nur ohne die Stunde Terminal-Arbeit.

FAQ