Open Disk Utility or About This Mac, notice tens of gigabytes missing, dig into ~/Library/Developer/CoreSimulator, and it hits you: your iOS simulator history has been silently accumulating data for every Xcode upgrade you have ever run. If CoreSimulator is taking up space on your Mac, you are not alone — and the fix is simpler than it looks, as long as you understand which simulators are safe to delete and which ones are not.
This guide explains exactly what lives inside the CoreSimulator folder, the difference between unavailable, shutdown, and in-use simulators, and how to reclaim that space safely — both from the Terminal and without it.
What Is the CoreSimulator Folder and Why Does It Get So Large?
The CoreSimulator folder lives at:
~/Library/Developer/CoreSimulator/
It has three main subdirectories worth knowing about:
- Devices/ — One folder per simulator device, identified by a UUID. Each contains a
data/directory that is essentially a full iOS file system: app sandboxes, preferences, photos, documents, and runtime state. A single device folder can be 2–5 GB. Multiply that by dozens of old simulators and you can easily reach 30–50 GB. - Caches/ — Runtime caches that Xcode regenerates on demand. Usually safe to delete, though Xcode will rebuild them on next launch.
- Temp/ — Transient working files. Generally small and safe to remove.
The Devices folder is where almost all the bulk lives. Every time you install a new version of Xcode or a new iOS simulator runtime, Xcode creates fresh default simulator devices. Old devices from prior SDK versions are not deleted automatically — they just sit there, consuming space.
Understanding Simulator States: Unavailable, Shutdown, and Booted
Before deleting anything, you need to understand the three states a simulator can be in. Run this in Terminal to see your full list:
xcrun simctl list devices
The output groups simulators by runtime (e.g., iOS 16.4, iOS 17.5, iOS 18.4) and tags each device with a state. Here is what those states mean:
| State | What it means | Safe to delete? |
|---|---|---|
| Unavailable | The runtime this simulator was created for is no longer installed (e.g., you deleted the iOS 15.5 runtime). The device folder still exists but the simulator cannot be booted. | Yes — these are orphans. |
| Shutdown | The runtime is present, the simulator has been used before, and it is not currently running. | Yes, if you no longer need it. Be cautious: any app data installed in it will be gone. |
| Booted | The simulator is currently running. Xcode has an open window for it. | No. Never delete a booted simulator. Quit Simulator first. |
Runtimes that are no longer installed leave behind "unavailable" orphan devices. These are the safest and easiest targets for cleanup.
How to Delete Unavailable Simulators with xcrun simctl
The fastest Terminal approach is the xcrun simctl delete unavailable command. It removes every simulator device whose corresponding runtime is not installed — exactly the orphaned folders described above.
- Quit the Simulator app completely (Cmd+Q or right-click its Dock icon).
- Quit Xcode if it is open.
- Open Terminal and run:
xcrun simctl delete unavailable
The command produces no output on success. To confirm what was removed, run xcrun simctl list devices again afterward — any runtimes that previously showed "(unavailable)" entries should now be gone.
If you want to go further and delete specific shutdown simulators you no longer use, list them first, note their UDID, then run:
xcrun simctl delete <UDID>
For example:
xcrun simctl delete A1B2C3D4-1234-5678-ABCD-000000000001
Deleting All Simulators (Nuclear Option)
There is a delete all variant:
xcrun simctl delete all
This removes every simulator device on your Mac, including ones that are currently useful. Xcode will recreate a default set of simulators for each installed runtime the next time it launches — but any custom device configurations, installed apps, or saved simulator state will be permanently lost. Use this only if you want a complete fresh start.
What About the CoreSimulator Devices Folder Directly?
You might be tempted to open ~/Library/Developer/CoreSimulator/Devices/ in Finder and start dragging UUID folders to the Trash. Do not do this.
CoreSimulator maintains an index of all registered devices in a device_set.plist file inside the Devices directory. If you manually delete a device folder without updating that index, CoreSimulator can get into an inconsistent state — Xcode may throw errors about missing devices, or the corrupted entry may prevent new simulators from being created cleanly.
Always use xcrun simctl delete to remove devices. It updates the index correctly.
Runtimes vs. Devices: The Other Source of Bulk
Simulator device folders are large, but simulator runtimes can be even larger. A runtime is the full operating system image that simulators run — typically 5–10 GB each for iOS. Runtimes are stored separately from the Devices folder, in:
~/Library/Developer/CoreSimulator/Caches/
or, on newer Xcode versions, as disk images under:
/Library/Developer/CoreSimulator/Volumes/
Deleting orphan simulator devices with simctl delete unavailable does not remove the runtime images themselves. To remove a runtime you no longer need, open Xcode, go to Settings > Platforms, and click the minus button next to any runtime you want to remove. This is the supported way to uninstall runtimes.
Alternatively, from Terminal:
xcrun simctl runtime delete <runtime-identifier>
List available runtime identifiers with:
xcrun simctl list runtimes
A Safer GUI Approach
If you would rather not work in Terminal, Crumb handles this as part of its one-click Clean. It identifies unused CoreSimulator device folders and Cryptex volumes, removes them, and automatically skips any simulator that is currently marked as in-use — so there is no risk of accidentally deleting a booted device mid-session.
Crumb's Visualize tab also shows a disk treemap so you can see exactly how much space the Developer folder is consuming relative to the rest of your drive, which makes it easy to spot whether simulators, Xcode build caches, or something else entirely is the real culprit. If you are ever unsure whether a specific folder is safe to remove, the built-in "Is this safe to delete?" AI will explain what the folder does and flag any risk before you commit.
You can download Crumb and use the free tier to run one cleanup and see how much space it recovers.
What Is Safe to Delete vs. What to Leave Alone
- Safe: Unavailable simulator devices (
xcrun simctl delete unavailable). - Safe with care: Shutdown simulator devices you no longer actively develop against. Any installed app data and simulator state inside them is permanently gone.
- Safe: Runtimes for iOS/watchOS/tvOS versions you will never target again, removed via Xcode Settings or
xcrun simctl runtime delete. - Safe: The
~/Library/Developer/CoreSimulator/Temp/folder. - Not safe: Booted (currently running) simulators.
- Not safe: Manually deleting UUID folders from the Devices directory in Finder — always go through simctl.
- Not safe: Deleting the
device_set.plistindex file directly.
Keeping CoreSimulator from Ballooning Again
A few habits that prevent the problem from recurring:
- When you update to a new major Xcode version, run
xcrun simctl delete unavailableas part of the upgrade. Old simulators tied to the previous runtime are immediately orphaned. - In Xcode Settings > Platforms, only install runtimes you are actively targeting. Each runtime you skip is 5–10 GB saved.
- If you use CI runners or run many builds locally, check
~/Library/Developer/Xcode/DerivedData/as well — it is separate from CoreSimulator but commonly reaches similar sizes.
Summary
The CoreSimulator folder grows because Xcode creates new simulator devices for every runtime version and never automatically removes the old ones. The single most impactful and safest command is xcrun simctl delete unavailable, which removes every orphaned device in one step without touching anything currently in use. For deeper cleanup — runtimes, build caches, and everything else in the Developer tree — combine that command with Xcode's Platforms panel and a disk visualizer so you can see exactly where your space went before you commit to deleting it.