Mac-Speicher voll: wo die Gigabyte wirklich stecken
„Der Speicher deines Mac ist fast voll“ — und im Finder findest du nichts. Die zwölf Orte, an denen der Platz tatsächlich liegt, wie groß sie typischerweise sind und was du bei jedem davon gefahrlos zurückbekommst.
Der Hinweis kommt immer im falschen Moment: „Der Speicher deines Mac ist fast voll.“ Du öffnest den Finder, siehst einen Benutzerordner mit vielleicht 40 GB — und die Systemeinstellungen behaupten, 900 von 1000 GB seien belegt. Der Unterschied liegt an Orten, die der Finder standardmäßig nicht zeigt.
Das hier ist die Landkarte dieser Orte, in der Reihenfolge, in der sie sich auf einem Arbeitsrechner lohnen.
Warum „System-Daten“ so groß ist
Die Kategorie heißt bei Apple Systemdaten und ist keine Kategorie, sondern ein Rest: alles, was macOS keiner anderen Rubrik zuordnen konnte. Darin steckt regelmäßig:
- Caches von Programmen unter
~/Library/Cachesund/Library/Caches - Container von Sandbox-Apps unter
~/Library/Containers - Lokale APFS-Snapshots von Time Machine, die auf der internen Platte zwischengelagert werden
- Protokolle und Diagnoseberichte unter
~/Library/Logs - Entwicklerkram, wenn irgendwann einmal Xcode oder Docker installiert war
Kein einziger dieser Orte taucht auf, wenn du in deinem Benutzerordner nach großen Dateien suchst. Deshalb fühlt sich der volle Mac wie ein Rätsel an — die Daten sind nicht versteckt, sie sind nur nicht dort, wo man sucht.
Die zwölf Orte, sortiert nach Ertrag
| Ort | Typisch | Kommt zurück? |
|---|---|---|
~/Library/Developer/Xcode/DerivedData | 10–60 GB | vollständig, beim nächsten Build neu erzeugt |
| Docker (Images, Volumes, Build-Cache) | 5–80 GB | teilweise — Volumes können Daten sein |
~/Library/Developer/CoreSimulator/Devices | 5–40 GB | pro Simulator, jeder mit eigenem Datenbestand |
~/Library/Developer/Xcode/iOS DeviceSupport | 3–25 GB | vollständig, wird bei Bedarf neu geladen |
~/.npm, ~/.pub-cache, ~/Library/Caches/pip | 2–15 GB | vollständig, rein wiederherstellbar |
Homebrew-Downloads (brew cleanup -n) | 1–10 GB | vollständig, Homebrew nennt den Betrag selbst |
~/Downloads | 2–40 GB | deine Entscheidung, oft Installer von 2023 |
~/Library/Mail (Anhänge) | 1–30 GB | über Mail-Einstellungen, nicht über den Finder |
| iPhone-/iPad-Backups | 5–150 GB | nur, wenn es woanders eine Kopie gibt |
| Fotomediathek (Originale lokal) | 10–400 GB | über iCloud-Optimierung, nicht durch Löschen |
| Papierkorb | 0–50 GB | sofort, wird gern vergessen |
| Datenleichen entfernter Programme | 0,5–8 GB | vollständig, aber erst nach Zuordnung |
Die Reihenfolge zählt: der erste Eintrag gibt auf einer Entwicklermaschine oft mehr her als die nächsten fünf zusammen, und er kostet exakt nichts — beim nächsten Build ist alles wieder da.
Der Fehler, den Aufräum-Programme machen
Ein Cleaner sieht einen 41 GB großen Ordner namens Docker.raw und schlägt vor, ihn zu leeren. Was er nicht sieht: darin liegen vier getrennte Konten, und eines davon sind benannte Volumes — also die Datenbank, die jemand vor einem Jahr für ein Projekt angelegt hat.
du kann messen, wie groß ein Ordner ist. Nur das Werkzeug, dem der Ordner gehört, weiß, wie viel davon gefahrlos zurückkommt. Deshalb fragt BalaneDisk das Werkzeug:
docker system df -v
brew cleanup -n
xcrun simctl list -jJeder dieser Aufrufe ist read-only und beantwortet die Frage, die eine Ordnergröße offenlässt.
Was du in zehn Minuten tatsächlich zurückholst
Eine realistische Reihenfolge für einen Mac, der voll ist:
- 01Papierkorb leeren. Kostenlos, sofort, wird ständig vergessen.
- 02
~/Library/Developer/Xcode/DerivedData— falls vorhanden, meist der größte Einzelposten. - 03Docker gestaffelt aufräumen, nicht pauschal: erst Build-Cache, dann ungenutzte Images, Volumes zuletzt und einzeln.
- 04Simulatoren durchsehen. Abgeschaltete Geräte, die du seit zwei iOS-Versionen nicht gestartet hast, halten trotzdem ihren vollen Datenbestand.
- 05Paketmanager-Caches über ihre eigenen Befehle.
- 06Downloads sichten. Installer, DMGs, ZIPs von Dingen, die längst installiert sind.
Danach ist ein typischer Entwickler-Mac 60 bis 120 GB leichter, ohne dass eine einzige eigene Datei angefasst wurde.
Warum wir trotzdem nichts löschen
BalaneDisk zeigt jeden dieser Funde mit Größe, Einordnung und dem konkreten Weg — dem Befehl, den das zuständige Werkzeug will, oder dem Ordner, geöffnet im Finder. Gelöscht wird nichts. Ein Programm, das ungefragt Ordner leert, verlangt Vertrauen für Daten, die es nicht versteht; die Entscheidung und das Rückgängig bleiben bei dir.
Mehr dazu: Warum BalaneDisk nichts löscht.
- Warum zeigt „Über diesen Mac“ mehr Belegung als die Summe meiner Ordner?
- Weil ein großer Teil des Platzes in versteckten Ordnern unter ~/Library, in APFS-Snapshots und in Systemdaten liegt, die der Finder gar nicht anzeigt. Die Kategorie „System-Daten“ ist keine Einheit, sondern der Rest, den macOS keiner anderen Kategorie zuordnen konnte.
- Kann ich ~/Library/Caches einfach löschen?
- Technisch ja, sinnvoll selten. Die meisten Programme legen ihren Cache sofort neu an, manche verlieren dabei angemeldete Sitzungen oder lokale Entwürfe. Zielgerichtet vorzugehen — Xcode, Docker, npm über ihre eigenen Befehle — gibt mehr Platz zurück und kostet nichts.
- Wie viel Platz sollte auf einer SSD frei bleiben?
- Als Faustregel 10 bis 15 Prozent. Darunter wird APFS beim Anlegen von Snapshots und beim Schreiben großer Dateien spürbar langsamer, und einzelne Programme brechen Speichervorgänge ab, statt zu warten.