Xcode DerivedData nimmt zu viel Platz auf dem Mac ein? Was du zuerst aufräumen solltest

Wenn du täglich Apps auf dem Mac baust, wird DerivedData irgendwann zu einem dieser Ordner, von denen du weißt, dass sie wichtig sind — aber von denen du auch hoffst, dass sie jemand anderes bereits aufgeräumt hat.

Dann eines Tages ist der Ordner riesig, die Festplatte knapp, Xcode fühlt sich schwerfälliger als sonst an, und die Cleanup-Frage wird dringend: Kannst du ihn sicher löschen, oder verwandelst du deinen Arbeitstag in Rebuild-Chaos?

Die kurze Antwort: DerivedData ist normalerweise eines der sichereren Xcode-Cleanup-Ziele. Die längere Antwort: Entwickler fokussieren sich oft zu sehr auf DerivedData und übersehen den Rest des Apple-Ökosystem-Footprints, der gleich daneben sitzt.

Kurzfassung

Was normalerweise sicher aufzuräumen ist und was Vorsicht erfordert

Was Xcode DerivedData eigentlich ist

DerivedData ist der Ort, an dem Xcode generierte Build-Ausgabe und zugehörige Arbeitsdaten für Entwicklungs-Workflows ablegt. Praktisch heißt das: Build-Produkte, Indexe, Zwischendateien, Preview-Ausgabe und andere generierte Artefakte, die Xcode beim nächsten Build oder Projekt-Öffnen schneller machen.

Deshalb wächst der Ordner so leicht. Jedes Projekt, Target, Branch, SDK und jeder Simulator-Workflow fügt mit der Zeit mehr generierten Zustand hinzu.

Das erklärt auch, warum Entwickler DerivedData anders behandeln als normale Projektdateien:

• es ist nicht die Source of Truth für deinen App-Code;
• es existiert, um Build- und Indexierungszeit zu sparen;
• es soll sich bei Bedarf neu aufbauen.

Dieses Regenerationsverhalten ist der Grund, warum DerivedData normalerweise als sichereres Cleanup-Ziel eingestuft wird als viele App- oder System-Pfade.

Warum Xcode DerivedData so groß wird

Die einfachste Antwort: Ansammlung.

Eine aktive App kann bereits viel Build-Ausgabe erzeugen. Mehrere Apps, mehrere Branches, Previews, Simulator-Läufe, Test-Builds und Package-Resolution-History können den Ordner viel weiter wachsen lassen, als die meisten Entwickler erwarten.

Typische Gründe, warum DerivedData anschwillt:

• mehrere aktive Projekte teilen sich dieselbe Maschine;
• veraltete projekt-spezifische Ordner bleiben lange nach dem Projekt bestehen;
• Preview-, Indexierungs- und simulator-intensive Arbeit erzeugt zusätzlichen Churn;
• langlebige Xcode-Umgebungen behalten alte Build-Ausgabe länger als gedacht;
• du räumst andere Dinge auf, aber berührst nie generierte Apple-Dev-Artefakte.

Der wichtige Punkt: Große DerivedData auf einem Entwickler-Mac sind nicht ungewöhnlich. Es wird erst zum Problem, wenn du annimmst, die richtige Antwort sei immer „alles sofort löschen”, ohne zu prüfen, was sonst noch groß ist und ob das Timing passt.

Was sonst in der Nähe von DerivedData groß wird

Entwickler machen oft DerivedData dafür verantwortlich, weil es bekannt ist. Aber es ist nur ein Profil im Apple-Ökosystem-Footprint.

StorageRadars aktuelle Apple-seitige Dev-Profile trennen diese Xcode-nahen Bereiche, weil sie nicht dasselbe Risikomodell haben:

Das ist der echte Grund, warum ein vollständiger Developer Folder-Scan nützlicher ist als Tunnelblick auf ein Verzeichnis. Wenn DerivedData 12 GB hat, aber CoreSimulator 35 GB und Archives 18 GB, ändert sich der Cleanup-Plan komplett.

Apple-Entwickler-Ordner, die oft mit DerivedData wachsen

Archives

Archives sind nicht nur generierter Zwischenraum. Sie können Lieferartefakte darstellen, die du tatsächlich behalten willst. Deshalb gehören sie in eine andere Cleanup-Kategorie als DerivedData.

CoreSimulator

Simulator-Daten können DerivedData leise überholen, besonders wenn du über viele Laufzeiten hinweg testest oder Simulator-Zustand lange behältst. Es ist nicht einfach ein wegwerfbarer Cache-Ordner. Er kann Simulator-Umgebungen enthalten, um die du dich noch kümmerst.

Wenn Simulator-Speicher das eigentliche Problem ist, geht die fokussierte Anleitung unter Xcode Simulator nimmt zu viel Platz auf dem Mac ein? Was du zuerst aufräumen solltest tiefer auf Laufzeiten, Device-Zustand und Cleanup-Kompromisse ein.

iOS DeviceSupport

Dieser Bereich wächst, wenn verschiedene physische Device-Versionen und Support-Dateien sich ansammeln. Er wird oft übersehen, weil er weniger bekannt ist als DerivedData, aber groß genug, um zu zählen.

Paketbezogene Caches

Das können sicherere Cleanup-Ziele sein als Simulator- oder Archive-Daten, aber sie sind trotzdem von DerivedData getrennt. Wenn du zurückgewinnbaren Platz ernsthaft suchst, behandle jedes Profil als eigenes Cleanup-Problem.

Wann selektives Aufräumen besser ist als alles löschen

Der Standard-Entwicklerreflex ist oft Total-Cleanup: ganzen Ordner löschen, Xcode neu aufbauen lassen, weitermachen.

Das kann in Ordnung sein, ist aber nicht immer der beste Zug.

Selektives Aufräumen ist meist besser, wenn:

• nur wenige alte Projekte für den Großteil der Größe verantwortlich sind;
• du schnelle, vorhersagbare Builds für deine aktuellen aktiven Apps brauchst;
• du keine vollständige Neu-Indexierung über alles erzwingen willst;
• du vermutest, dass veraltete Branches oder stillgelegte Workspaces das eigentliche Problem sind, nicht aktuelle Projekte.

Ein vollständiger Wipe ist sinnvoller, wenn:

• der gesamte Ordner über viele alte Projekte hinweg aufgebläht ist;
• du einen sauberen Reset der generierten Ausgabe willst;
• die aktuelle Verlangsamung ein kontrolliertes Rebuild-Fenster wert ist;
• du vermutest, dass globaler generierter Zustand Teil des Problems ist.

Das ist eigentlich eine Timing-Entscheidung, die als Speicherentscheidung getarnt ist. Die Platzersparnis mag ähnlich sein, aber die Workflow-Kosten sind unterschiedlich.

Wie du Xcode DerivedData aufräumst, ohne Rebuild-Chaos zu erzeugen

Das sichere Ziel ist nicht einfach „Platz freimachen”. Das sichere Ziel ist „den richtigen Platz freimachen und die nächsten Arbeitsstunden vorhersehbar halten”.

1. Zuerst das gesamte Entwickler-Bild überprüfen

Starte beim Developer Folder, falls verfügbar, nicht bei DerivedData isoliert. Der Punkt ist zu sehen, ob Xcode-Ausgabe wirklich das dominante Problem ist oder ob andere Apple-Dev-Profile größer sind.

Wenn der breitere Entwickler-Footprint das Problem ist, bringt Cleanup nur von DerivedData möglicherweise weniger als erwartet.

2. Sichere generierte Ausgabe von Vorsichts-Profilen trennen

Diese Unterscheidung ist wichtig:

• DerivedData und Caches sind normalerweise Safe-Cleanup-Ziele, weil sie generiert sind;
• Archives, CoreSimulator und iOS DeviceSupport verdienen mehr Vorsicht, weil sie Artefakte, Laufzeiten oder Zustand bewahren können, den du noch brauchst.

Sobald du diese vermischst, wird „Dev Cleanup” nur ein weiteres gefährliches Ordner-Löschen.

3. Bewusst zwischen selektivem und totalem Cleanup entscheiden

Bevor du etwas entfernst, beantworte diese Fragen:

1. Sind die größten DerivedData-Verzeichnisse an veraltete oder aktive Projekte gebunden?
2. Brauchst du heute schnelle Builds und Indexierung?
3. Sind benachbarte Profile tatsächlich größer als DerivedData?
4. Wird ein vollständiges Rebuild-Fenster deinen aktuellen Sprint, Demo oder Release stören?

Diese kurze Überprüfung verhindert die meisten unnötigen Full-Wipes.

4. Wiederherstellungskosten erwarten, keinen Datenverlust

Für DerivedData sind die normalen Cleanup-Kosten in der Regel:

• langsamerer nächster Build;
• Index-Neuaufbau;
• schwerere Previews oder Simulator-Startup;
• temporäre Reibung, während generierte Ausgabe zurückkehrt.

Das ist etwas ganz anderes als das Löschen von App-Support-Daten, Archives die du noch brauchst, oder Simulator-Zustand, der dir wichtig war. Dev Cleanup bleibt nur sicher, wenn du diese Kategorien getrennt hältst.

5. Einen Dev-Cleanup-Workflow nutzen, nicht generisches Datei-Löschen

Ein einfacher Dateibrowser kann dir sagen, dass etwas groß ist. Er kann dir nicht sagen, ob der Pfad ein bekanntes Dev-Profil ist, ob es im Safe- oder Caution-Bucket liegt, was die wahrscheinlichen Folgen sind oder ob ein geführtes Preflight vor dem Cleanup erforderlich ist.

Dieser fehlende Kontext ist der Grund, warum Dev Cleanup nicht zu normalem „größte Dateien”-Cleanup zusammenfallen sollte, wenn die Anforderungen steigen.

Warum Xcode-Cleanup anders ist als normales Datei-Cleanup

Normales Datei-Cleanup stellt eine einfache Frage: Was ist groß?

Wenn du die breitere Anleitung über Xcode, Docker, SDK-intensive Setups und Entwickler-Risikoprofile brauchst, lies Entwickler-Caches auf dem Mac sicher aufräumen.

Dev Cleanup muss härtere Fragen stellen:

• ist das generiert oder nutzerautorisiert;
• ist das Profil Safe, Caution oder Dangerous;
• brauche ich Dry Run, bevor ich der zurückgewinnbaren Größe vertraue;
• brauche ich Guided Preflight, weil das Profil Workflow-Risiko hat;
• welche Blocker, Warnungen oder Folgen sollte ich zuerst überprüfen?

Dieser Unterschied ist in StorageRadars Dev Cleanup-Modell eingebaut. Es arbeitet nicht als beliebiges Löschen. Es arbeitet mit bekannten Entwickler-Profilen und einer Risikorichtlinie.

Die aktuellen Apple-Dev-Profile teilen zum Beispiel auf:

• Xcode DerivedData als Safe;
• Xcode Archives als Caution;
• CoreSimulator Data als Caution;
• iOS DeviceSupport als Caution;
• SwiftPM Cache als Safe.

Das ist das Gegenteil von Cleanup-Chaos. Es ist ein ökosystembewusster Workflow, der generierte Caches anders behandelt als beibehaltene Artefakte und Simulator-Zustand.

Wo StorageRadar passt

Das verändert den praktischen Workflow:

• nutze Developer Folder, wenn der gesamte Apple-Entwickler-Bereich aufgebläht sein könnte;
• nutze Dev Cleanup, wenn du profilbewusstes Cleanup statt normalem Datei-Löschen willst;
• halte Safe-Profile wie DerivedData getrennt von Caution-Profilen wie Archives und Simulator-Speicher.

Diese Unterscheidung ist der ganze Wert für eine Entwickler-Maschine. Das Produkt sagt dir nicht nur, dass ein Ordner groß ist. Es sagt dir, welche Art von Entwicklerspeicher es ist und welche Art von Cleanup-Prozess es verdient.

Was du nicht tun solltest

Vermeide diese häufigen Fehler:

• nimm nicht an, DerivedData sei der einzige Xcode-Ordner, der sich lohnt zu prüfen;
• lösche nicht Archives, CoreSimulator und iOS DeviceSupport, als hätten sie dasselbe Risikoprofil;
• mach keinen vollständigen Reset direkt vor einer Deadline, wenn Rebuild-Zeit wichtig ist;
• nutze nicht allein größte-Datei-Logik für Entwickler-Artefakte, die Ökosystem-Kontext brauchen;
• verwechseln nicht generierte Build-Ausgabe mit Projektdaten, Lieferartefakten oder beibehaltenem Simulator-Zustand.

Wenn Apple-Dev-Artefakte auch System Data verdächtig groß aussehen lassen, ist die Begleitanleitung zu Mac System Data zu groß der richtige nächste Lesestoff.

Fazit

Wenn DerivedData zu viel Platz auf deinem Mac einnimmt, ist die beruhigende Nachricht: Es ist normalerweise eines der sichereren Xcode-Cleanup-Ziele, weil es generierte Ausgabe ist. Der weniger offensichtliche Teil: DerivedData ist selten die ganze Geschichte.

Die beste Cleanup-Entscheidung kommt davon, den breiteren Entwickler-Footprint zu überprüfen, Safe-Profile von Caution-Profilen zu trennen und selektives oder totales Cleanup basierend auf deinem aktuellen Workflow statt Panik zu wählen.