Reclaim tens of gigabytes from Xcode

Why Xcode fills your disk

Xcode is built to be fast and convenient, and both of those cost disk. It caches build output so rebuilds are quick, keeps every simulator you have ever run so you can test old OS versions, and downloads a fresh set of debug symbols each time you plug in a device running a new iOS build. None of this is ever cleaned up automatically. It just grows, quietly, for years.

The reassuring part is that nearly all of it is derived data in the general sense: made from your source code, your Apple account, or Apple's servers, and therefore reproducible. Deleting it costs time, not work. Let us go through each place, largest payoff first.

1. DerivedData — the big one

Every project you build leaves a folder in ~/Library/Developer/Xcode/DerivedData, named after the project plus a hash. Inside are build products, intermediate object files, precompiled headers, the module cache, logs, and the code-completion and indexing database. What it never contains is your source code. In System Settings this shows up under Developer as "Project Build Data and Indexes."

Xcode never garbage-collects these, so folders for projects you deleted years ago are often still there. This is usually the single largest reclaim.

# see what each project's DerivedData costs
$ du -sh ~/Library/Developer/Xcode/DerivedData/*

# clear it all (safe: source is untouched)
$ rm -rf ~/Library/Developer/Xcode/DerivedData/*

2. iOS DeviceSupport — invisible and large

The first time you connect a physical device running a particular iOS build, Xcode downloads a matching set of debug symbols so it can debug against that exact OS. These land in ~/Library/Developer/Xcode/iOS DeviceSupport, one folder per build, and they are never removed. Because they are keyed to the full build number, every minor iOS update triggers a fresh download of a gigabyte or several, and the old ones just accumulate.

# list each cached build's symbols by size
$ du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# remove old ones; they re-download on next connect
$ rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

Safe to delete. The next time you plug in a device on a given build, Xcode fetches that build's symbols again.

3. Simulators: unavailable devices and old runtimes

There are two separate things here, and the distinction matters. A simulator device is a configured iPhone or iPad instance. A runtime is the iOS version it runs. When you update Xcode, devices tied to a runtime that is no longer supported become "unavailable" but stick around forever, and old runtimes stay installed.

Do not delete the folders by hand. Xcode keeps a database of simulators, and hand-deleting leaves it out of sync. Use Apple's own simctl tool, which updates the database as it goes.

# remove simulator devices whose runtime is no longer supported
$ xcrun simctl delete unavailable

# see installed runtimes, then remove the outdated ones
$ xcrun simctl runtime list
$ xcrun simctl runtime delete --outdated

# preview before committing, on any delete
$ xcrun simctl runtime delete all --dry-run

4. Archives — the one with a real catch

Each time you archive a build for distribution, Xcode saves an .xcarchive in ~/Library/Developer/Xcode/Archives, containing the app binary and its debug symbols (dSYMs). Here is the catch that the other items do not have: you need the archive for any build you shipped in order to symbolicate its crash reports. Delete the archive for a version still in users' hands and you lose the ability to turn their crash logs into readable stack traces.

5. CoreSimulator caches

Separately from the simulator devices themselves, there is a cache folder at ~/Library/Developer/CoreSimulator/Caches that is safe to empty. Leave the sibling Devices folder to simctl, but the Caches directory can go.

Put it together

A single cleanup session that clears DerivedData, old DeviceSupport, unavailable simulators and outdated runtimes commonly returns 50 GB or more on a machine that has been building for a year or two. Individual developers have reported far larger single hauls: over 100 GB from stale simulator runtimes alone in extreme cases. Measure yours first so you know what you actually recovered:

# a quick before/after of the Xcode footprint
$ du -sh ~/Library/Developer/Xcode/*
$ du -sh ~/Library/Developer/CoreSimulator/*

Sources

• Apple — xcrun simctl help delete and xcrun simctl help runtime (Xcode's own built-in reference; Apple publishes no man simctl).
• Apple Developer Forums — threads on iOS DeviceSupport growth, archives and dSYM retention for symbolication.
• Developer write-ups on DerivedData and simulator-runtime cleanup (reclaim sizes are commonly reported, not official averages).