Simulator-Runtimes und Docker.raw: die sauberen Wege statt roher Ordnerumzüge

Auf vielen Entwickler-Macs gehören zwei Posten zu den größten: die Simulator-Plattformen von Xcode und das Festplattenabbild von Docker Desktop. Beide wachsen schleichend, beide sind im Finder schwer zu durchschauen, und bei beiden liegt der Gedanke nahe, den Ordner einfach auf eine externe SSD zu schieben und einen Link zu setzen. Genau das solltest du hier nicht tun. Dieser Beitrag erklärt, warum, und zeigt die Wege, die Apple und Docker dafür vorsehen.

Warum rohe Ordnerumzüge hier riskant sind

Ein Projektordner ist passiv: Er liegt da, bis ein Programm ihn öffnet. Simulator-Runtimes und das Docker-Abbild sind anders. Sie werden von Diensten verwaltet, die im Hintergrund laufen, Dateien geöffnet halten und selbst Buch darüber führen, was wo liegt.

Simulator-Runtimes installiert und verwaltet macOS in eigenen Systembereichen, teils an geschützten Orten, auf die du als Nutzer keinen Schreibzugriff hast. In Apples Entwicklerforen finden sich Berichte über verwaiste Runtimes, die sich wegen des Systemschutzes nicht einmal per Hand löschen lassen. Wer hier Ordner verschiebt oder verlinkt, arbeitet gegen die Verwaltung des Systems statt mit ihr.

Das Docker-Abbild ist die virtuelle Festplatte einer Linux-VM, in der deine Container laufen. Wird die Datei verschoben, während Docker läuft, oder zeigt ein Link auf ein Laufwerk, das beim Start fehlt, drohen ein Docker Desktop, das nicht mehr startet, oder beschädigte Daten in Containern und Volumes.

Deshalb verschiebt DevSpace Manager, unsere macOS-App von BRUNIQO, CoreSimulator-Daten, Simulator-Runtimes und Docker.raw bewusst nicht direkt. Für diese Daten sind die Wege in Xcode und Docker Desktop vorgesehen, die dieser Beitrag beschreibt.

Simulatoren: was wo liegt

Bei Simulatoren lohnt es sich, zwei Ebenen zu unterscheiden. Runtimes sind die Betriebssystem-Abbilder, etwa für eine bestimmte iOS-Version. Eine Runtime wird von vielen Simulator-Geräten gemeinsam genutzt und ist entsprechend groß. Geräte sind die einzelnen Simulatoren, also die Kombination aus Gerätemodell und Systemversion, jeweils mit eigenen installierten Apps, Dokumenten und Caches. Ihre Daten liegen unter ~/Library/Developer/CoreSimulator/Devices.

Beide Ebenen wachsen aus unterschiedlichen Gründen. Runtimes kommen mit jeder neuen Plattform dazu, die du installierst, und bleiben oft liegen, wenn du sie nicht mehr brauchst. Geräte sammeln Testdaten, und nach Xcode-Updates bleiben häufig Simulatoren für Systemversionen zurück, die gar nicht mehr installiert sind.

Runtimes über Xcode verwalten

Der offizielle Ort ist Xcode → Settings → Components; in älteren Xcode-Versionen hieß der Bereich Platforms. Dort siehst du die installierten Plattformen und Simulator-Runtimes mit ihrer Größe und kannst entfernen, was du nicht mehr brauchst. Eine gelöschte Runtime lädst du später an derselben Stelle erneut, wenn ein Projekt sie wieder verlangt. Plane dafür eine Internetverbindung und etwas Zeit ein.

Im Terminal zeigt xcrun simctl runtime list die installierten Runtimes. Neuere Xcode-Versionen bringen auch Befehle zum Entfernen mit; welche Optionen deine Version kennt, verrät xcrun simctl help runtime. Für die meisten Fälle ist die Oberfläche in Xcode der einfachere und übersichtlichere Weg. Welche Runtimes du wirklich brauchst, ergibt sich aus den Mindestversionen deiner Apps und aus den Systemversionen deiner Testgeräte.

Mehrere Xcode-Versionen

Wer Betas neben der stabilen Version installiert, hat schnell mehrere große Xcode-Pakete im Programme-Ordner. Ein nicht mehr benötigtes Xcode entfernst du, indem du die App löschst. Die Simulator-Runtimes, die du damit geladen hast, verschwinden dabei nicht zwingend mit, denn sie werden getrennt von der App verwaltet. Prüfe deshalb nach dem Entfernen einer Xcode-Version in der verbliebenen Version unter Settings → Components, welche Runtimes noch installiert sind, und entferne die, die du nicht mehr brauchst.

Simulator-Geräte aufräumen

Einzelne Simulatoren löschst du im Fenster „Devices and Simulators“ von Xcode. Schneller geht das Aufräumen verwaister Geräte mit xcrun simctl delete unavailable. Der Befehl entfernt Simulatoren, deren Runtime nicht mehr installiert ist; ihre Daten waren ohnehin nicht mehr nutzbar.

Gründlicher, aber mit Nebenwirkungen ist xcrun simctl erase all. Der Befehl setzt alle Simulatoren auf den Werkszustand zurück und löscht dabei installierte Apps und ihre Daten. Das ist sinnvoll, wenn sich über Monate Testdaten angesammelt haben. Bewahrst du in einem Simulator Zustände auf, die du noch brauchst, ist er der falsche Befehl. Beende Simulator und Xcode, bevor du größere Aufräumaktionen startest.

Docker: den Platz verstehen

Docker Desktop speichert Images, Container, Volumes und den Build-Cache in einem einzigen Festplattenabbild, das auf dem Mac als Docker.raw im Container-Ordner von Docker Desktop unter ~/Library/Containers/com.docker.docker liegt. Diese Datei ist eine sogenannte Sparse-Datei. Der Finder zeigt oft ihre maximale Größe, belegt ist aber nur der Teil, den Docker tatsächlich nutzt. Den echten Platzbedarf siehst du mit du -h auf die Datei. Das erklärt manche Verwirrung über eine scheinbar riesige Datei. Lösche Docker.raw nicht im Finder, um Platz zu schaffen: Die Datei enthält sämtliche Images, Container und Volumes, und ohne sie beginnt Docker Desktop praktisch von vorn.

Welche Daten innerhalb von Docker Platz belegen, zeigt docker system df. Die Ausgabe listet Images, Container, lokale Volumes und Build-Cache getrennt auf und nennt jeweils, wie viel davon zurückgewonnen werden könnte. Mit dieser Übersicht entscheidest du, wo sich Aufräumen lohnt.

In den Einstellungen von Docker Desktop kannst du unter Resources außerdem festlegen, wie groß die virtuelle Festplatte höchstens werden darf. Das begrenzt das Wachstum. Eine nachträgliche Verkleinerung kann je nach Version bedeuten, dass Docker die virtuelle Festplatte neu anlegt, lies die Hinweise im Dialog deshalb genau.

Docker aufräumen

Docker bringt eigene Befehle zum Aufräumen mit. docker image prune entfernt Images ohne Namen, die kein Container mehr nutzt, mit der Option -a auch alle anderen ungenutzten Images. docker builder prune leert den Build-Cache. docker system prune fasst mehrere Schritte zusammen und entfernt je nach Optionen gestoppte Container, ungenutzte Netzwerke, Images und Build-Cache. Mit zusätzlichen Optionen trifft er auch Volumes, und dort liegen häufig die Daten deiner Datenbanken. Lies die Bestätigungsabfrage deshalb genau, bevor du zustimmst, und sichere Volumes mit wichtigen Daten vorher.

Nach dem Aufräumen schrumpft Docker.raw nicht immer sofort sichtbar. Wie schnell Docker Desktop frei gewordenen Platz an macOS zurückgibt, hängt von der Version ab. Miss nach einer Weile noch einmal mit du -h nach.

Das Docker-Abbild auf eine SSD verlegen

Wenn Aufräumen nicht reicht, kannst du den Ort des Abbilds ändern. Der vorgesehene Weg führt über Docker Desktop → Settings → Resources → Advanced → Disk image location. Docker verschiebt das Abbild dann selbst an den neuen Ort. Einige Punkte helfen, damit das gut geht:

• Beende vorher alle Container und sichere Volumes mit wichtigen Daten.
• Wähle einen Ordner auf einer SSD, die dauerhaft angeschlossen bleibt, und keinen Netzwerkordner.
• Starte Docker nicht, wenn die SSD fehlt, denn ohne sein Abbild kann Docker nicht arbeiten.
• Rechne mit Problemen: Im Issue-Tracker und im Forum von Docker gibt es Berichte, dass Docker Desktop nach einem Wechsel auf ein externes Laufwerk hängt oder nicht startet. Notiere dir den alten Ort, damit du zurückwechseln kannst.

Das ist nicht der bequemste Weg, aber der einzige, bei dem Docker weiß, wo seine Daten liegen. Ein Symlink auf Docker.raw oder auf den Container-Ordner umgeht genau diese Buchführung.

Häufige Missverständnisse

„Docker.raw belegt laut Finder riesige Mengen.“ Oft ist das die maximale Größe der Sparse-Datei, nicht der tatsächlich belegte Platz. Maßgeblich ist, was du -h meldet.

„Den CoreSimulator-Ordner kann ich einfach im Finder leeren.“ Davon ist abzuraten. Der Simulator-Dienst führt eine eigene Liste seiner Geräte, und von Hand gelöschte Ordner können Einträge hinterlassen, die ins Leere zeigen. Nutze Xcode oder xcrun simctl, dann bleibt die Verwaltung konsistent.

„Eine gelöschte Runtime ist für immer weg.“ Nein. Xcode lädt sie bei Bedarf erneut. Du brauchst dafür nur Zeit und eine Internetverbindung.

„Nach dem Aufräumen ist das Problem gelöst.“ Nur vorübergehend. Neue Xcode-Versionen bringen neue Runtimes mit, und Docker sammelt mit jedem Build wieder Images und Cache an. Plane das Aufräumen deshalb als wiederkehrende Aufgabe ein.

Speicher im Blick behalten

Nach jedem größeren Xcode-Update lohnt ein Blick in Settings → Components. Häufig liegen dort Runtimes älterer Systemversionen, die du nicht mehr testest. Behalte die, die zu den Mindestversionen deiner Apps und zu deinen Testgeräten passen, und entferne den Rest. Bei Docker hilft ein regelmäßiger Blick auf docker system df, zum Beispiel am Ende einer Projektphase. Und wenn du bestimmte Daten dauerhaft brauchst, aber nicht auf der internen SSD, ist ein geordneter Umzug auf eine externe SSD auf Dauer die ruhigere Lösung als ständiges Löschen.

Und was ist mit DerivedData?

DerivedData ist der Gegenpol zu Simulatoren und Docker: ein Ordner mit Build-Ergebnissen, den Xcode selbst anlegt und bei Bedarf neu aufbaut. Ihn kannst du löschen, über die Xcode-Einstellungen verlegen oder mit Prüfung auf eine SSD auslagern. Die Unterschiede beschreibt die Seite Xcode-Speicher: DerivedData löschen oder verlegen. Einen Überblick über alle typischen Wachstumszonen gibt die Seite Mac-Speicher voll: Systemdaten und Build-Ordner.

Wie DevSpace Manager damit umgeht

DevSpace Manager ist für große Arbeitsordner gedacht, die passiv auf einem Laufwerk liegen: Xcode DerivedData, Xcode-Archive, SwiftPM- und Node-Caches, node_modules, lokale Medienbibliotheken und große Projektordner. CoreSimulator-Daten, Simulator-Runtimes und Docker.raw verschiebt die App bewusst nicht direkt, ebenso wenig Daten auf Netzwerklaufwerken.

Bevor die App einen der geeigneten Ordner verlegt, prüft ihr Plan unter anderem, ob Prozesse von Xcode, Simulator oder Docker laufen. Das hilft, einen Umzug nicht mitten in einen laufenden Build oder Container hinein zu starten. Auch hier gilt: Die Auslagerung ersetzt kein unabhängiges Backup. DevSpace Manager ist für den Mac App Store vorgesehen und derzeit noch nicht veröffentlicht; mehr dazu auf der Übersichtsseite der App.

Kurzer Fahrplan

Wenn du den Platz auf deinem Mac in einer ruhigen Stunde ordnen willst, arbeite diese Reihenfolge ab. Sie beginnt mit dem Messen und endet mit dem Backup, denn beides wird am häufigsten übersprungen.

1. Miss den Platzbedarf mit du -sh ~/Library/Developer/* und docker system df.
2. Entferne ungenutzte Simulator-Runtimes in Xcode unter Settings → Components.
3. Räume verwaiste Simulatoren mit xcrun simctl delete unavailable auf.
4. Räume Docker mit den prune-Befehlen auf und lies jede Bestätigung genau.
5. Verlege das Docker-Abbild bei Bedarf nur über die Einstellung Disk image location.
6. Verlege passive Arbeitsordner wie DerivedData oder Projekte mit Prüfung und Rückweg.
7. Sorge dafür, dass dein Backup die ausgelagerten Daten erfasst.