Every simulator you've ever created in Xcode — for every device type, every iOS version — is a real disk image sitting on your Mac, complete with its own filesystem, its own installed apps, and its own accumulated data. Xcode's UI makes creating a new simulator effortless and deleting an old one easy to forget. The result, on a Mac that has been through several Xcode and iOS SDK updates, is a CoreSimulator folder that quietly holds tens of gigabytes of simulators nobody has launched in over a year.
Where simulators actually live
Every simulator device Xcode has ever created lives under ~/Library/Developer/CoreSimulator/Devices/, one folder per simulator instance, named with a UUID rather than anything human-readable. Inside each one is a full disk image representing that simulator's storage — its installed apps, its Springboard state, any data those apps have written, formatted the same conceptual way a real device's storage would be.
You won't easily tell from folder names alone which UUID corresponds to which simulator. The command line is the practical way to inspect what's actually there:
xcrun simctl list devices
This prints every simulator Xcode currently knows about, grouped by iOS version, along with each one's state (booted, shutdown) and whether it's marked (unavailable) — meaning the iOS runtime it was created for is no longer installed.
xcrun simctl delete unavailable
xcrun simctl delete unavailable
This is the single most useful cleanup command in the whole simulator ecosystem. Every time you update Xcode and it installs a new iOS simulator runtime, old simulators tied to a runtime you've since removed become orphaned — they still exist as disk images, but Xcode can no longer launch them because the underlying OS version is gone. This command finds every such orphaned simulator and deletes it in one pass, with no risk to any simulator tied to a runtime you still have installed.
This is safe to run at any time and worth doing immediately after any Xcode update that changes your installed simulator runtimes.
xcrun simctl erase all
xcrun simctl erase all
A different kind of cleanup: this resets every simulator — the ones that are still available and usable — back to a factory-fresh state, wiping installed apps and any data they'd written, without deleting the simulators themselves. Useful when simulators have accumulated years of test app installs and cached data that inflate their individual disk images, but you still want the simulator devices themselves to exist and be launchable afterward.
The distinction matters: delete unavailable removes simulators you can no longer use anyway; erase all keeps your simulators but empties them out, similar in spirit to a factory reset on a physical device.
Deleting a specific simulator
If you want to remove one particular simulator rather than everything unavailable or everything at once:
xcrun simctl list devices
xcrun simctl delete <device-udid>
Grab the UUID from the list output for the specific device and iOS version combination you want gone.
Managing simulator runtimes themselves
Beyond individual simulator devices, Xcode also downloads and stores entire simulator runtimes — the actual iOS (or watchOS, tvOS) system images that simulators run on top of. These are separate from individual device instances and can be managed through Xcode → Settings → Platforms, where you can see every installed runtime and its size, and remove ones you no longer need. A single iOS runtime image commonly runs several gigabytes on its own, before any simulator devices are even created from it.
If you frequently update Xcode, it's common to accumulate simulator runtimes for iOS versions two or three releases behind your current target, each one sitting unused after the first testing pass against a new release cycle finished.
A comparison of what each approach clears
| Command / action | What it removes | What it keeps |
|---|---|---|
xcrun simctl delete unavailable |
Simulators tied to removed runtimes | All simulators on currently installed runtimes |
xcrun simctl erase all |
App data and installed apps inside every simulator | The simulator devices themselves |
xcrun simctl delete <udid> |
One specific simulator | Everything else |
| Xcode → Settings → Platforms, remove a runtime | An entire iOS/watchOS/tvOS runtime image, plus any simulators built on it | Other installed runtimes |
Simulator content grows the same way an app's data would on a real device
It's worth remembering that a simulator is a genuinely complete environment, not a lightweight stub — every app you've installed to test on it, every photo you've dragged into its Photos app for testing an image picker flow, every SQLite database or cache your app has written while running there, persists exactly the way it would on physical hardware, and counts toward that simulator's disk image size. A simulator you've used heavily for testing a photo-heavy or offline-data-heavy app can grow substantially larger than a simulator you've only used to check basic layout, even though both started from the same base runtime image.
This is part of why erase all can reclaim more space than you'd expect from what seems like "just a simulator" — you're not clearing a cache in the traditional sense, you're wiping an entire accumulated device state, app data included.
A practical routine
xcrun simctl delete unavailableimmediately, since this has effectively no downside.xcrun simctl list devicesto review what's left and spot simulators you haven't used in a long time despite their runtime still being installed.- Delete specific old simulators by UUID if you recognise ones you don't need.
- Check Xcode → Settings → Platforms for old simulator runtimes several iOS versions behind your current work, and remove any you're confident you won't need to test against again.
xcrun simctl erase allif disk space is tight and you're willing to lose current simulator app data, keeping the devices themselves for future use.
This is a low-risk area to clean aggressively — every simulator and runtime is fully re-creatable through Xcode's own download mechanism, and none of it represents data you've made rather than data Apple or Xcode provided.
Where VolumeLens fits in
~/Library/Developer/CoreSimulator/Devices is one of the largest and least self-explanatory folders on any iOS developer's Mac, since its contents are named by UUID rather than anything recognisable. VolumeLens shows the total size honestly in a normal scan, sitting alongside DerivedData, Archives, and iOS DeviceSupport, so you can judge at a glance whether a simctl cleanup pass is worth your time before running it. Compare the free and Pro tiers to see what Insights adds on top of the scan.