Simulators
Simulators you don't use, and the ones eating your memory
Simulator runtimes take several gigabytes each, devices outlive the runtimes they ran on, and a booted simulator can hold gigabytes of memory that macOS pushes to swap on your disk. DevSweeper shows all three.
Free to scan. Seven days of cleaning free, no card. macOS 26 or later.
Runtimes
DevSweeper asks xcrun simctl runtime list for the installed runtimes and marks the ones that can go:
- No simulator uses it. No available device runs on this runtime.
- Older version. A newer runtime of the same platform and major version is installed.
- Not ready. The runtime is in a broken or unfinished state.
- Not used lately. Its last use is older than your staleness window.
Removing one runs xcrun simctl runtime delete. You can download it again in Xcode › Settings › Components.
Devices
Unavailable simulators belong to runtimes that are no longer installed and can't boot. They are grouped into one row and removed together with xcrun simctl delete unavailable.
Old devices are listed one by one when they are shut down, hold at least 100 MB and haven't been used within your staleness window. Removing one runs xcrun simctl delete with its identifier, while Simulator is not running.
The shared ~/Library/Developer/CoreSimulator/Caches folder is a row of its own.
Booted simulators, memory and swap
Each booted simulator runs a tree of processes. DevSweeper adds up their memory and shows it next to your swap on disk and the memory pressure, with a Shut Down button per simulator, or for all of them. Shutting one down runs xcrun simctl shutdown: apps in it quit, nothing on disk changes, and you can boot it again from Xcode. This works without a licence.
When free space drops by 10 GB or more within an hour, DevSweeper sends a notification that names the cause: swap growth with the simulators holding memory, or new files.