Is it safe to delete DerivedData?

Short answer: yes, as long as Xcode is not building right now. It regenerates. The longer answer is about what regenerating actually costs you, because it is not free, and about the one situation where deleting it does real damage.

DerivedData lives at ~/Library/Developer/Xcode/DerivedData. On a machine that has been used for a year it is routinely 20 to 80 GB, which is why every disk cleanup article tells you to empty it, and why every Mac cleaner offers to do it for you.

They are not wrong. They are just missing the timing question.

What is actually in there

Four things, and they are not equally disposable.

• Build products. The compiled output of your project. Object files, the app bundle itself, static libraries. This is the bulk of the size.
• The module cache. Precompiled Swift and Clang modules. This is the one that gets corrupted and causes those errors that make no sense.
• The index. What powers jump to definition, autocomplete and symbol search. Delete it and Xcode has to read your whole project again.
• Logs. Build logs and test results, including the history behind those little timing graphs.

All four regenerate. None of them are your source code, and nothing in DerivedData is under version control, which is the reason it is safe to remove at all.

What deleting it actually costs

People say it is free because it rebuilds. What they mean is that nothing is permanently lost. The cost is time, and on a large project the time is not small.

A clean build of a medium Swift project is commonly five to fifteen minutes where an incremental build was fifteen seconds. Then indexing runs, and until it finishes autocomplete is unreliable and jump to definition does nothing. On a big codebase that is another few minutes of the editor feeling broken while it is in fact working exactly as designed.

So it is not free. It is cheap, occasionally, when you have a reason.

When it genuinely helps

Deleting DerivedData is a real fix for a specific class of problem, not a general tune up:

• Build errors referencing a file you have already deleted or renamed
• Swift module errors that mention a version mismatch, or a module built with a different compiler
• A stale resource being bundled into the app even after you changed it
• Autocomplete offering symbols that no longer exist

All of those are the index or the module cache holding a view of the project that no longer matches reality. Clearing it forces a fresh read, and the problem disappears.

If your build is failing because of an actual mistake in your code, deleting DerivedData will cost you ten minutes and change nothing.

The one time it does damage

While a build is running.

Xcode writes intermediate output into DerivedData throughout a compile. Remove those files mid build and the compiler starts failing on things that were there a second ago. The errors you get do not say "somebody deleted my scratch directory". They look like missing headers, corrupt module files, or linker errors about symbols that obviously exist. People spend an afternoon debugging their own code because a scheduled cleanup ran at the wrong moment.

The same applies to anything else building on the machine at the time: a Gradle daemon, a Vite dev server, cargo, ninja, an npm install. They all keep scratch state on disk while they work, and they all react badly to it disappearing.

How to delete it properly

Quit Xcode first. Not because the folder is locked, but because Xcode holds its own view of the index in memory and gets confused if the files vanish underneath it.

Then, from Terminal:

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

Xcode recreates the folder on the next build. If you want to keep the folder itself, add a trailing /*, though there is no real benefit.

Inside Xcode you can also use Product then Clean Build Folder, holding Option to get Clean Build Folder Immediately. That is narrower: it clears the current scheme's build products but leaves the index and the module cache. For the stale module errors above, you usually want the full removal.

What not to delete while you are in there

Two neighbours in the same directory tree look similarly disposable and are not.

~/Library/Developer/Xcode/iOS DeviceSupport holds symbol files for each iOS version you have debugged against. It gets large, and it is genuinely safe to clear, but you will re-download several gigabytes the next time you plug in a device running that version.

~/Library/Developer/Xcode/Archives holds every build you have ever archived for the App Store, including the dSYMs. Delete those and you lose the ability to symbolicate crash reports from versions already in the wild. Cleaners sometimes offer this folder because it is large and old. Do not accept.

The rule

DerivedData is safe to delete, unpleasant to delete at the wrong moment, and pointless to delete on a schedule. Clear it when you have a symptom that suggests a stale index, or when you genuinely need the disk space back. Otherwise leave it alone and let it do its job, which is making your builds fast.

Keep reading

• Never let a cleaner run during a build: safe to delete and safe to delete now are different claims.
• What is safe to delete on a Mac, and what absolutely is not: what regenerates, and what never comes back.