Developer cleanup

CoreSimulator Taking Up Space? Delete Unused iOS Simulators Safely

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.

  1. Quit the Simulator app completely (Cmd+Q or right-click its Dock icon).
  2. Quit Xcode if it is open.
  3. 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.plist index 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 unavailable as 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.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

How do I find out how much space CoreSimulator is using?
Open Terminal and run: du -sh ~/Library/Developer/CoreSimulator/. This gives you the total. For a breakdown by subfolder, run du -sh ~/Library/Developer/CoreSimulator/*/ to see Devices, Caches, and Temp separately. The Devices subfolder is almost always the largest.
Will deleting unused simulators affect my Xcode projects or code?
No. Simulator devices only store runtime data: installed apps, simulator settings, photos, and sandboxed app data. Your Xcode project files, source code, and build settings are stored elsewhere and are completely unaffected.
What is the difference between xcrun simctl delete unavailable and xcrun simctl delete all?
delete unavailable removes only orphaned simulators — ones whose iOS/watchOS runtime is no longer installed. delete all removes every simulator device on your Mac, including ones tied to currently installed runtimes. Xcode will recreate a default set on next launch, but any custom simulator configurations and installed app data will be gone permanently.
Can I delete CoreSimulator device folders manually in Finder?
You should not. CoreSimulator tracks all devices in an index file (device_set.plist). Deleting UUID folders directly in Finder bypasses that index and can leave Xcode in a broken state. Always use xcrun simctl delete to remove devices so the index stays consistent.