On a working developer's Mac, Xcode is usually the single largest thing
on the disk, and most of it is regenerable. DerivedData, device support
for every iOS version you ever connected, simulator runtimes you stopped
using two years ago, and archives you have already shipped. It is
routinely 100 GB or more. Here is what each folder is, what it costs
you to delete it, and the commands to do it.
01 DerivedData
~/Library/Developer/Xcode/DerivedData. Build products,
intermediates, indexes, and module caches, one subfolder per project.
This is the biggest and the safest to delete. Everything in it is
reproducible by building again.
rm -rf ~/Library/Developer/Xcode/DerivedData/*
The cost is that your next build of each project is a clean build, and
the index has to be rebuilt, so autocomplete and jump-to-definition will
be unhelpful for a few minutes after you reopen a large project. For a
single project, delete only that project's subfolder rather than the lot.
02 iOS DeviceSupport
~/Library/Developer/Xcode/iOS DeviceSupport. Every time you
plug in a device running an OS version Xcode has not seen, it copies that
version's symbols so it can symbolicate crashes. It never removes them.
A folder per iOS point release, several gigabytes each, going back years.
Delete the ones for versions you no longer test against. Xcode
regenerates a folder the next time you connect a device on that version,
which takes a few minutes of "preparing device" but costs nothing else.
The same applies to watchOS DeviceSupport and
tvOS DeviceSupport if you have them.
03 Simulators and runtimes
Two separate things live here and they are worth treating differently.
Simulator devices in
~/Library/Developer/CoreSimulator/Devices. Each one holds
a full filesystem image with your app's data. Devices for runtimes you
have removed linger as unavailable.
xcrun simctl delete unavailable clears exactly those and
is safe. xcrun simctl erase all wipes the data on every
simulator without deleting the devices, which reclaims more.
Simulator runtimes, the OS images themselves, which
on current Xcode are managed from
Xcode → Settings → Components. These are large,
several gigabytes each. Remove the ones for OS versions you no longer
support, and be aware they are a sizeable download to get back.
04 The rest of it
Archives:~/Library/Developer/Xcode/Archives. Every build you ever
archived, with its dSYMs. Keep the ones for versions currently in the
wild, since you need the dSYMs to symbolicate crash reports from
them. Delete the rest.
Xcode's own cache:~/Library/Caches/com.apple.dt.Xcode. Safe, rebuilds
itself.
Swift Package Manager cache:~/Library/Caches/org.swift.swiftpm and
~/.swiftpm. Safe. Next resolve re-downloads.
CocoaPods cache:~/Library/Caches/CocoaPods,
or pod cache clean --all.
Old Xcode versions. If you keep several Xcodes in
/Applications, each is roughly 10 to 20 GB. Often the easiest
single win on the whole disk.
And while you are here, the non-Xcode developer caches worth the same
treatment: docker system prune -a,
npm cache clean --force,
brew cleanup --prune=all, and
~/.gradle/caches or ~/.m2/repository if you
work on the JVM. Docker in particular is frequently tens of gigabytes of
images nobody has run in a year.
05 Why the numbers will not add up
Here is the part that catches people out. You will delete a DerivedData
folder that Finder swore was 60 GB, and free 9 GB. Nothing went
wrong.
Xcode's build system is a heavy user of APFS clone-on-write. When it
copies a framework or a resource bundle into a build product, the copy
shares its blocks with the original rather than duplicating them. Both
files report their full size. Only one of them is really there. Finder's
Get Info and du both sum logical sizes and so both report a
number that can be many times what deleting will actually give you back.
The full version of this, with the syscalls, is in
Counting bytes on APFS.
The practical consequence: to decide what is worth deleting, you need a
tool that reports deduplicated on-disk bytes. Otherwise you spend an hour
clearing the folder that looked biggest and reclaim almost nothing.
06 Seeing it
Delve is the tool we built for exactly this. It maps
the volume as a treemap where every rectangle is sized by the space it
genuinely occupies, with clones and hardlinks counted once and iCloud
placeholders marked. Point it at
~/Library/Developer and the real distribution of your Xcode
storage is one picture: which projects' DerivedData actually cost
something, which device support folders are dead weight, which archives
to keep.
A 1 TB volume scans in well under two minutes on a base M2. It
is native, it never sends your filesystem anywhere, and it is $4.99 once
after a 14-day free trial. If you want the engineering behind it, the
architecture notes are the
honest version.
Yes. Everything in it is generated from your source and rebuilds
on the next build. The only cost is a clean build and a rebuilt
index, so the first build and the first few minutes of
autocomplete afterwards will be slow.
Where is DerivedData on a Mac?
~/Library/Developer/Xcode/DerivedData. The Library
folder is hidden in Finder; hold Option while opening the Go menu,
or press Cmd+Shift+G and paste the path.
How much space does Xcode use?
The app itself is roughly 10 to 20 GB. On an active developer's
Mac the surrounding caches, DerivedData, device support, simulator
runtimes, and archives, are frequently larger than the app, often
100 GB or more in total.
Can I delete iOS DeviceSupport?
Yes, for OS versions you no longer test against. Xcode regenerates
the folder the next time you connect a device on that version,
which takes a few minutes of preparing the device.
Why did deleting DerivedData free less space than expected?
Xcode makes heavy use of APFS clone-on-write, so build products
share blocks with the files they were copied from. Finder and du
report the sum of logical file sizes, which counts those shared
blocks repeatedly. Only the blocks nothing else references are
actually freed.