iOS Simulator storage on Mac: what you can delete, and what you cannot
Start with Xcode Settings → Components to remove runtimes you no longer need. Simulator devices, caches and installed runtime images are different kinds of data. Save any test data you need before erasing a device, and measure actual free space after a supported removal. The figures below come from one Mac tested in August 2026, not a promise for every Xcode or macOS version.
TL;DR
- Short answer. Start with Xcode Settings → Components to remove runtimes you no longer need.
- Watch out for. Devices, caches and runtime images are different kinds of data. Save test data before erasing a device, and check free space after a removal.
- With Mint. Mint lists each piece with the action that applies. A payload it can’t remove shows its size and the reason, with no checkbox.
Identify the storage before choosing a command
We took the measurements below on one developer Mac between August 20 and 26, 2026, and they describe that installation. Before you run a version-specific command, check your current Xcode component list and the help for the simctl you have installed. Don’t turn off System Integrity Protection to force a deletion.
Where simulator storage lives
Simulator storage sits in four places, and each one behaves differently. Registered runtimes are disk images that CoreSimulator mounts, with the payload usually under /System/Library/AssetsV2 or in a Cryptex bundle under /Library/Developer/CoreSimulator/Cryptex/Images/bundle. Device data, meaning the apps and files inside each simulated iPhone, is in ~/Library/Developer/CoreSimulator/Devices. The shared caches that every simulator boot rebuilds sit next to it. And when a runtime install goes wrong, it can leave staging copies in /Library/Developer/CoreSimulator/Images/Inbox.
On one developer Mac these came to about 35 GB, and 16.9 GB of it was in a state no command could reclaim. Most of the work is knowing which pile you’re looking at, since the size on disk says nothing about whether it can go.
What gives the space back
Go through CoreSimulator, which owns these files. It keeps a registry, and deleting files behind its back leaves that registry listing runtimes that are no longer there.
- Open Xcode Settings → Components (Platforms in older releases). Keep the runtime versions your current tests need, and remove an unused one with its info or delete control.
- Before you erase or delete a simulated device, save the app data you need and quit any running simulators. Find the exact device with xcrun simctl list devices, then read xcrun simctl help erase or xcrun simctl help delete for the tools you have installed. Both commands throw away the device’s data.
- Removing the shared caches is optional, and more advanced. Check xcrun simctl runtime help first, because the dyld_shared_cache subcommands from our test depend on the tool version. The 3.04 GB we freed this way was temporary: booting a simulator rebuilds the caches it needs.
- Check free space again and launch a simulator you kept. If the space hasn’t come back, look at the current Components list and the error message instead of retrying a raw deletion. A removed registration doesn’t mean the payload is gone.
What resists deletion, and why
Runtime payloads under /System/Library/AssetsV2 carry the SIP restricted flag. Running xcrun simctl runtime delete <runtime UUID> frees the registration and unmounts the bundle, but the folder stays on disk and free space doesn’t change. We checked that twice on the same machine.
Staging copies in /Library/Developer/CoreSimulator/Images/Inbox are stranger. Two of them, 8.22 GB each, had no special flags, no extended attributes and no ACL, so SIP doesn’t protect them. Nothing referenced them either: hdiutil and diskutil showed nothing attached, and the runtime list reported zero disk images. They survived a reboot, and nothing we tried removed them. Running xcrun simctl runtime add <file> --move asks Apple’s own entitled daemon to relocate the image. It adopts the runtime and then prints "--move was specified but unable to remove original file: (1) Operation not permitted". If a daemon with more privilege than your shell can’t unlink the file, root’s rm won’t do better.
That’s what happened on one Mac with the operations we tested. It doesn’t prove that every protected or staging file is stuck for good on every version. If your result is different, go with current Xcode management and Apple’s support guidance.
The neighbours worth checking
Old Metal toolchains from other Xcode versions take about 670 MB each and can only be removed from the same Components pane, under the heading for other Xcode versions. The xcodebuild -deleteComponent command removes the current one and takes no version argument, so it can’t reach the leftovers.
DerivedData and Archives live somewhere else and follow their own rules. DerivedData is rebuildable and safe to remove when Xcode is closed. Archives hold the symbol files you need to read crash reports from a shipped build, so recent ones should stay.
How Mint handles it
Mint lists each piece of simulator storage with the action that applies to it. A runtime it can remove through CoreSimulator is offered that way. A payload under AssetsV2 shows its size and an explanation, with no checkbox, since a checkbox would promise a removal that can’t happen. When a staging copy has already refused your administrator password, Mint remembers it and won’t ask for the password again for that file.
An action can still be refused because of permissions, a running process or a change since the scan. Check the result instead of assuming every selected byte was freed.
Frequently asked questions
Can I just delete ~/Library/Developer/CoreSimulator by hand?
Don’t delete the whole CoreSimulator folder by hand. Find the device or runtime first, save any device data you need, and remove it with the controls your installed Xcode or simctl supports.
Why does deleting a runtime free less space than the runtime’s size?
A runtime’s registration, its mounted image and its payload are separate things. Remove it in Xcode’s component manager and check free space afterwards. In our test, the registration sometimes disappeared while the payload stayed.
Is it safe to remove the shared caches?
It worked on the Mac and tool versions we tested, with no simulator booted. Check the simctl runtime help for your installed version first. The caches a simulator needs get rebuilt, so the space you free is temporary.
What about the .cxbd files in the Inbox folder?
They can be staging copies left by a runtime installation. The copies on our test Mac resisted the operations described above, but that doesn’t mean every .cxbd file is unused or stuck for good. Check current Xcode management and Apple’s support guidance.
See which simulator files are on your Mac
Run a free local scan to sort simulator storage, protected files and other developer data before you choose what to do.