At 2:38 in the afternoon on September 29, my MacBook Pro froze and then restarted on its own.
The crash log pointed at low swap space, on a disk that was 97% full. du blamed 186 GB of iOS simulators, but it had counted disk images mounted inside the folder, and the real number was about 64 GB. I deleted six runtimes with Apple’s own tool, and 41.6 GB of them is still on disk, listed by nothing. That gap is why I’m building Diskling.
The crash log pointed at the disk
The panic log didn’t say much in plain words. Two lines stood out:
panic(cpu 2 caller ...): watchdog timeout: no checkins from watchdogd in 92 seconds
... 13 swapfiles and LOW swap spacemacOS writes swap files to the disk when memory runs short. Thirteen of them, with the system warning about low swap space, sent me straight to the disk. df showed the data volume 97% full: 460 GB, with 16 GB free.
Other things had been slow too. Obsidian took a moment to open notes, and I found out why. iCloud’s Optimize Mac Storage had moved 581 of my vault’s 583 notes to the cloud to save space, so every note I opened had to download first.
System Settings wasn’t much help. Storage showed 212 GB of System Data, and System Data doesn’t break down any further.
Clearing the obvious things first
I started with what I knew about. Android Studio and its emulators, some local AI models, and an AI editor all went, by hand. That was about 50 GB.
Then I went looking for what I didn’t know about, with an AI coding app running commands next to me. The list was long.
node_modules took 27.1 GB across 165 folders, and 69 of them hadn’t been touched in 90 days. Docker images took 18.1 GB. My AI coding agents, test runs, and local test sites had left about 50 GB behind.
One number was bigger than all of those.
186 GB of simulators
$ du -sh /Library/Developer/CoreSimulator186G /Library/Developer/CoreSimulatorThat was about 40% of the disk. simctl, the command-line tool that ships with Xcode, listed eight iOS simulator runtimes at 7.5 to 8.2 GB each. Only two had been used in the past month.
It looked like the easiest win of the day. I kept iOS 27.0, which matches Xcode 27, and iOS 26.5.
The other six went with xcrun simctl runtime delete. One delete got stopped by a safety check in the AI coding app, so I ran that one myself in Terminal.
Afterwards, simctl listed two runtimes, and Xcode’s Components settings agreed. By every tool’s count, the six were gone.
What du got wrong
Something didn’t add up. Eight runtimes at about 8 GB each is about 64 GB, not 186.
du had walked into disk images. macOS had mounted runtime images inside /Library/Developer/CoreSimulator/Volumes, and a plain du -sh counts what’s inside a mounted image as if it were part of the folder. The -x flag keeps du on one file system:
$ du -shx /Library/Developer/CoreSimulator3.0G /Library/Developer/CoreSimulator3 GB, all of it caches. So my big number was wrong.
The runtimes live somewhere else, in /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime, and they were about 64 GB. Still a lot for software I barely used, but not 40% of my disk.
The 41.6 GB that stayed
Then I measured the folder where the runtimes really live:
$ du -shx /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime 57G /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntimeI had kept two runtimes, and simctl said they came to 15.4 GB. The folder held 57 GB.
Five of the six runtimes I deleted were still there: iOS 18.0, 18.1, 18.2, 18.4, and 18.5, 41.6 GB together. Only iOS 26.1 had actually left the disk.
Nothing lists them. Xcode doesn’t, and simctl doesn’t.
Each one’s Info.plist says NeverCollected, so macOS won’t clean them up on its own. simctl’s help says --keep-asset keeps the downloaded image, so a delete without it should remove the image. I didn’t pass it.
The folder is protected by System Integrity Protection, so sudo rm can’t remove it either. I’m not turning SIP off for disk space.
Free space went from 16 GB to 79 GB that day. Most of that came from the apps I removed by hand. The simulator cleanup freed far less than it looked like it did.
Why this is the app I’m building
After that day I started asking around. Friends and colleagues had the same story: the disk suddenly almost full, and no idea where the space went.
The disk tools out there are good. DaisyDisk, DiskBuddy, Mole, and Pearcleaner all do their job. DaisyDisk shows the map, but this space ends up under System Data or hidden space.
None of them explains who owns it, whether the owner’s own tool can remove it safely, or that a delete can leave the files behind. I had to work that out with du, and I got it wrong the first time.
The idea behind Diskling is to name the owner of every big folder, say whether it’s safe to remove, and remove it with the owner’s own command, shown to you first. I’m also building it to measure again after a cleanup and tell you what didn’t come back, like these five runtimes.
It isn’t out yet.
Next time you delete simulator runtimes, run du -shx on the AssetsV2 folder before and after. I wrote up the full steps and that check. And if you find a safe way to get those leftovers back, tell me what worked.