How to Safely Clear Xcode DerivedData (and Reclaim 50 GB+)

Run this. Brace yourself.

du -sh ~/Library/Developer/Xcode/DerivedData

Numbers between 20 GB and 90 GB are routine. We have seen 140 GB on a machine belonging to someone who had no idea the folder existed.

What is actually in there

For every project you have ever opened, Xcode creates a directory named after the project plus a hash, and fills it with:

• Build products — compiled .o files, linked binaries, the .app bundles
• Module caches — precompiled Swift and Clang modules
• The index — the database powering jump-to-definition, autocomplete and refactoring
• Logs — every build and test log Xcode has ever written for that project

Two things are worth noticing. First, all of it is derived — hence the name — from source code that lives elsewhere. Second, Xcode never removes any of it, including for projects you deleted in 2023. The directory for that contract job you finished two years ago is still sitting there, and it is probably 4 GB.

Is it safe to delete?

Yes. Unambiguously.

DerivedData contains no source code, no project settings, no signing certificates, no simulator data and nothing that is not reproducible from your repository. Deleting it is the single safest large reclaim on a Mac.

The cost is precisely two things:

1. Your next build of each project is a clean build. For a large app that means several minutes instead of several seconds, once.
2. Your index rebuilds. Autocomplete and jump-to-definition will be degraded for a few minutes after you next open the project.

That is it. There is no third cost.

Clearing DerivedData is also the standard fix for a whole family of Xcode absurdities: phantom build errors that survive a clean, “module not found” for a module that plainly exists, the autocomplete going silent, breakpoints landing on the wrong line, and SwiftUI previews failing for no stated reason. If you have been told to “clean the build folder” and it did not help, this is the next step.

Clearing all of it

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Quit Xcode first. Deleting the directory out from under a running build produces confusing failures — not damage, just noise you do not need.

Note the trailing /*. It empties the folder while keeping the folder itself, which is what Xcode expects to find. Removing the directory outright also works, but Xcode has to recreate it.

Clearing only what you no longer need

Wholesale deletion means every project you actively work on rebuilds from scratch. Often you want to drop the dead ones and keep today’s warm.

See what is in there, largest first:

du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -hr

And by how recently each was touched — the useful signal, because it tells you which projects you have genuinely stopped building:

ls -lt ~/Library/Developer/Xcode/DerivedData

Then remove the ones you recognise as finished. Each entry is ProjectName-somelonghash, so it is usually obvious:

rm -rf ~/Library/Developer/Xcode/DerivedData/OldClientApp-abcdefgh12345678

If you want everything not modified in the last 90 days:

find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mindepth 1 -type d -mtime +90

Check that list, then re-run with -exec rm -rf {} + appended once you are happy with it. Never pipe a find straight into a recursive delete without reading the output first.

Doing it from inside Xcode

Xcode’s own Window → Projects window lists each project with its DerivedData size and a Delete button. It is safer if you are nervous, and slower if you have forty projects.

Product → Clean Build Folder (⇧⌘K) is not the same thing. It clears the build products for the current scheme only, leaving the index, module caches and every other project untouched. It reclaims a fraction of what people expect.

Do not relocate it to an external drive

A recurring suggestion is to point DerivedData at an external SSD via Settings → Locations. It works, and it will make your builds meaningfully slower — Xcode reads and writes this directory constantly during a build, and even a fast Thunderbolt SSD is a downgrade from internal NVMe. Solve the space problem by deleting, not by moving the hot path off the fast disk.

The three other Xcode hoards

DerivedData is the biggest, not the only one:

# Debug symbols per attached device OS version — 2-6 GB each
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# Every archive you ever built
du -sh ~/Library/Developer/Xcode/Archives

# Simulator devices and runtimes
du -sh ~/Library/Developer/CoreSimulator

DeviceSupport re-downloads automatically the next time you connect a device. Archives you should keep only for versions actually released to users — you need those dSYMs to symbolicate crash reports from the field, and they are irreplaceable once gone. Simulators get their own article; they are worth 30–60 GB on their own.

It will come back

DerivedData reaches 10–15 GB within a fortnight of normal work. There is no setting to cap it and no automatic eviction. It is a standing tax on developing for Apple platforms, and the only reason it keeps ambushing you is that it is invisible — a folder inside a directory Finder hides by default.

DevCruft draws it to scale next to everything else on your disk, tells you which projects each directory belongs to and when each was last built, and clears the dead ones without you memorising paths. Or keep this page bookmarked and run the commands. Both work.

For the rest of the sources, see the full developer storage guide.