How do I reclaim disk space from Xcode simulators?

A senior iOS dev posted a screenshot to the Apple Developer Forums last year: 18 GB of simulator data the Xcode UI refused to show and the standard cleanup commands could not touch. The thread is still open. The Apple replies offered no fix beyond rebooting and reinstalling Xcode. The original poster ended up grepping the filesystem by hand to find the rogue devices, then deleting them with rm -rf because nothing else worked.

That story is the floor, not the ceiling. A Mac that has hosted three or four major Xcode versions usually carries 60 to 120 GB across the four folders Apple uses to back the iOS, iPadOS, watchOS, and tvOS simulators. If you searched for how to reclaim disk from Xcode simulators, the storage panel is not going to help you. There is no Manage button for CoreSimulator, no progress bar, no path list. Reclaiming the disk means knowing the four folders, the safe order, and the one runtime cache simctl will not touch.

Where do Xcode simulators actually live on disk?

The Xcode UI hides the path layout because Apple wants the simulator to feel like an appliance. On disk it is four distinct folders, each owned by a different component, each with its own growth pattern.

The folders under /Library/ and /System/ are not in your home directory, which is why most "free up Mac disk space" guides ignore them. They are also where the largest reclaimable wins hide on a Mac that has been through multiple Xcode majors.

What does xcrun simctl delete unavailable actually clear?

This is the first command every guide recommends and the only one Xcode itself ships. It is also the easiest to misunderstand. The xcrun simctl delete unavailable guide covers every flag in depth. The short version for reclaiming disk:

# See what simctl currently considers "available"
xcrun simctl list devices available

# Delete every device whose runtime is missing from this Xcode
xcrun simctl delete unavailable

# Optional: shut down everything that is still booted first
xcrun simctl shutdown all

delete unavailable only removes device folders whose runtime is no longer installed in your current Xcode. It does not delete the runtimes. It does not touch XCTestDevices. It does not look at the CoreSimulator/Caches folder. On a Mac that just upgraded from Xcode 16 to Xcode 26, you might reclaim 10 to 20 GB with this one command. On a Mac that has stayed on the same Xcode major, it will reclaim almost nothing, because every device still has a matching runtime.

That is the trap. People run delete unavailable, see "nothing freed", and assume the simulators are not the problem. They almost always are.

Which folder gives you the biggest reclaim?

For most working iOS devs, the biggest single win is the Devices/ folder. Each booted simulator has its own copy of the runtime DMG mounted into a writable container, plus every app you ever installed for QA. On a busy project you might have a dozen devices, each holding 2 to 5 GB. After delete unavailable, the right next step is to walk the device list and remove the ones you no longer test against.

# List every device with its UUID and runtime
xcrun simctl list devices

# Delete a specific device by UUID (replace with one from the list)
xcrun simctl delete A1B2C3D4-1111-2222-3333-444455556666

# Or nuke a specific device by name
xcrun simctl delete "iPhone 14 Pro"

# Move the whole CoreSimulator devices folder to Trash for a clean slate
mv ~/Library/Developer/CoreSimulator/Devices ~/.Trash/Devices-$(date +%s)

The last command is the nuclear option. It is safe in the sense that Xcode will recreate any device on the next launch, but it destroys per-simulator UserDefaults, Keychain items, and installed builds. If you do QA against specific simulator states, snapshot what you need first or stick to per-device deletion.

What about the runtime images and the AssetsV2 orphans?

This is where the Apple Developer Forums thread on orphaned runtimes gets relevant. When you change Xcode versions, the old runtime DMGs sometimes stay mounted in /Library/Developer/CoreSimulator/Volumes/ and /System/Library/AssetsV2/. The Xcode > Settings > Platforms panel will not show them. simctl runtime list may or may not show them depending on which Xcode binary you call.

Walk both folders by hand.

# Installed runtimes Xcode currently exposes
xcrun simctl runtime list -v

# Mounted runtime volumes on disk
ls -lh /Library/Developer/CoreSimulator/Volumes/

# The asset cache where orphans hide
sudo du -sh /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime
sudo du -sh /System/Library/AssetsV2/com_apple_MobileAsset_watchOSSimulatorRuntime
sudo du -sh /System/Library/AssetsV2/com_apple_MobileAsset_tvOSSimulatorRuntime

If simctl runtime list shows three runtimes but Volumes/ shows seven, you have orphans. The safe removal path is to delete by identifier rather than rm -rf on the volume:

# Delete a runtime by its identifier (from simctl runtime list)
xcrun simctl runtime delete <UUID>

# If simctl refuses (the orphan case), unmount and remove the DMG
# Replace <volume> with the path from ls -lh above
sudo umount "/Library/Developer/CoreSimulator/Volumes/<volume>"
sudo rm "/Library/Developer/CoreSimulator/Cryptex/<UUID>.cryptex"

The unmount path is the one the Apple forum thread points at. Do it slowly. Do not run a blanket rm -rf on /Library/Developer/ or you will take out the working runtimes alongside the orphans. The safely delete Xcode DerivedData post has the same theme for build data, with the same rule of thumb: identify, then remove, then verify Xcode still launches.

Why does XCTestDevices exist as a separate folder?

~/Library/Developer/XCTestDevices/ is the simulator pool used by xcodebuild test and swift test. It is created on first run and grows quietly. Each invocation can spin up a fresh throwaway device, and unless your CI cleans up between runs, the folder accumulates. I have seen 8 GB of XCTestDevices on a Mac whose owner had never opened the simulator UI manually, and every byte came from swift test runs.

du -sh ~/Library/Developer/XCTestDevices

# Safe full-wipe: Trash, do not rm
mv ~/Library/Developer/XCTestDevices ~/.Trash/XCTestDevices-$(date +%s)

The folder regenerates on the next swift test or xcodebuild test invocation, so there is no recoverable state to protect. If your CI runner does this, you should also clean it on the CI host.

What is the safe order to actually reclaim the disk?

Reclaiming Xcode simulator disk is one of the highest size-to-safety ratio cleanups on a developer Mac, but only if you walk the folders in the right order. Skip a step and you either reclaim almost nothing or break a working setup.

1. Quit Xcode and any Simulator.app windows. CoreSimulator processes hold file handles open and refuse to release them while devices are booted.
2. Run xcrun simctl shutdown all to belt-and-brace any booted runtimes.
3. Run xcrun simctl delete unavailable. Note the freed size.
4. List ~/Library/Developer/CoreSimulator/Devices/ and delete the per-UUID folders for devices you do not actively test against. Move to Trash, do not rm -rf.
5. Trash ~/Library/Developer/CoreSimulator/Caches/dyld/. It rebuilds on next simulator boot.
6. Trash ~/Library/Developer/XCTestDevices/ if you use Swift Package or xcodebuild tests.
7. Audit /Library/Developer/CoreSimulator/Volumes/ and /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime for orphan runtimes. Remove via xcrun simctl runtime delete <UUID> first, fall back to umount + Trash only for orphans simctl will not address.
8. Empty Trash to reclaim the space. The Finder progress bar is the receipt.

On a Mac that has been through Xcode 15, 16, and 26 without ever doing this, the eight steps usually total 40 to 100 GB. On a Mac that runs CI locally with swift test, add another 5 to 15 GB from XCTestDevices.

What does CleanMyDev do that the script does not?

The script above works. It is also a half hour of attention and a sudo password you should not be giving to commands you do not understand. CleanMyDev is the same eight steps wrapped in a UI that:

• Sizes every simulator folder before you touch anything, including the AssetsV2 orphans most cleaners do not look at.
• Shows the runtime identifier, the last-booted date, and the device UUIDs as a flat list you can sort by size.
• Moves to Trash by default. Never sudo, never blanket rm -rf.
• Skips simctl entirely for the orphan case, because simctl is the thing that broke for the 18 GB hidden simulators in the first place.

If you want the receipt-driven version of the cleanup walk in this post, grab CleanMyDev for $9.99 lifetime. It is the same paths, with the audit step done for you before deletion.

Related reading

• How do I safely delete Xcode DerivedData?, the build cache half of the same cleanup story.
• The complete xcrun simctl delete unavailable guide, every flag, every edge case, every thing it does not touch.
• Orphaned simulator runtimes on Mac, the AssetsV2 hunt in detail.