Delete iOS simulators.
And the runtimes behind them.

Three different things take space

Commands

# see every simulator and its state
xcrun simctl list devices

# remove simulators whose runtime is no longer installed
xcrun simctl delete unavailable

# wipe one simulator's apps and data, keeping the device
xcrun simctl erase <device-udid>

# list and remove installed runtimes
xcrun simctl runtime list
xcrun simctl runtime delete <runtime-id>

Choose between erasing a device and removing a runtime

A simulator device is a particular virtual phone or tablet with its own installed apps and data. A runtime supplies the operating system that compatible devices use. Removing an unwanted device and removing an operating-system runtime therefore have different consequences. Work out which item is taking space and which capability you want to keep.

If you need a clean test state on one virtual phone, erasing that device may fit the job. If you no longer test an older operating-system version, inspect the runtime-management controls in Xcode. Do not delete the entire CoreSimulator folder as a shortcut; it can mix device state, caches and supporting data.

Inventory what you still test

Before changing anything, note the Xcode version you use, the target operating systems your project supports, and the devices involved in current testing. A simulator can look idle because you have not launched it today, while still holding a difficult-to-recreate reproduction case or a local test database.

Use the device list to identify names and identifiers. For commands that affect one device, match the identifier carefully instead of guessing from a similar name. Two virtual phones can have almost identical labels while running different runtimes. An example identifier in a tutorial is not an identifier you should paste unchanged.

Preserve the test state before erasing

Ask what would be lost: installed test apps, app settings, downloaded fixtures, sign-in state, screenshots or locally created records. Export anything you need through your test application’s supported route. A source repository alone may not contain the data needed to reproduce the bug you are investigating.

For team work, record the state in an issue or test note before removing it. Include the Xcode/runtime versions and the exact steps that produce the problem, without publishing private account information. A reproducible setup is more useful than a simulator that only one developer knows how to restore.

Example: keeping a current device and removing an obsolete one

Suppose you have one simulator used by today’s automated tests and another created for an older experiment. This is a fictional example. The older device may be a reasonable candidate if it contains no needed state and your current test matrix no longer depends on it.

Check the selected device and its runtime, shut down work using it, and read the consequence of the chosen action. Erasing its contents keeps a device shell but removes its app state; deleting a device removes that configured device. Neither decision proves that its runtime is also unwanted by other devices.

Review unavailable devices deliberately

The command that deletes unavailable devices is convenient because it acts on a category rather than one identifier. That convenience deserves an extra review. First inspect what your installed tools consider unavailable and why. A temporarily changed Xcode setup is different from a deliberate decision to stop supporting a runtime.

If you are uncertain, use Xcode’s management interface and work on one understood item. Do not combine bulk deletion, runtime removal and cache clearing into one unrecorded command sequence. You want to know which action removed which capability if a test environment later needs rebuilding.

Reclaim space without confusing the measurements

A device’s displayed data size is not necessarily the same as the runtime’s size or the storage newly available afterward. Several devices can depend on one runtime, and other developer activity may be writing to disk during the cleanup. Keep those measurements separate in your notes.

After a removal, verify the original goal. If you wanted one empty test device, launch it and install the test app again. If you removed an old runtime, confirm that a current supported device still launches. Then compare available disk space using the same measurement as before.

A practical maintenance checklist

1. Keep a list of operating-system versions that your project actually tests.
2. Keep a documented way to recreate important test data.
3. Review old devices at a convenient point between development tasks, not during an active failing test.
4. Remove or erase a specific understood item and record what you changed.
5. Verify a current simulator workflow before performing another cleanup category.

This is particularly helpful when Xcode is taking up disk space alongside DerivedData and Archives. Those categories serve different purposes, so review each according to its value instead of treating the entire Developer directory as one cache.

Questions about simulator cleanup

Will erasing a simulator delete my source project?

The source project and the simulator’s installed app data are different things. However, a simulator can contain test records or documents that are not in the project. Preserve those before erasing rather than assuming they are automatically backed up with your code.

Do I need to remove every old iOS runtime?

No. Keep runtimes required by your testing and support commitments. A runtime you rarely launch may still be necessary for investigating an issue reported by a user on an older supported version.

Why does the location differ from a tutorial?

Xcode and simulator storage management change across versions. Use Xcode’s current Components controls and the help from the installed simctl command. A filesystem path from another version is a clue to investigate, not a universal deletion target.

Can an erased test device be recovered?

Do not assume there is an undo operation for simulator erasure. Recreate the device and restore only data you deliberately exported or otherwise preserved. A cleaner’s Trash recovery feature does not make simulator erasure reversible.

Do devices and runtimes have the same backup needs?

No. A runtime can often be obtained again through a supported Xcode installation route, while a particular simulator’s local app data may have no equivalent recovery source. Document how you seed test records and avoid relying on one developer’s long-lived virtual device as the only copy of a reproduction environment.

For automated tests, check the device identifiers and runtime requirements used by the test configuration before changing the inventory. Removing a device that a script names explicitly can break the script even when another apparently equivalent device remains. Update that configuration deliberately and rerun the relevant non-destructive test workflow. This connects storage maintenance to a working development setup rather than treating a smaller directory as the only success criterion.

Does shutting down a simulator remove its data?

No. Shutting down a virtual device stops that session; it is not the same action as erasing or deleting the device. This distinction lets you stop active work before reviewing storage while retaining the state you may still need. Read the selected operation's confirmation instead of inferring its effect from whether a simulator window is open.

References

• Apple: additional Xcode components