Is It Safe to Delete Xcode's DerivedData Folder?

Yes, it's safe to deleteDiskmack safety tier: Safe to clean

~/Library/Developer/Xcode/DerivedData**/DerivedData

Yes, you can delete DerivedData. It holds Xcode's build output and indexes, and Xcode rebuilds all of it the next time you open or build a project. The only cost is a slower first build while Xcode recompiles and re-indexes. This is the single most famous disk hog on developer Macs, and clearing it is routine.

What it is

DerivedData is where Xcode keeps everything it generates while working on your projects: compiled object files, intermediate build products, module caches, indexes for code completion and search, and build logs. Every project you have ever opened in Xcode gets its own subfolder here, named after the project plus a hash. The default location is ~/Library/Developer/Xcode/DerivedData.

It grows because Xcode almost never cleans up after itself. Open a project once to peek at the code and its build artifacts can sit there for years. Active projects add more with every build, and each Xcode update can leave stale data from the old version behind. A single medium-sized app can account for several gigabytes, and on a Mac that has seen many projects the folder can reach tens of gigabytes. Some teams also configure Xcode to put DerivedData next to the project instead of in ~/Library (Xcode Settings > Locations > Derived Data > Relative), so you may find a folder literally named DerivedData sitting inside a project directory. It is the same thing at a different path.

Is it safe to delete?

Deleting it is safe. Nothing in DerivedData is source code or user data; it is all generated from your projects. When you next open or build a project, Xcode recreates the folder and rebuilds what it needs. What you pay is time: the first build after a wipe is a full build instead of an incremental one, and code completion may lag for a few minutes while the index rebuilds. For a small project that is seconds; for a large app with many dependencies it can be several minutes.

Beyond reclaiming space, wiping DerivedData is the standard first fix when Xcode misbehaves: phantom build errors that a clean should have cured, stale code completion suggestions, breakpoints that never get hit. The project-local variant is equally safe to remove, since it holds the same generated output. Diskmack identifies this folder automatically and cleans it the safe way. Just quit Xcode first so nothing is writing to the folder while you remove it.

How to check its size

In Finder: In Finder, choose Go > Go to Folder (Cmd+Shift+G), paste ~/Library/Developer/Xcode/DerivedData and press Return. Select the DerivedData folder, then press Cmd+I to see its size.

In Terminal:

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

The shell expands ~ to your home folder. For a project-local copy, type du -sh followed by a space, then drag the DerivedData folder from Finder into the Terminal window and press Return; Terminal fills in the exact path and escapes any spaces for you.

How to clean it

Quit Xcode completely (Cmd+Q, not just closing the window).
In Finder, choose Go > Go to Folder and enter ~/Library/Developer/Xcode/DerivedData.
Select everything inside the folder and move it to the Trash. You can also trash the whole DerivedData folder; Xcode recreates it.
If your team configured a custom location, also look for a folder named DerivedData next to your .xcodeproj or .xcworkspace file and trash that too.
Empty the Trash, then reopen Xcode. Expect the first build of each project to take longer than usual.

You don't have to wipe everything. Each project's build cache lives in a subfolder named after that project plus a hash, so you can trash only the entries for projects you no longer work on. The folders with names ending in .noindex (like ModuleCache.noindex) are shared caches; they regenerate too, but leaving them alone keeps your active builds fast.

Will it come back?

Yes, and quickly if you are an active developer. The moment you build a project, Xcode recreates that project's subfolder, and within a few builds it is back to roughly its old size for the projects you actually use. What does not come back on its own is the dead weight: subfolders for projects you opened once and never touched again stay gone until you open those projects again. So a periodic wipe genuinely reclaims space, but on a working development machine treat DerivedData as a folder you prune every few months, not one you empty once and forget.

Common questions

Will deleting DerivedData break my Xcode projects?

No. Your source code, project files, and settings live elsewhere. DerivedData only holds generated build output and indexes. The worst outcome is a slower first build while Xcode recreates everything.

How big does DerivedData usually get?

It varies with how much you build. A single active app project often accounts for several gigabytes, and Macs that have hosted many projects over the years commonly carry tens of gigabytes here. Check yours with du -sh ~/Library/Developer/Xcode/DerivedData before assuming.

Isn't Product > Clean Build Folder enough?

Clean Build Folder (Cmd+Shift+K) clears build output for the currently open project only. It does nothing about the subfolders left behind by every other project you have ever opened, which is usually where most of the space hides. Deleting the DerivedData folder itself is the full reset.

I found a DerivedData folder inside my project directory. Is that different?

No, it is the same build output. Xcode can be configured (Settings > Locations) to keep DerivedData next to the project instead of in ~/Library/Developer/Xcode. It is just as safe to delete, and it regenerates on the next build the same way.