Introduction

The iOS Simulator can consume a surprising amount of disk space because it is not just one app. Xcode stores simulator runtimes, device data, app containers, logs, caches, and derived build artifacts, so the right fix depends on which category is actually growing.

Where The Space Goes

Large simulator storage usually comes from four places:

• simulator runtimes installed by Xcode
• per-device data under CoreSimulator
• app build products and DerivedData
• old or unavailable simulator devices left behind after Xcode upgrades

Deleting the wrong directory can save space temporarily while breaking your workflow, so it is worth checking what exists first.

Inspect Installed Simulators

Use simctl to see the device inventory.

xcrun simctl list devices

This shows all known simulator devices, including old and unavailable ones. To see runtimes too:

xcrun simctl list

If you have many old runtime versions or unavailable devices, that is often the first cleanup target.

Remove Unavailable Devices

After Xcode upgrades, stale simulator entries commonly remain on disk. A safe first cleanup is:

xcrun simctl delete unavailable

This removes simulator devices that no longer correspond to an installed runtime. It usually frees space without touching the simulators you can still use.

Clear Simulator App Data

Each simulator can accumulate installed apps, caches, media, and database files. If a specific simulator has become bloated, erase its contents.

xcrun simctl erase all

That resets the simulated devices to a fresh state. It is useful when test apps or local databases are the main source of growth.

If you only want one device reset, find its identifier first and erase that specific simulator.

xcrun simctl list devices
xcrun simctl erase DEVICE-UUID-HERE

Clean Derived Data Too

Sometimes the simulator is blamed when the real disk usage is build output. Clear DerivedData to remove intermediate products and old debug artifacts.

rm -rf ~/Library/Developer/Xcode/DerivedData

This does not delete your source code or project settings. It only forces Xcode to rebuild the next time you compile.

Understand Runtime Size

A simulator runtime is effectively a full development image for a platform version. Keeping multiple iOS versions, watchOS versions, and tvOS versions can take many gigabytes. If you no longer test against an older runtime, removing it from Xcode settings can free much more space than deleting app data.

For teams, the right balance is usually:

• keep the current major runtime
• keep only the minimum older runtimes you actually support
• remove obsolete device sets and stale builds regularly

Example Maintenance Script

For manual maintenance, a simple shell session is usually enough.

1xcrun simctl list devices
2xcrun simctl delete unavailable
3xcrun simctl erase all
4rm -rf ~/Library/Developer/Xcode/DerivedData

This is not something to run blindly every day, but it is a practical reset when disk usage has drifted badly.

Common Pitfalls

The most common mistake is deleting simulator directories manually while Xcode is still running. That can leave CoreSimulator metadata inconsistent. Close Xcode and the Simulator app before doing aggressive cleanup.

Another mistake is confusing simulator storage with DerivedData. Both live under the developer directories and both can become large, but they are separate cleanup targets.

A third issue is removing runtimes that the team still depends on for compatibility testing. Disk savings are real, but so is the cost of re-downloading or losing test coverage.

Summary

• The iOS Simulator grows because of runtimes, device data, app data, and build artifacts.
• Use xcrun simctl list to see what is actually installed.
• 'xcrun simctl delete unavailable is a safe first cleanup step.'
• 'xcrun simctl erase all clears app data from simulator devices.'
• Cleaning DerivedData often matters as much as cleaning simulator state.