Simulators and DeviceSupport.
Xcode's other half.

The Xcode app in /Applications is only part of it. Most of the space Xcode uses builds up over time in your Library folder: build output, simulators and the operating systems they run, symbols copied from your devices, and every archive you ever made. A first look, smallest to largest:

du -sh ~/Library/Developer/* ~/Library/Developer/Xcode/* 2>/dev/null | sort -h

DerivedData has a guide of its own. This one covers the rest.

~/Library/Developer/CoreSimulator/Devices holds one folder per simulator, named by its UDID. Inside is a device.plist describing it and a data folder that is the simulator's disk: the apps you installed, their containers, photos, caches and everything your app wrote while you tested it. A simulator you used for months can hold several gigabytes.

To see which UDID is which device, and which ones are booted:

xcrun simctl list devices

To see the size of each folder, then look up a UDID:

du -sh ~/Library/Developer/CoreSimulator/Devices/* | sort -h
xcrun simctl list devices | grep <UDID>

In current Xcode versions, xcrun simctl list devices -j also prints each device's dataPathSize and lastBootedAt, the date it was last started. A simulator you have not started in months is a good candidate to remove.

Two more device sets live outside this folder. Parallel testing clones simulators into ~/Library/Developer/XCTestDevices, and SwiftUI previews keep their own in ~/Library/Developer/Xcode/UserData/Previews. simctl reaches them with --set:

xcrun simctl --set testing list devices
xcrun simctl --set previews list devices

Use simctl rather than deleting folders by hand, so CoreSimulator's list of devices stays consistent with what is on disk. Start with the devices that can't run anyway:

xcrun simctl delete unavailable

In simctl's own words, this deletes “devices that are not supported by the current Xcode SDK”: typically simulators for an iOS version whose runtime you no longer have. They can't start, so nothing usable is lost.

To remove specific devices, pass their UDIDs. Shut a booted one down first with xcrun simctl shutdown <UDID>.

xcrun simctl delete <UDID> [<UDID> …]

This deletes the device with every app and file in it. If you only want the space its data takes and want to keep the device itself, erase it instead. That is the same as Device → Erase All Content and Settings in the Simulator app:

xcrun simctl erase <UDID>

Before either, think about what is inside. Test accounts you signed in to, a database you seeded by hand, a reproduction of a bug: none of that is in your project, and none of it comes back. Xcode's Window → Devices and Simulators shows the same devices if you prefer to manage them there.

A simulator is small without the operating system it runs. That operating system, the runtime, is a separate download per platform and version, and each one takes gigabytes. To see what you have and how big each is:

xcrun simctl runtime list

Downloaded runtimes are disk images, mounted read-only under /Library/Developer/CoreSimulator/Volumes. That is why the folder can look huge in a disk analyzer: it shows the contents of a mounted image, not extra space. The image itself lives elsewhere; xcrun simctl runtime list -v prints its Image Path. Don't delete anything in these folders by hand. Next to them, /Library/Developer/CoreSimulator/Caches holds shared caches built for the installed runtimes.

The supported way to remove a runtime is Xcode → Settings → Components. Apple's guide to Xcode components lists simulator runtimes under Other Installed Platforms; click the information button next to one and choose Delete. The panel also shows how much space each one frees. From Terminal, simctl can delete by identifier, or every runtime not used for a number of days. Try it with --dry-run first, which only prints what it would delete:

xcrun simctl runtime delete --notUsedSinceDays 90 --dry-run
xcrun simctl runtime delete <identifier>

A runtime you delete can be downloaded again from the same Components panel, or with xcodebuild -downloadPlatform iOS. Simulators that used it become unavailable; clear them with xcrun simctl delete unavailable afterwards.

When you connect an iPhone or iPad running an OS version Xcode has not seen before, Xcode shows “Copying shared cache symbols” and copies that version's system symbols to ~/Library/Developer/Xcode/iOS DeviceSupport. It needs them to debug on the device and to show readable system frames in crash logs from that OS version. Apple Watch and Apple TV get their own folders next to it, watchOS DeviceSupport and tvOS DeviceSupport.

Every OS version on every device you test with adds a folder, and old ones stay until you remove them. To see them:

du -sh ~/Library/Developer/Xcode/*DeviceSupport/* | sort -h

Folders for OS versions no device of yours runs any more are safe to delete. If you delete the one for a device you still use, Xcode copies the symbols again the next time you connect it, which takes a while before you can debug. Delete by folder, quoting the path because of the space:

rm -rf ~/Library/Developer/Xcode/"iOS DeviceSupport"/"<folder name>"

Not without thinking. ~/Library/Developer/Xcode/Archives holds the .xcarchive made each time you chose Product → Archive. An archive contains the build you shipped and its dSYM files, which turn crash report addresses back into function names and line numbers. Apple says it plainly in Building your app to include debugging information: you must retain the Xcode archive for each build of your app you distribute, or you might not be able to diagnose an issue from crash reports.

Archives are your data, not a cache. Nothing recreates them. Review them in Window → Organizer → Archives. Archives of builds that never shipped, like a failed upload or a local test, can go. For builds people still run, move the archives to an external disk or other storage you trust instead of deleting them.

~/Library/Caches/com.apple.dt.Xcode is Xcode's own cache. It is safe to delete while Xcode is closed and is recreated when needed. ~/Library/Developer/CoreSimulator/Caches holds caches the simulators build for themselves and is regenerated the same way.

If you keep more than one Xcode, such as a beta next to the release, each copy in /Applications takes its full size. Removing a version you no longer build with is often the single biggest win, and is worth checking alongside the folders above. Docker, Gradle and package caches are covered in what is in System Data and “Your disk is almost full”.

Specula measures each of these locations and labels it: simulator devices as app data, Device Support and the Xcode and simulator caches as regenerable, and archives as your data, with a note that they hold the dSYMs needed to symbolicate crashes. Your data never goes in the one-click plan and can only be moved to the Trash.

The Clean Up plan runs xcrun simctl delete unavailable as its own action, listing the devices whose OS version is no longer installed. Simulators not started for 30 days, by lastBootedAt or, for one never started, the date of its data folder, are offered unchecked. Booted simulators are never offered, and right before deleting, Specula asks simctl again and keeps any device that is running or was started in the meantime. Device Support is offered unchecked too, because getting it back means reconnecting each device.