I build StorageRadar, a disk space app for macOS. Every step below uses built-in commands, so you can follow along without it.
My Mac runs macOS 27.0.1 and Xcode 27.1, and I test several iOS apps on it. I measured what the simulators take on 25 October 2026.
Two places, two owners
Simulator storage lives in two places, and different tools manage them.
| What | Where | On my Mac |
|---|---|---|
| Runtimes, one per iOS version | system-managed disk images | 31.3 GB for 4 runtimes |
| Device data, one folder per simulator | ~/Library/Developer/CoreSimulator/Devices |
20 GB for 53 simulators |
A runtime is the iOS system image. Device data is what each simulated iPhone or iPad keeps: installed apps, their containers, logs and settings.
Runtimes: about 8 GB each
xcrun simctl runtime list prints every runtime and the total:
$ xcrun simctl runtime list
== Disk Images ==
-- iOS --
iOS 27.1 (24A94232) - … (Ready)
iOS 27.0 (24A434) - … (Ready)
iOS 26.5 (23F77) - … (Ready)
iOS 18.6 (22G86) - … (Ready)
Total Disk Images: 4 (31.0G)
Add -j and you get each runtime's size and the last time it ran. Mine range from 7.87 GB (iOS 27.1) to 8.84 GB (iOS 18.6).
Remove runtimes with simctl, not Finder. The images sit in protected system storage, and simctl shuts down booted simulators and unmounts the image first. Start with a dry run:
xcrun simctl runtime delete --notUsedSinceDays 30 --dry-run
You can also pass --unusable, --outdated, or one identifier from the list. Xcode's Settings window lists the same runtimes.
All four of mine ran in the last day, so I keep them. If you dropped an iOS version from your deployment targets, its runtime is the biggest single thing you can remove.
The du number that misleads
du -sh /Library/Developer/CoreSimulator/Volumes reported 51 GB on my Mac. That folder holds mount points:
$ mount | grep CoreSimulator/Volumes
/dev/disk5s1 on /Library/Developer/CoreSimulator/Volumes/iOS_23F77 …
du walks into the mounted images and counts the files inside them. The images take 31 GB on disk, and 51 GB is the size of their contents. Leave Volumes alone and use simctl runtime delete.
Device data: one simulator held half
The Devices folder took 20 GB, and the split surprised me:
du -sh ~/Library/Developer/CoreSimulator/Devices/* | sort -h | tail -5
- one QA simulator: 9.6 GB
- the next four: 3.3, 2.5, 2.1 and 1.5 GB
- 47 of 53 simulators: under 200 MB each
The folder names are UDIDs. xcrun simctl list devices maps them to names.
Two commands handle the heavy ones:
-
xcrun simctl erase <UDID>wipes the simulator's apps and data and keeps the device. -
xcrun simctl delete <UDID>removes the device.
xcrun simctl delete unavailable removes simulators your current Xcode can no longer run. I had none, but the list grows after Xcode upgrades and runtime deletions. Erasing a simulator leaves its runtime in place.
The rest of ~/Library/Developer
Two more folders sat next to the simulators:
- DerivedData, 6.2 GB. Xcode rebuilds it, so you can delete it and pay with one slower build.
- Archives, 3.9 GB. Keep the archives of builds you shipped: they hold the dSYMs that symbolicate crash reports.
My checklist now
-
xcrun simctl runtime listfor runtimes I no longer test on. -
duon Devices to find the one or two heavy simulators, then erase them. -
xcrun simctl delete unavailableafter each Xcode update.
I keep a longer guide with every path and what rebuilds it: Xcode Simulator taking up space on Mac. To test yourself on ten developer folders, from DerivedData to Docker data, try this quiz.
StorageRadar's Dev Cleanup lists ~/Library/Developer/CoreSimulator with a Caution label and DerivedData as Safe, next to npm, Docker and Homebrew caches, and moves files to the Trash after you confirm: storageradar.app.
Top comments (4)
The du-through-the-mount-points trap is a great catch, that 51 GB number looks so convincing. What was the 9.6 GB QA simulator actually holding, one big app container or years of logs?
Thanks! I checked the breakdown after your comment. The biggest folder was PRBPosterExtensionDataStore at about 2.9 GB. I also found 2 GB in var/db/diagnostics, 2 GB in private/var/MobileAsset, and 1 GB in the CoreSymbolication cache.
Apps and their containers came to about 350 MB in total. I’d only measured the whole device folder for the article, so thanks for prompting me to look inside.
2.9 GB of lock screen poster data is not where I'd have looked first. That breakdown would make a good follow-up post.
Thanks for the idea! I’d want to compare a few simulators to see whether this one is an outlier.