Speicher des iOS-Simulators auf dem Mac: was du löschen kannst und was nicht
Fang in Xcode unter Settings → Components an und entferne dort Runtimes, die du nicht mehr brauchst. Simulator-Geräte, Caches und installierte Runtime-Images sind unterschiedliche Arten von Daten. Sichere benötigte Testdaten, bevor du ein Gerät zurücksetzt, und miss den tatsächlich freien Speicherplatz, nachdem du etwas auf einem unterstützten Weg entfernt hast. Die folgenden Zahlen stammen von einem einzigen Mac, den wir im August 2026 getestet haben, und sind kein Versprechen für jede Version von Xcode oder macOS.
Das Wichtigste in Kürze
- Kurz gesagt. Fang in Xcode unter Settings → Components an und entferne dort Runtimes, die du nicht mehr brauchst.
- Worauf du achten solltest. Geräte, Caches und Runtime-Images sind unterschiedliche Arten von Daten. Sichere Testdaten, bevor du ein Gerät zurücksetzt, und prüf nach dem Entfernen den freien Speicherplatz.
- Mit Mint. Mint listet jeden Teil mit der Aktion auf, die dafür infrage kommt. Runtime-Dateien, die es nicht entfernen kann, zeigt es mit Größe und Grund an, ohne Auswahlkästchen.
Erst herausfinden, was da liegt, dann den Befehl wählen
Die folgenden Messungen haben wir vom 20. bis 26. August 2026 auf einem einzigen Entwickler-Mac vorgenommen, und sie beschreiben diese eine Installation. Bevor du einen Befehl ausführst, der von der Version abhängt, sieh dir die aktuelle Komponentenliste in Xcode und die Hilfe zu deiner installierten simctl-Version an. Schalte den Systemintegritätsschutz nicht ab, um ein Löschen zu erzwingen.
Wo der Simulator seine Daten ablegt
Der Speicher des Simulators verteilt sich auf vier Stellen, und jede verhält sich anders. Registrierte Runtimes sind Disk-Images, die CoreSimulator einhängt. Die eigentlichen Dateien liegen meist unter /System/Library/AssetsV2 oder in einem Cryptex-Bundle unter /Library/Developer/CoreSimulator/Cryptex/Images/bundle. Die Gerätedaten, also die Apps und Dateien in jedem simulierten iPhone, stecken in ~/Library/Developer/CoreSimulator/Devices. Gleich daneben findest du die gemeinsamen Caches, die bei jedem Simulator-Start neu aufgebaut werden. Und wenn die Installation einer Runtime schiefgeht, können Zwischenkopien in /Library/Developer/CoreSimulator/Images/Inbox zurückbleiben.
Auf einem Entwickler-Mac kam das zusammen auf etwa 35 GB, und 16,9 GB davon steckten in einem Zustand, aus dem kein Befehl sie zurückholen konnte. Die meiste Arbeit besteht darin, zu erkennen, welchen dieser Posten du gerade vor dir hast, denn die belegte Größe sagt nichts darüber, ob er weg kann.
Was den Platz wieder freigibt
Geh über CoreSimulator, dem diese Dateien gehören. Es führt ein Register, und wenn du Dateien an ihm vorbei löschst, listet dieses Register weiter Runtimes auf, die gar nicht mehr da sind.
- Öffne in Xcode Settings → Components (in älteren Versionen Platforms). Behalte die Runtime-Versionen, die deine aktuellen Tests brauchen, und entferne eine ungenutzte über die Info- oder Löschen-Schaltfläche daneben.
- Sichere die App-Daten, die du brauchst, und beende alle laufenden Simulatoren, bevor du ein simuliertes Gerät zurücksetzt oder löschst. Such mit xcrun simctl list devices das genaue Gerät heraus und lies dann xcrun simctl help erase oder xcrun simctl help delete für die Werkzeuge, die bei dir installiert sind. Beide Befehle verwerfen die Daten des Geräts.
- Die gemeinsamen Caches zu entfernen ist optional und eher etwas für Fortgeschrittene. Sieh zuerst in xcrun simctl runtime help nach, denn die dyld_shared_cache-Unterbefehle aus unserem Test hängen von der Version des Tools ab. Die 3,04 GB, die wir so freigegeben haben, waren nur vorübergehend frei: Sobald ein Simulator startet, baut er die Caches neu auf, die er braucht.
- Prüf den freien Speicherplatz noch einmal und starte einen Simulator, den du behalten hast. Ist der Platz nicht frei geworden, sieh dir die aktuelle Liste unter Components und die Fehlermeldung an, statt es noch einmal mit direktem Löschen zu versuchen. Eine entfernte Registrierung heißt nicht, dass die eigentlichen Dateien weg sind.
Was sich nicht löschen lässt, und warum
Runtime-Dateien unter /System/Library/AssetsV2 tragen das SIP-Flag „restricted“. Der Befehl xcrun simctl runtime delete <runtime UUID> entfernt die Registrierung und hängt das Bundle aus, aber der Ordner bleibt auf der Festplatte, und der freie Speicherplatz ändert sich nicht. Wir haben das zweimal auf demselben Rechner geprüft.
Noch seltsamer sind die Zwischenkopien in /Library/Developer/CoreSimulator/Images/Inbox. Zwei davon, je 8,22 GB groß, hatten keine besonderen Flags, keine erweiterten Attribute und keine ACL, SIP schützt sie also nicht. Auch verwies nichts auf sie: hdiutil und diskutil zeigten nichts als eingehängt an, und die Runtime-Liste meldete null Disk-Images. Ein Neustart änderte nichts daran, und keiner unserer Versuche hat sie entfernt. Der Befehl xcrun simctl runtime add <file> --move bittet Apples eigenen Daemon mit Entitlements, das Image zu verschieben. Er übernimmt die Runtime und meldet dann „--move was specified but unable to remove original file: (1) Operation not permitted“. Wenn ein Daemon mit mehr Rechten als deine Shell die Datei nicht löschen kann, schafft es rm als root auch nicht.
So lief es auf einem Mac mit den Schritten, die wir getestet haben. Das beweist nicht, dass jede geschützte Datei oder Zwischenkopie in jeder Version für immer festsitzt. Wenn du zu einem anderen Ergebnis kommst, richte dich nach der aktuellen Verwaltung in Xcode und den Support-Hinweisen von Apple.
Was daneben noch einen Blick wert ist
Alte Metal-Toolchains aus anderen Xcode-Versionen belegen jeweils etwa 670 MB und lassen sich nur im selben Bereich Components entfernen, unter der Überschrift für andere Xcode-Versionen. Der Befehl xcodebuild -deleteComponent entfernt die aktuelle Toolchain und nimmt keine Versionsangabe an, an die Überbleibsel kommt er also nicht heran.
DerivedData und Archives liegen woanders und folgen eigenen Regeln. DerivedData lässt sich neu erzeugen und gefahrlos entfernen, wenn Xcode geschlossen ist. Archives enthalten die Symboldateien, die du brauchst, um Absturzberichte eines ausgelieferten Builds zu lesen. Die neueren solltest du deshalb behalten.
Wie Mint damit umgeht
Mint listet jeden Teil des Simulator-Speichers mit der Aktion auf, die dafür infrage kommt. Eine Runtime, die es über CoreSimulator entfernen kann, bietet es auch auf diesem Weg an. Runtime-Dateien unter AssetsV2 zeigt es mit ihrer Größe und einer Erklärung an, aber ohne Auswahlkästchen, denn ein Kästchen würde ein Entfernen versprechen, das nicht möglich ist. Hat eine Zwischenkopie dein Administratorpasswort schon einmal abgewiesen, merkt sich Mint das und fragt für diese Datei nicht noch einmal nach dem Passwort.
Eine Aktion kann trotzdem abgelehnt werden, etwa wegen der Zugriffsrechte, eines laufenden Prozesses oder einer Änderung seit dem Scan. Prüf das Ergebnis, statt davon auszugehen, dass jedes ausgewählte Byte freigegeben wurde.
Häufig gestellte Fragen
Kann ich ~/Library/Developer/CoreSimulator einfach von Hand löschen?
Lösch nicht den ganzen Ordner CoreSimulator von Hand. Such zuerst das Gerät oder die Runtime heraus, sichere die Gerätedaten, die du brauchst, und entferne den Eintrag dann über die Wege, die dein installiertes Xcode oder simctl vorsieht.
Warum gibt das Löschen einer Runtime weniger Platz frei, als sie groß ist?
Die Registrierung einer Runtime, ihr eingehängtes Image und ihre eigentlichen Dateien sind getrennte Dinge. Entferne die Runtime in der Komponentenverwaltung von Xcode und prüf danach den freien Speicherplatz. In unserem Test verschwand manchmal die Registrierung, während die Dateien blieben.
Kann ich die gemeinsamen Caches gefahrlos entfernen?
Auf dem Mac und mit den Tool-Versionen aus unserem Test hat es funktioniert, solange kein Simulator lief. Sieh zuerst in der Hilfe zu simctl runtime für deine installierte Version nach. Die Caches, die ein Simulator braucht, werden neu aufgebaut, der gewonnene Platz ist also nur vorübergehend frei.
Und was ist mit den .cxbd-Dateien im Ordner Inbox?
Das können Zwischenkopien sein, die eine Runtime-Installation zurückgelassen hat. Die Kopien auf unserem Test-Mac haben sich den oben beschriebenen Versuchen widersetzt, aber das heißt nicht, dass jede .cxbd-Datei ungenutzt ist oder für immer festsitzt. Richte dich nach der aktuellen Verwaltung in Xcode und den Support-Hinweisen von Apple.
Sieh nach, welche Simulator-Dateien auf deinem Mac liegen
Starte einen kostenlosen lokalen Scan, der Simulator-Speicher, geschützte Dateien und andere Entwicklerdaten sortiert, bevor du entscheidest, was damit passiert.