Xcode: Clean Build Folder oder DerivedData löschen?
AskClean-Team · Aktualisiert 2026-11-02
Clean Build Folder entfernt die Build-Produkte des Schemas, das du gerade geöffnet hast. Wenn du DerivedData löschst, setzt du deutlich mehr zurück: Build-Produkte plus Indizes, Modul-Caches und Logs. Bei einem kaputten Build beginnst du mit Clean Build Folder, bei einem beschädigten Index löschst du den DerivedData-Ordner dieses einen Projekts, und um wirklich Speicher freizugeben, löschst du die DerivedData-Ordner von Projekten, die du nicht mehr baust.
Der Unterschied liegt im Umfang, nicht in der Gründlichkeit
Product > Clean Build Folder (Umschalt-Befehl-K) wirkt innerhalb des Projekts und Schemas, das du gerade geöffnet hast. Der Befehl verwirft die kompilierten Produkte und Zwischendateien für diesen Kontext, sodass der nächste Build wieder beim Quellcode beginnt. Er ist auf ein Projekt beschränkt und behält bewusst alles, dessen Neuaufbau teuer wäre.
DerivedData ist das übergeordnete Verzeichnis, das sich alle Projekte mit dem Standardspeicherort teilen: ~/Library/Developer/Xcode/DerivedData, mit einem Unterordner für jedes Projekt und jeden Workspace, den du je geöffnet hast. Löschst du einen Unterordner, setzt du genau dieses Projekt zurück. Löschst du das ganze Verzeichnis, muss jedes deiner Projekte beim nächsten Öffnen neu gebaut und neu indiziert werden.
Ehrlich beschrieben stehen sich hier also nicht „leichte“ und „gründliche“ Reinigung gegenüber. Clean Build Folder ist eng und günstig; DerivedData zu löschen ist breit und kostet dich den Index. Welcher Weg richtig ist, hängt allein davon ab, ob das, was kaputt ist, in den Build-Produkten steckt oder außerhalb davon.
Wenn ein Build kaputtgeht: eng anfangen
Tritt der Fehler direkt nach einem Branch-Wechsel, einer geänderten Build-Konfiguration oder bearbeiteten Ressourcendateien auf, beende die laufende App und nutze zuerst Clean Build Folder. Das ist der günstigste Reset, den es gibt: Der Index bleibt erhalten, und du bist nach einem einzigen Build wieder arbeitsfähig – nicht erst nach einem Build plus mehreren Minuten Indizierung.
Lösche den DerivedData-Ordner dieses Projekts erst, wenn die Symptome nicht wirklich mit Build-Produkten zu tun haben: Xcode zeigt Fehler für Code an, den du längst korrigiert hast, Jump to Definition landet an der falschen Stelle, oder die Codevervollständigung versteht deine eigenen Typen nicht mehr. Das sind Index-Symptome, und den Index rührt Clean Build Folder nicht an.
Einen Sonderfall solltest du kennen, denn er ist der übliche Grund, warum aus „Ich habe bereinigt, es hat nichts gebracht“ ein „Ich habe DerivedData gelöscht, und es lief wieder“ wird: Der Cache für vorkompilierte Module (ModuleCache.noindex) liegt im Wurzelverzeichnis von DerivedData, nicht im Unterordner eines Projekts. Clean Build Folder erreicht ihn nie. Veraltet dieser Modul-Cache nach einem Wechsel von SDK oder Toolchain, verschwindet der Fehler erst, wenn du ihn entfernst.
Keiner der beiden Befehle behebt einen echten Fehler in deinem Quellcode oder deinen Abhängigkeiten. Bleibt nach einem Clean Build exakt derselbe Fehler bestehen, hör auf zu bereinigen und lies die Compiler-Meldung – die Ursache liegt dann in den Projekteinstellungen, in Package.resolved, im ausgewählten SDK oder im Code selbst.
Beides ist kein Weg, um Speicher freizugeben
Clean Build Folder ist ein Diagnosewerkzeug, das nebenbei ein paar Bytes freigibt. Es kann Platz für das aktuelle Projekt zurückholen, doch die Build-Produkte aller anderen Projekte, sämtliche Indizes und der Modul-Cache bleiben genau, wo sie waren. Wer den Befehl ausführt, um Speicher zurückzugewinnen, setzt am falschen Ende an.
Geht es dir tatsächlich um Platz, geh umgekehrt vor: Miss zuerst die DerivedData-Unterordner und lösche dann die Unterordner der Projekte, die du seit Monaten nicht geöffnet hast. Dort stecken meist die Dutzende Gigabyte: Klone, die du ein einziges Mal gebaut und nie wieder angefasst hast.
Fang nicht mit rm -rf an. Im Finder kannst du die ausgewählten Ordner in den Papierkorb legen; dort bleiben sie wiederherstellbar, bis du ihn leerst. Dieser Unterschied zählt spätestens dann, wenn du zum ersten Mal den Ordner eines Projekts löschst, das gerade baut. Das Terminal lohnt sich für Automatisierung – aber erst, wenn du den genauen Pfad geprüft hast.
Das Ergebnis prüfen, statt einer Zahl zu vertrauen
Notiere die Größe von DerivedData, bevor du irgendetwas tust, wende genau eine der beiden Optionen an und miss danach erneut. Nach Clean Build Folder baust du das aktuelle Schema. Nach dem Löschen eines DerivedData-Ordners öffnest du Xcode und wartest, bis der erste Build und die Indizierung abgeschlossen sind.
In dieser Reihenfolge trennst du den zurückgewonnenen Platz von dem Preis, den du dafür zahlst. Eine allgemeingültige Zahl gibt es nicht: Das Ergebnis hängt davon ab, wie viele Projekte, Konfigurationen und Architekturen auf genau diesem Mac gebaut wurden.
Was du wann tust
| Situation | Was du tust | Was es kostet |
|---|---|---|
| Der Build schlägt im aktuellen Schema fehl | Product > Clean Build Folder | Ein Neubau dieses Projekts. Die Indizes aller Projekte bleiben erhalten. |
| Veraltete Fehler, Jump to Definition springt falsch | ~/Library/Developer/Xcode/DerivedData/<project> | Kompletter Neubau plus Neuindizierung – nur für dieses Projekt. |
| Fehler bleiben nach einem SDK-Wechsel trotz Clean Build Folder | ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex | Module werden beim nächsten Build neu kompiliert. Clean Build Folder erreicht diesen Ordner nicht. |
| Du brauchst tatsächlich Speicherplatz | ~/Library/Developer/Xcode/DerivedData | Lösche die großen, veralteten Unterordner; diese Projekte werden beim nächsten Öffnen neu gebaut. |
| Alte Simulator-Runtimes | Xcode Settings > Components | Eine ganz eigene Kategorie. Keiner der beiden Befehle berührt sie. |
Die Tabelle beschreibt den Umfang, keine versprochene Zahl an Gigabyte. Miss deinen eigenen Mac vorher und nachher.
FAQ
Löscht Clean Build Folder DerivedData?
Nein. Der Befehl entfernt die Build-Produkte des Projekts und Schemas, das du geöffnet hast. Das ist nicht dasselbe, wie das gemeinsame DerivedData-Verzeichnis zu löschen, in dem auch die Indizes, der Modul-Cache und die Logs aller Projekte liegen.
Ist es sicher, den DerivedData-Ordner eines Projekts zu löschen?
Ja. Alles darin ist aus deinem Quellcode abgeleitet, und Xcode erzeugt es neu. Dein Code und deine Git-Historie bleiben unberührt. Der einzige Preis: Der erste Build danach ist ein kompletter Build, gefolgt von einer Indizierung.
Muss ich Xcode vorher beenden?
Wenn du DerivedData von Hand löschst, ja – sonst hält der Indexer womöglich Dateien fest oder legt sie neu an, während du sie entfernst. Für den eingebauten Befehl Clean Build Folder nicht; den führt Xcode an sich selbst aus.
Warum ist der Fehler nach dem Bereinigen immer noch da?
Höchstwahrscheinlich lag die Ursache nie im Cache. Prüfe die Compiler-Meldung, die Schema-Einstellungen, die Versionen deiner Abhängigkeiten, Package.resolved, das ausgewählte SDK und was sich in deinem aktuellen Branch tatsächlich geändert hat.
Clean Build Folder hat nichts gebracht, DerivedData zu löschen schon. Warum?
Meist wegen des Caches für vorkompilierte Module. ModuleCache.noindex liegt im Wurzelverzeichnis von DerivedData statt in einem Projektunterordner. Clean Build Folder kommt deshalb nicht daran heran – das Löschen von DerivedData schon.
Quellen