Mac-Speicher voll: Systemdaten und Entwicklerordner aufschlüsseln

Die Meldung kommt selten zu einem guten Zeitpunkt: Das Startvolume ist fast voll, ein Xcode-Update bricht mangels Platz ab, oder ein Build scheitert, weil keine temporären Dateien mehr geschrieben werden können. Wer mit Xcode, Node oder Docker arbeitet, sucht die Ursache oft zuerst in Downloads und Dokumenten. Die großen Posten liegen aber meist woanders: in Ordnern, die Entwicklerwerkzeuge selbst anlegen und die der Finder standardmäßig gar nicht zeigt.

Diese Seite hilft dir, die Speicheranzeige von macOS richtig zu lesen, die typischen Wachstumszonen auf einem Entwickler-Mac zu finden und jeden Posten einer von drei Gruppen zuzuordnen: löschen, verlegen oder dem zuständigen Werkzeug überlassen. Erst mit dieser Einordnung wird aus hektischem Aufräumen ein Plan, der länger hält als bis zum nächsten Build.

Was die Speicheranzeige zeigt – und was nicht

In aktuellen macOS-Versionen findest du die Übersicht unter Systemeinstellungen → Allgemein → Speicher. macOS teilt die belegte Kapazität dort in Kategorien auf, etwa Programme, Dokumente, Fotos und Systemdaten. Seit macOS Monterey heißt die frühere Sammelkategorie „Andere“ nun „Systemdaten“. Darin landet vieles, was sich keiner anderen Kategorie zuordnen lässt: Caches, Protokolle, lokale Snapshots, Festplattenabbilder virtueller Maschinen, Daten in App-Containern und Reste alter Installationen. Je nach macOS-Version und installierten Werkzeugen zeigt die Übersicht zusätzlich eine eigene Kategorie für Entwicklerdaten.

Die Übersicht ist eine Zusammenfassung, keine Entscheidungsgrundlage. Sie sagt dir, dass viel Platz in den Systemdaten steckt, aber nicht, ob es sich um einen löschbaren Cache, ein Docker-Abbild oder die Daten eines Simulators handelt. Für eine Entscheidung brauchst du den Blick in die konkreten Ordner. Genau dort unterscheiden sich Entwickler-Macs deutlich von Geräten, auf denen vor allem Fotos, Mails und Dokumente liegen.

Die typischen Wachstumszonen auf einem Entwickler-Mac

Nicht jeder dieser Ordner existiert auf jedem Mac, und die Größen schwanken stark. Ein Mac, der seit Jahren mit wechselnden Xcode-Versionen, vielen Branches und mehreren Simulator-Plattformen arbeitet, sammelt deutlich mehr an als ein frisch eingerichteter. Genau deshalb lohnt sich das Messen, bevor du etwas löschst oder verschiebst.

So misst du selbst

Der Befehl du zeigt, wie viel Platz ein Ordner tatsächlich belegt, und verändert dabei nichts. Mit du -sh ~/Library/Developer/* siehst du die Unterordner von Xcode und Simulator auf einen Blick, mit du -sh ~/Library/Developer/Xcode/* gehst du eine Ebene tiefer. Für den npm-Cache genügt du -sh ~/.npm, für Docker Desktop du -sh ~/Library/Containers/com.docker.docker. Beim Zugriff auf manche Bereiche fragt macOS nach einer Berechtigung für das Terminal. Das ist normal und schützt die Daten anderer Apps.

Notiere dir die Werte. Wiederholst du dieselbe Messung ein paar Wochen später, erkennst du, welche Ordner schnell wachsen. Diese Wachstumsrate ist oft aufschlussreicher als die absolute Größe. Sie entscheidet, ob einmaliges Aufräumen reicht oder ob ein Ordner dauerhaft einen anderen Platz braucht.

Drei Gruppen: löschen, verlegen, dem Werkzeug überlassen

Regenerierbares darfst du löschen. DerivedData, Paket-Caches und die node_modules ruhender Projekte entstehen beim nächsten Build oder der nächsten Installation neu. Der Preis ist Zeit: Der erste Build danach dauert länger, und Pakete werden erneut geladen. Beende Xcode und andere beteiligte Programme, bevor du solche Ordner entfernst.

Großes, das du brauchst, kannst du verlegen. Projektordner, Archive mit Debug-Symbolen und Medienbibliotheken lassen sich nicht einfach neu erzeugen. Hier hilft kein Löschen, sondern ein Umzug auf eine dauerhaft angeschlossene externe SSD. Auch DerivedData kann in diese Gruppe fallen, wenn du ständige Neuaufbauten vermeiden willst. Was dabei für Xcode im Einzelnen gilt, beschreibt die Seite Xcode-Speicher: DerivedData löschen oder verlegen.

Werkzeug-Verwaltetes bleibt beim Werkzeug. Simulator-Runtimes und das Festplattenabbild von Docker Desktop werden von eigenen Diensten verwaltet. Dafür gibt es Einstellungen in Xcode und Docker Desktop; ein roher Ordnerumzug ist hier der falsche Weg. Warum das so ist und wie du dort sauber Platz schaffst, erklärt der Beitrag Simulatoren und Docker.raw sauber verlagern.

Lokale Time-Machine-Snapshots und viele Systemcaches verwaltet macOS selbst und gibt sie in der Regel frei, wenn der Platz knapp wird. Ein Teil der Systemdaten verschwindet deshalb ohne dein Zutun wieder, ein anderer Teil wächst bei nächster Gelegenheit nach.

Warum Aufräumen allein oft nicht reicht

Wer regelmäßig DerivedData und Caches löscht, gewinnt kurzfristig Platz. Nach ein paar Builds ist er wieder belegt, denn die Werkzeuge legen genau diese Daten erneut an. Auf einem Mac mit kleiner interner SSD wird Aufräumen so zur Routine, die Zeit kostet und trotzdem knapp bleibt. Wie viel Speicher für welchen Arbeitsalltag realistisch ist, beschreibt die Seite Reichen 256 GB zum Entwickeln?.

Der nachhaltigere Weg trennt zwischen dem, was wirklich weg kann, und dem, was nur nicht auf der internen SSD liegen muss. Letzteres bekommt einen festen Platz auf einer externen SSD, die zu deinem Arbeitsplatz gehört. Das setzt voraus, dass die SSD dort dauerhaft angeschlossen bleibt und dass du sie in dein Backup einbeziehst. Eine SSD, die mal dranhängt und mal in der Tasche steckt, taugt für ausgelagerte Arbeitsordner nicht.

Wo DevSpace Manager ansetzt

DevSpace Manager ist eine macOS-App von BRUNIQO für die mittlere Gruppe: große Arbeitsordner, die du brauchst, die aber nicht auf der internen SSD liegen müssen. Typische Kandidaten sind Xcode DerivedData, Xcode-Archive, SwiftPM- und Node-Caches, node_modules, lokale Medienbibliotheken und große Projektordner. Die App kopiert zunächst in einen Staging-Bereich auf der SSD, vergleicht Quelle und Ziel vollständig und schaltet erst danach um. Das Original bleibt als Quarantäne für einen möglichen Rollback erhalten. Der Platz auf der internen SSD wird deshalb erst frei, wenn du die Freigabe gesondert bestätigst.

Simulator-Runtimes und Docker.raw verschiebt DevSpace Manager bewusst nicht direkt, Netzwerklaufwerke und interne Ziele sind ebenfalls ausgeschlossen. Die Ziel-SSD sollte dauerhaft angeschlossen bleiben, und die Auslagerung ersetzt kein unabhängiges Backup. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht.