Which Xcode Simulators, Runtimes and DeviceSupport Folders Can You Delete?

$ du -sh ~/Library/Developer/CoreSimulator/Devices
$ xcrun simctl runtime list
$ du -sh /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime
$ du -sh ~/Library/Developer/Xcode/*DeviceSupport
$ diskutil info / | grep "Container Free Space"

A du of the home folder, as in What’s Taking Up All the Space on My Developer Mac?, shows two of Xcode’s three places. The third, simulator runtimes, lives outside the home folder. To get a real before-and-after without touching anything I use, I installed a watchOS 27.0 runtime for this page and removed it again. This is part of a series on cleaning up a developer Mac’s disk, and each part stands alone.

Check how much space simulators and DeviceSupport use

Xcode keeps simulator devices, simulator runtimes and DeviceSupport in three places, and each holds something different:

Record the free space first, so you can check the result later:

$ diskutil info / | grep "Container Free Space"

Then measure the folders. These commands only read:

$ du -sh ~/Library/Developer/CoreSimulator/Devices
$ du -sh ~/Library/Developer/Xcode/*DeviceSupport
$ du -sh ~/Library/Developer/Xcode/DerivedData ~/Library/Developer/Xcode/Archives

du -h and simctl print binary units, so every G they print on this page is GiB; diskutil prints decimal GB. On my Mac, devices were 44 GiB, iOS DeviceSupport 35 GiB and tvOS DeviceSupport 6.6 GiB. DerivedData was 0B and Archives 10M, so those weren’t the problem here; check yours, because on a Mac that builds a lot they can be. The runtimes totaled 22.3G by simctl’s count, which the next section shows how to read. Devices, both DeviceSupport folders and runtimes came to about 108 GiB.

Find where simulator runtimes live and size them

Runtimes are disk images, and macOS mounts them read-only. List them:

$ xcrun simctl runtime list

== Disk Images ==
-- iOS --
iOS 27.0 (24A434) - <runtime-id> (Ready)
iOS 26.5 (23F77) - <runtime-id> (Ready)
-- tvOS --
tvOS 27.0 (24J360) - <runtime-id> (Ready)
tvOS 26.5 (23L470) - <runtime-id> (Ready)

Total Disk Images: 4 (22.3G)

Run it again with -v for each image’s details. The -v output adds a Last Used At line per image. It also gives an Image Path under /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime/ and a Mount Path: under /Library/Developer/CoreSimulator/Volumes/ for the iOS and tvOS images here, and under /private/var/run/com.apple.security.cryptexd/mnt/ for the watchOS one. The image path is where the bytes are, so size the runtime images there:

$ du -sh /System/Library/AssetsV2/com_apple_MobileAsset_*SimulatorRuntime

Here that printed 15G for the iOS runtime images and 6.9G for the tvOS ones. These figures are rounded and come from a different tool than the 22.3G total above. Because the images live outside your home folder, a du of ~ never counts them.

Do not run du on a mount path. du -sh /Library/Developer/CoreSimulator/Volumes printed 48G on this Mac, but that isn’t disk use. du walks into each mounted image and counts its unpacked contents, which are already counted in the runtime images. Adding it to the totals counts the runtimes twice, and then some.

Delete simulator devices you no longer use

List the devices, grouped by runtime:

$ xcrun simctl list devices

I had 27: 11 each on iOS 26.5 and iOS 27.0, 3 on tvOS 26.5 and 2 on tvOS 27.0. A device is worth keeping if you run a test or a preview on it. To see which ones are large, size each device folder; the folder name is the device’s UDID, which the list prints in parentheses:

$ du -sh ~/Library/Developer/CoreSimulator/Devices/* | sort -hr | head

By runtime, the iOS 26.5 devices took 19.9 GiB, iOS 27.0 19.1 GiB, tvOS 26.5 3.6 GiB and tvOS 27.0 1.3 GiB. The largest single device was 5.0 GiB. For scale, one watchOS device I booted for about 80 seconds grew from 8 KiB to 546 MiB. If you no longer test on a runtime, its devices are the candidates, and so is the runtime itself.

Deleting a device removes its installed apps and data. Two commands delete devices. xcrun simctl delete <UDID> removes the devices you name. Use the UDID, not the name, because the same device name appears under every runtime. There’s no undo, so copy out any test data you want first. xcrun simctl delete unavailable removes devices that the current Xcode SDK doesn’t support, according to xcrun simctl help delete. Check what it would remove before you run it:

$ xcrun simctl list devices unavailable

== Devices ==
-- iOS 26.5 --
-- iOS 27.0 --
-- tvOS 26.5 --
-- tvOS 27.0 --

If every group is empty, as here, delete unavailable removes nothing.

Delete simulator runtimes you no longer use

A runtime is in use if a test target needs that OS version or a device you keep still runs on it. Last Used At in xcrun simctl runtime list -v shows when each image was last used.

xcrun simctl runtime delete removes one. It takes an identifier from the list, or a filter: --notUsedSinceDays <days>, --unusable or --outdated. Add --dry-run and it prints what it would delete and deletes nothing:

$ xcrun simctl runtime delete --notUsedSinceDays 90 --dry-run

When the dry run lists what you expect, run the same command without --dry-run, or pass an identifier from xcrun simctl runtime list to remove a single image. Read the whole dry-run list first: a filter can match several runtimes, and each one is a multi-GB download if you need that OS version again. xcrun simctl help runtime says the delete shuts down any booted simulators and unmounts the image first. In my run, a tvOS simulator booted on a different runtime stayed booted, so I can’t say which ones it stops. Shut down any simulator holding state you care about first.

$ xcrun simctl runtime delete <identifier>

Use this command, not rm. The images are mounted and managed by the system, so they aren’t folders to remove by hand. To get a runtime back, run xcodebuild -downloadPlatform <iOS|watchOS|tvOS|visionOS>, as in Apple’s Installing additional simulator runtimes (opens in a new tab).

Why a deleted simulator runtime can keep its disk space

A runtime can leave xcrun simctl runtime list while its image stays mounted and keeps its space. Do not read the runtime list as proof you got the space back. Check that the image has left mount and that Container Free Space has risen, and if it hasn’t, reread it later and after a restart.

The watchOS 27.0 runtime I installed for this page was a 3.83 GB download; xcrun simctl runtime list -v sized it at 3.6G (GiB), and it cut Container Free Space from 83.9 GB to 80.1 GB. After a dry run that named only that runtime, xcrun simctl runtime delete <identifier> took it off the list within five minutes, but Container Free Space didn’t rise by those 3.8 GB in the next 21 minutes. The backing folder under /System/Library/AssetsV2 still measured 3,736,360 KiB (3.56 GiB), and the image was still in mount, held by a SimLaunchHost.arm64 process that had a library from it mapped. xcrun simctl shutdown all didn’t release it. Stopping that process left nothing holding the image, but the image stayed mounted and the space stayed in use for the nine minutes I watched. I didn’t test a restart, unmounting the image or restarting the CoreSimulator service, so I can’t say what finally frees it.

Delete DeviceSupport folders you no longer need

DeviceSupport holds debug symbols copied from physical devices you connected. Each folder is named for the device model, the OS version and the build, and there’s one per combination. My iOS DeviceSupport had six folders, at 5.4G to 6.6G each, and tvOS DeviceSupport had two, at 3.4G and 3.2G.

$ ls ~/Library/Developer/Xcode/iOS\ DeviceSupport

<model> 26.6 (<build>)
<model> 27.0 (<build>)

A folder is needed while a connected device still runs that OS version, or while you still read crash reports from that version. Xcode uses these symbols to name the system framework frames in a report, and Apple’s crash report documentation (opens in a new tab) says to download the device symbols for the report’s OS version if it can’t. List your connected and paired devices from the terminal, then check each one’s OS version on the device itself:

$ xcrun devicectl list devices

Any folder for a version no device runs now, and that no crash report you still read comes from, is a candidate. If every device you connect is on 27, that’s the five iOS 26.x folders (28.1 GiB) and both tvOS 26.6 folders (6.6 GiB). I kept all of mine, because I still need 26.x.

simctl doesn’t manage these; they’re plain folders. Move the one you chose to the Trash in Finder, which leaves you an undo, and empty the Trash after you confirm Xcode still works. Once it’s gone, a crash report from a device you no longer have can’t be symbolicated from it. I haven’t tested what Xcode does the next time you connect a device whose folder you removed, so remove one and check before you clear several.

Check how much space you got back

Run the same command you started with:

$ diskutil info / | grep "Container Free Space"

Mine read 83.9 GB before the watchOS run. Other work on the Mac moves this figure by up to about 1 GB with no action of yours, so a change under that is noise. Reread after a restart if a runtime delete hasn’t returned its space. Do not expect the change to match the du totals. Only the container’s figure says what the Mac got back.

Do this with a coding agent

Paste this prompt into your own local coding agent. It measures and recommends, and it removes nothing until you say what to remove:

Measure Xcode's disk use on this Mac. Report only; delete nothing until I
name what to remove.

1. Run diskutil info / and record Container Free Space.
2. Measure three places separately: simulator devices
   (~/Library/Developer/CoreSimulator/Devices), simulator runtimes, and
   DeviceSupport (~/Library/Developer/Xcode/*DeviceSupport). For runtimes,
   use xcrun simctl runtime list -v and measure each runtime image
   under /System/Library/AssetsV2. Do not run du on
   /Library/Developer/CoreSimulator/Volumes; it walks into the mounted
   images and overstates the size.
3. For devices, list them with xcrun simctl list devices, group them by
   runtime and report the size of each group. Also run
   xcrun simctl list devices unavailable.
4. List my connected devices (xcrun devicectl list devices) and ask me for
   the OS version of each; do not infer it. Also report which OS versions my test targets and deployment targets
   need, from the projects I name or from the project files you can find.
5. Recommend removal candidates with a reason for each: devices and runtimes
   no target uses, and DeviceSupport folders for OS versions no connected
   device runs. Ask me whether I still read crash reports from those
   versions, because Xcode needs the folder to symbolicate them. For devices and runtimes, give the simctl command (xcrun
   simctl delete <UDID>, or xcrun simctl runtime delete <identifier> after
   the same command with --dry-run). For DeviceSupport folders, name the
   folder; there is no Apple removal command, and Xcode's behaviour when
   that device reconnects is untested, so propose one folder first. Warn me
   that deleting a device removes its apps and data, and that runtime
   deletion can shut down booted simulators.
6. After a runtime deletion, expect the space to come back late or not
   until a restart: reread Container Free Space more than once, and check
   whether the image is still mounted (mount | grep -i <platform>).
7. Note that a du total is not what deleting frees; only the change in
   Container Free Space is.

Then stop and wait. After I name what to remove, run only those removals,
one at a time, with --dry-run first for runtimes, and stop if any output is
not what you expected. Then read Container Free Space again and report the
difference.

Common failures

du reports the CoreSimulator/Volumes folder as larger than the runtimes

du followed the mounts into the runtime images and counted their contents. Measure the runtime images under /System/Library/AssetsV2 instead, as in the section on where simulator runtimes live.

Runtime deleted but the space didn’t come back

xcrun simctl runtime list no longer shows the runtime, yet Container Free Space hasn’t risen and the folder under /System/Library/AssetsV2 is the same size. The image can stay mounted while a SimLaunchHost process has a file from it open. Check with mount | grep -i <platform> and lsof +D <mount path>. In my run, shutting down all simulators and stopping that process still didn’t free it, and I didn’t test a restart. See the section on why a deleted runtime can keep its disk space.