- Das Problem. Unsere Erkennungsfunktion stufte 16,9 GB an iOS-Simulator-Images als verwaist ein. macOS lässt sie von niemandem löschen, und Apples eigenes Tool hinterließ beim Versuch 34 GB an fehlgeschlagenen Kopien.
- Was wir herausgefunden haben. Sie waren nicht verwaist. Sie sind die Basis-Images zweier installierter Simulatoren, die die Registry aus den Augen verloren hatte, und das Löschen dieser Runtimes bringt 21 MB zurück. Entfernen kann sie nur Xcode, im Bereich „Components“.
- Was wir gebaut haben. Mint repariert die Registry, bevor es etwas als verwaist entfernt, und führt diese Images unter Keep mit einem Hinweis auf Xcode. Den Weg, der 8-GB-Kopien zurückließ, versucht Mint nicht mehr.
Wir hatten eine Erkennungsfunktion ausgeliefert, die auf einem Entwickler-Mac 16,9 GB verwaister iOS-Simulator-Runtimes fand. Sie listete sogar auf, um welche Builds es sich handelte.
Wie sich herausstellte, waren diese Dateien die Basis-Images zweier Simulatoren, die noch installiert waren. Die Erkennungsfunktion lag also falsch.
In diesem Beitrag zeigen wir, wie ein Speichertool zu so einem Urteil kommt. In jedem Schritt auf dem Weg dorthin steckt eine Falle, und drei dieser Fallen kosten Nutzer bis heute Speicherplatz. Alle Zahlen unten haben wir vom 19. bis 21. August 2026 auf einem einzigen Mac gemessen, und jede davon kannst du nachmessen.
Der Datenmüll, den macOS nicht löschen lässt
Jedes Mal, wenn Xcode einen iOS-Simulator herunterlädt, landet das System-Image in Apples Asset-Speicher unter /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/<hash>.asset, jeweils etwa 8 bis 9 GB groß. CoreSimulator, der Dienst, der die Simulatoren ausführt, hält in einer Registry fest, welche er kennt. xcrun simctl runtime list gibt sie aus.
An diesem Morgen zeigte die Registry eine Runtime an (iOS 26.5), der Ordner enthielt aber drei. Die anderen beiden waren iOS 18.2 und iOS 18.4 mit 8,4 und 8,5 GB, beide Anfang 2025 heruntergeladen.
Zwei große Images, und nichts in der Registry verweist auf sie. So sieht eine verwaiste Datei normalerweise aus, und genau zu diesem Schluss kam unser Scanner.
Die erste Überraschung ist, dass du sie ohnehin nicht löschen kannst:
$ ls -lO /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/
drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Feb 4 2025 3ee34d77….asset
drwxr-xr-x@ 5 _nsurlsessiond wheel restricted 160 Apr 8 2025 6fb1e5fe….asset
restricted ist ein Flag des Systemintegritätsschutzes (SIP). Niemand kann den Ordner anrühren, auch nicht mit sudo rm. Im Netz lautet der übliche Rat „SIP deaktivieren, neu starten, löschen, SIP wieder aktivieren“, und so etwas liefern wir an niemanden aus.
Apples eigener Runtime-Dienst kann sie allerdings entfernen. Du bittest ihn mit simctl runtime add <image> --move, das Image wieder in seine Registry aufzunehmen, und löschst es dann über seine UUID. Der Daemon entfernt es mit seinen eigenen Berechtigungen, daher erscheint keine Passwortabfrage.
Die Weigerung, die dich 8 GB kostet
Der Dienst weigerte sich, das Image aufzunehmen:
$ xcrun simctl runtime add …/092-10337-196.dmg --move
SimDiskImageError code=14: Cannot copy the image because the disk is almost full
Frei waren 24,7 GB, das Image ist 8,4 GB groß. Die Logzeilen des Daemons sind geschwärzt, also haben wir stattdessen in das Binary geschaut:
$ strings …/CoreSimulator.framework/…/simdiskimaged
minFreeSpace = %llu
Because source is on the same volume as inbox and clones are supported
will allow a lower free space limit
Kann der Dienst einen APFS-Klon der Quelle anlegen (Copy-on-Write, sofort, ohne ein zusätzliches Byte), braucht er kaum freien Speicher. Kann er das nicht, weicht er auf eine vollständige Kopie Byte für Byte aus und verlangt die Größe des Images plus eine große Reserve obendrauf.
Aus dem SIP-geschützten Asset-Speicher heraus kann er nicht klonen. Bevor dir Apples eigenes Tool also mit dem Ordner hilft, den du nicht löschen darfst, muss es eine vollständige Kopie davon anlegen.
Wir haben das auch von der anderen Seite her geprüft. Eine gewöhnliche 9-GB-Datei in /tmp besteht dieselbe Vorprüfung mit nur 14,6 GB freiem Speicher. Gleiches Volume, ähnliche Größe, kein SIP-Flag, und der Daemon hat nichts einzuwenden.
Schlimmer noch: Ein abgelehntes runtime add bleibt nicht folgenlos. Bis der Daemon entscheidet, dass die Festplatte zu voll ist, hat er das Image schon in seinen eigenen Speicher kopiert und als Unusable-Runtime registriert, und beides lässt er liegen. Drei Ablehnungen hinterließen drei Kopien zu je 8,38 GB in /Library/Developer/CoreSimulator/Cryptex/Images/ und dazu eine 9-GB-Kopie in seiner Inbox.
Das sind 34 GB an Rückständen aus Vorgängen, die allesamt einen Fehler gemeldet hatten. Kein Tool listet sie auf. Ein du über deinen Benutzerordner bekommt sie nie zu sehen, und die Runtime, zu der sie gehören, taucht in der einfachen Ausgabe von simctl runtime list nicht auf.
Der Datenmüll, der keiner war
An diesem Punkt lautete unser Fazit: Niemand kann die 16,9 GB löschen, und der Weg über die Aufnahme macht es mit jedem Fehlschlag schlimmer. Ein einziger Befehl hat dieses Fazit widerlegt.
xcrun simctl runtime scan-and-mount ist Apples eigener Reparaturbefehl. Er weist CoreSimulator an, seinen Speicher abzusuchen und alles wieder aufzunehmen, was ihm abhandengekommen ist, und braucht dafür etwa eine Zehntelsekunde. Danach sah die Registry so aus:
$ xcrun simctl runtime list
iOS 18.2 (22C150) - 87410283-… (Ready)
iOS 26.5 (23F77) - 8E56E104-… (Ready)
iOS 18.4 (22E238) - 10B15C7F-… (Ready)
Total Disk Images: 3 (24.2G)
Aus einer Runtime in der Registry waren drei geworden. Der vollständige JSON-Eintrag für iOS 18.4 enthielt außerdem ein Feld, das die zusammenfassende Liste nie anzeigt:
parentImagePath = /System/Library/AssetsV2/…/6fb1e5fe….asset/AssetData/090-44150-318.dmg
Das „verwaiste“ Asset war das Basis-Image einer installierten, funktionierenden Runtime. CoreSimulator hatte die Registrierung der beiden Cryptex-Bundles mit iOS 18.2 und 18.4 verloren, und solange diese Registrierung fehlte, beanspruchte nichts auf dem Mac die Assets für sich. An den Dateien hatte sich nichts geändert. Verloren gegangen war der Eintrag in der Registry.
Danach war die Bereinigung einfach. Ein simctl runtime delete <UUID> für die drei Unusable-Reste räumte die vollen 34 GB an Zwischenkopien weg. Dafür waren weder ein Passwort noch Platz für Zwischenkopien nötig, und auch die Inbox war danach leer. Die beiden 18.x-Runtimes erscheinen in unserem Scan jetzt korrekt: eine unbenutzt, eine durch einen neueren Build ersetzt, beide per UUID löschbar.
Und dann lagen wir wieder falsch
Löschst du sie, wird fast nichts frei. Wir haben das Löschen über Mint laufen lassen und nachgemessen: Das Entfernen der iOS-18.2-Runtime brachte 21 MB zurück, nicht annähernd 8,4 GB. Die Registrierung verschwand und das Bundle wurde ausgehängt, aber das 8,4 GB große .asset blieb genau, wo es war. simctl runtime delete entfernt nie das MobileAsset, aus dem die Runtime installiert wurde. Apple liefert sogar ein Flag --keep-asset mit, was nahelegt, dass das Asset standardmäßig entfernt wird, und bei einer Runtime auf Cryptex-Basis ändert das Flag nichts.
Damit blieb nur ein Weg, den Platz zurückzubekommen, so jedenfalls unser Schluss: runtime add --move, womit das Image aus dem geschützten Speicher verlagert wird. Dieser Weg kann nicht klonen, also verlangt er freien Platz für das Image plus etwa ein Zehntel des Volumes. Auf einem 494-GB-Laufwerk mit 16,9 GB toter Simulatoren musst du also zuerst rund 58 GB freigeben.
Nachtrag, eine Woche später, nachdem wir die 58 GB freigegeben und es ausprobiert hatten: Auch dieser Weg funktioniert nicht. Der Daemon nimmt seine Kopie auf und meldet dann „--move was specified but unable to remove original file: Operation not permitted“. Apples eigener Dienst kann trotz seiner Sonderrechte eine Datei im versiegelten Asset-Speicher genauso wenig entfernen wie du. Jeder Versuch hinterlässt außerdem eine 8-GB-Zwischenkopie in CoreSimulators Images/Inbox, und nichts, was wir probiert haben, konnte diese Kopie entfernen: weder simctl noch rm als root mit eingegebenem Administratorpasswort. Kein Programm kann den Speicherplatz einer Runtime zurückholen, die in Apples Asset-Speicher liegt. Der einzige Ort, an dem das noch geht, ist Xcode unter Settings ▸ Components, wo eine registrierte Runtime eine Schaltfläche zum Entfernen hat.
Im Rückblick stimmte die Rechnung mit dem freien Speicher von Anfang an. Falsch lagen wir zuerst bei der Einordnung und dann beim Weg.
Beim Messen sind zwei weitere Probleme aufgetaucht. Wenn du eine Runtime gelöscht und neu gescannt hast, war sie wieder da: Unser eigener Reparaturschritt registrierte das übrig gebliebene Asset erneut und machte das Löschen rückgängig. Und ein Löschvorgang, der geklappt hatte, wurde als Fehler gemeldet, weil CoreSimulator seine Registry zum Zeitpunkt unserer Prüfung noch nicht aktualisiert hatte. Beides ist behoben. Gefunden haben wir die beiden Fehler erst, als wir anfingen, das Dateisystem zu messen, statt der Registry zu vertrauen.
Noch eine Eigenheit von Apple, falls du deine eigene Bereinigungsroutine schreibst: simctl runtime delete --notUsedSinceDays 90 erfasste hier nichts, obwohl bei beiden 18.x-Runtimes lastUsedAt auf null steht. Apples Filter „Nicht Benutztes löschen“ überspringt Runtimes, die noch nie benutzt wurden.
Ein Ordner, zwei Namen
Während wir das Diagramm bauten, das zeigt, wohin der Speicherplatz geht, schlug eine interne Prüfung an. Die Untereinträge der Kategorie „Developer“ ergaben zusammen 18,1 GB mehr als die Kategorie selbst. Das dürfte gar nicht möglich sein, denn jeder Untereintrag wird innerhalb seines übergeordneten Eintrags gemessen. Die Prüfung schlug 502-mal an, und der Überschuss betrug jedes Mal genau 18,1 GB.
Die Ursache war ein Firmlink. Seit Catalina legt macOS das System auf ein versiegeltes, schreibgeschütztes Volume und deine Daten auf ein anderes und fügt beide so zusammen, dass das Dateisystem wie ein einziger Baum aussieht. Manche Pfade haben dadurch zwei Schreibweisen, die auf denselben Ordner zeigen:
$ stat -f '%d %i %N' /System/Library/AssetsV2 /System/Volumes/Data/System/Library/AssetsV2
16777233 210916113 /System/Library/AssetsV2
16777233 210916113 /System/Volumes/Data/System/Library/AssetsV2
Beide Zeilen zeigen dasselbe Gerät und denselben Inode unter zwei Namen. Unser Durchlauf über die ganze Festplatte erfasste den Simulator-Ordner unter der einen Schreibweise, der Scanner meldete die Runtimes unter der anderen. Ein Vergleich der Zeichenketten hielt das für zwei verschiedene Orte, und so kamen 18,1 GB zu einer Kategorie hinzu, in der sie schon enthalten waren.
Jedes Speichertool ordnet Messwerte über Pfade einander zu, und jedes davon hat diesen Fehler, solange es nicht über die Firmlink-Tabelle vergleicht. Das eigentliche Problem ist älter als APFS: Zwei verschiedene Pfade können dieselbe Datei sein. Vergleiche also Gerät und Inode, nicht Zeichenketten.
Die 46,7 GB, die es nie gab
Lass du über die Update-Reste von Chrome laufen, und es meldet 46,7 GB in 34 Ordnern namens *.code_sign_clone. Lösch sie alle, und dein freier Speicher ändert sich kein bisschen.
Es sind APFS-Klone. Beim Signieren des Codes legt Chrome einen Copy-on-Write-Schnappschuss seines eigenen Bundles an, und der Klon teilt sich jeden Block mit dem Original, bis einer von beiden verändert wird, und das passiert nie. du meldet die logische Größe und zählt eine 1,4 GB große App deshalb 34-mal.
Ein Aufräum-Tool, das nach du sortiert, setzt diese Ordner ganz oben auf die Liste und lässt dich 46,7 GB „freigeben“. Danach zeigt dein freier Speicher denselben Wert wie vorher. Wir messen stattdessen die belegten Blöcke und lassen Klon-Ordner in der Übersicht weg. Lieber erwähnen wir sie gar nicht, als 46,7 GB zu versprechen und nichts freizugeben.
Das Löschen, das eine Sekunde zu spät ankam
Die letzte Falle ist klein. Erwischt hat sie uns an dem Tag, an dem wir diesen Beitrag geschrieben haben.
Damals zeigte unser Beleg nach einer Bereinigung nicht die Größe dessen, was entfernt wurde, sondern wie sich der freie Speicher auf dem Volume verändert hatte, gemessen direkt nach dem Verschwinden der letzten Datei. Der freie Speicher ist die einzige Zahl, die Nutzer im Finder nachprüfen können, deshalb haben wir es so gemacht, und das hatte monatelang funktioniert.
Dann löschte jemand zwei 9-GB-Ordner, und der Beleg meldete: 0 Byte freigegeben. Die Dateien waren weg, und der Verlaufseintrag verzeichnete 17,5 GB als endgültig gelöscht, aber der freie Speicher des Volumes, 375 Millisekunden später gelesen, hatte sich nicht bewegt.
APFS gibt die Blöcke eines großen Verzeichnisbaums asynchron frei. Ein paar Hundert Megabyte kommen fast sofort zurück, Dutzende Gigabyte brauchen Sekunden, und eine Messung in dieser Lücke sieht nichts. Die große Zahl oben im Fenster las den Wert nur ein einziges Mal und bewegte sich deshalb ebenfalls nicht. Für Nutzer sieht das genau so aus wie ein fehlgeschlagenes Löschen.
Die Lösung ist langweilig. Mint lässt dem Volume jetzt Zeit, zur Ruhe zu kommen, bevor es eine Zahl meldet, und liest die große Zahl oben neu, sobald etwas Speicherplatz freigegeben hat, egal über welche Schaltfläche.
Was wir geändert haben
Die Erkennungsfunktion haben wir behalten, aber sie kann nichts mehr anhand einer Registry markieren, die sie nicht überprüft hat. Bevor Mint Simulator-Speicher als verwaist einstuft, bittet es CoreSimulator, seinen eigenen Speicher wieder aufzunehmen, und liest die Registry dann erneut. Auf diesem Mac erkennt Mint dadurch korrekt, dass die beiden „verwaisten“ Images die Basis-Images zweier installierter Runtimes sind. Mint führt sie unter Keep, mit einem Hinweis auf den Bereich „Components“ in Xcode, den einzigen Ort, an dem sie sich entfernen lassen. Eine Schaltfläche in Mint hätte 21 MB freigegeben und den Rest als „nothing was removed“ gemeldet.
Nachtrag, Oktober 2026: Ein gewöhnlicher Scan bittet CoreSimulator nicht mehr, seinen Speicher wieder aufzunehmen. Er liest nur die Registry. Diese Reparatur läuft jetzt nur noch, wenn du über Mint Simulator-Speicher entfernst.
Den Weg über runtime add --move versucht Mint nicht mehr, also kann es auch keine 8 GB an Zwischenkopien zurücklassen. Kopien, die CoreSimulator bereits als Unusable führt, werden per UUID gelöscht, und für eine Zwischenkopie, die in der Inbox liegen geblieben ist, gibt es einen Versuch mit dem Administratorpasswort. Wird das Entfernen selbst mit diesem Passwort verweigert, merkt sich Mint das und bietet die Zeile nicht mehr an, bis sich die Datei oder das Betriebssystem ändert.
Keine dieser Fallen ist ein Fehler in macOS. Versiegelte Systemvolumes, Firmlinks, Copy-on-Write-Klone, verzögerte Freigabe und eine Runtime-Registry, die sich selbst repariert, sind technisch alle sinnvoll, und solange du den Mac einfach nur benutzt, merkst du davon nichts. Ärger machen sie einem Programm, das behauptet zu wissen, wo dein Speicherplatz geblieben ist, denn bei jeder von ihnen klaffen die Größe eines Ordners und der Platz, den sein Löschen zurückbringt, auseinander.
Der billige Weg, ein Aufräum-Tool für die Festplatte zu bauen: den Verzeichnisbaum ablaufen, nach Größe sortieren und neben die großen Posten Checkboxen setzen. Bei jeder der Fallen oben zeigt dieser Ansatz eine größere Zahl, als Nutzer zurückbekommen, und das merken sie erst nach dem Klick.
Unser teuerster Fehler hatte mit dem Messen nichts zu tun: Wir haben der Registry geglaubt, als sie sagte, nichts verweise auf diese Images, und nie geprüft, ob sie mit dem Zählen fertig war.
Alle Messungen haben wir im August 2026 mit dem rein lesenden Scan von Mint auf einem Entwickler-Mac vorgenommen, und du kannst sie auf deinem eigenen wiederholen. Was Coding-Agenten zurücklassen, steht in Dein Coding-Agent frisst deinen Speicherplatz.
So setzt du das auf deinem Mac um
Welche Schritte heute funktionieren, steht in der Anleitung zum Speicher des iOS-Simulators. Sie trennt Runtimes, Gerätedaten und Caches. Ist dein großer Ordner DerivedData, lies stattdessen die Anleitung zu Xcode-Build-Artefakten: Das sind andere Daten, und wenn du sie entfernst, hat das andere Folgen.