DerivedData, and when deleting it is the right answer

On this page

1. What is in there
2. Why it never shrinks
3. When deleting it actually fixes something
4. Deleting it safely
5. The part worth keeping

What is in there

One directory per project, named for the project plus a hash of its path, containing four things worth knowing about.

• Build — object files, the built products, and the intermediates that make an incremental build fast. Almost all of the size.
• Index — the code index that drives autocomplete, jump-to-definition and the issue navigator. Large, and expensive to rebuild: on a big project, expect several minutes of the machine being busy after you delete it.
• Logs — build and test logs, which is what the report navigator reads. Small.
• ModuleCache — precompiled module data shared across targets. Medium, and rebuilt quickly.

du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -h | tail -10

That command is worth running before anything else, because the distribution is usually lopsided. One project you abandoned in 2024 is often larger than the three you work on every day.

Why it never shrinks

Xcode does not garbage-collect DerivedData. A project directory is created on first build and is never removed, not when you delete the project, not when you rename it, and not when you move it. Moving a project is in fact the worst case: the hash is derived from the path, so the same project at a new location gets an entirely new directory and the old one stays for ever.

This is why the folder on a three-year-old machine is mostly archaeology. A quick way to see it:

ls -lt ~/Library/Developer/Xcode/DerivedData | tail -20

Anything at the bottom of that list has not been touched in months. Those directories are pure dead weight, and deleting them costs nothing at all — not even a rebuild, because the project they belonged to is gone.

When deleting it actually fixes something

“Delete DerivedData” is the folk remedy of iOS development, and it is prescribed far more often than it helps. It genuinely fixes a narrow class of problems:

• Stale module or header state after switching branches, where the compiler insists on a symbol that no longer exists.
• A build that succeeds on a colleague’s machine and fails on yours with no relevant diff.
• Autocomplete that has stopped seeing new symbols, which is the index rather than the build.
• Odd linker errors after an Xcode version upgrade.

It does not fix a genuine compile error, a signing failure, a missing dependency or a simulator that will not boot. If the error message names a file and a line, deleting DerivedData is not the answer.

Delete the project’s own directory rather than the whole of DerivedData. You get the same fix and you do not force every other project on the machine to rebuild from scratch.

Deleting it safely

From Xcode: Settings, then Locations, then the small arrow next to the Derived Data path, which opens the folder in the Finder.

From the command line, the whole lot:

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

Or only the directories not touched in the last sixty days, which is the option worth having in a shell function:

find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mindepth 1 -type d \
  -mtime +60 -print -exec rm -rf {} +

Close Xcode first. Deleting the directory underneath a running Xcode leaves it holding references to files that no longer exist, and the symptom is a build failure that looks far more alarming than the cause.

The part worth keeping

Nothing in DerivedData is worth keeping, but the folder one level up contains something that very much is. ~/Library/Developer/Xcode/Archives holds your shipped builds and their dSYM files, which are what turn a crash report from the App Store into a line number. Delete those and you lose the ability to symbolicate crashes from versions already in users' hands — permanently, because they cannot be regenerated from a later build. Archives and dSYMs, and why they are the exception makes the case in full.

The other large directories in the same parent are worth a look while you are there: iOS DeviceSupport accumulates a folder for every iPhone build you have ever connected, covered in iOS DeviceSupport is thirty gigabytes of old iPhones, and simulator runtimes are dealt with in deleting unavailable simulators safely.