Every iOS and macOS developer has, at some point, been told to "just delete DerivedData" as the fix for an Xcode problem that made no sense. It works often enough that it has become folklore, but the folder itself is not mysterious once you know what's actually in it — and knowing that also tells you when deleting it will and won't help.

Where it lives and what triggers it

Xcode writes DerivedData to ~/Library/Developer/Xcode/DerivedData by default. Inside, every project or workspace you've opened gets its own subfolder, named after the project plus a fixed-length hash suffix — MyApp-a1b2c3d4e5f6g7h8i9j0klmnop. Opening a project in Xcode is enough to create an entry here; you don't need to have built it.

Each project's DerivedData folder holds several distinct things bundled together under one name:

  • Build products — compiled object files, the actual .app or framework bundles produced by a build, and intermediate build artefacts.
  • Module cache — precompiled Clang/Swift module interfaces, shared in principle across projects that use the same system frameworks, though in practice DerivedData's per-project layout means much of this ends up duplicated.
  • Index — the index-store — the data Xcode's source indexer builds to support jump-to-definition, autocomplete, and "Find Callers", derived from parsing your entire codebase.
  • Logs — build logs and diagnostic output from past builds, useful for debugging a build failure after the fact.

None of these are source of truth for anything. Every one of them is Xcode's own derived output from your actual source code — hence the name.

Why it grows without bound

Xcode does not automatically prune old DerivedData entries when a project is renamed, moved, or deleted from disk. Each time the hash in the folder name changes — which happens when a project's file path changes — Xcode creates a new DerivedData folder rather than reusing or cleaning up the old one. Developers who reorganise their projects folder occasionally, or who clone the same repository into multiple locations for different branches, can end up with several stale multi-gigabyte DerivedData folders for projects they no longer have on disk in that location.

Combine that with module caches and index stores that grow proportionally to codebase size, and it's common for ~/Library/Developer/Xcode/DerivedData to reach tens of gigabytes on an actively used development Mac — sometimes over a hundred, for someone working across several large projects.

Deleting it is safe

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

Xcode rebuilds whatever it needs the next time you open a project or trigger a build. The cost is entirely time: the next build for each project is a full clean build rather than an incremental one, and the source indexer has to re-index the codebase from scratch before autocomplete and jump-to-definition work at full accuracy again — which for a large project can take a few minutes of the indexer working quietly in the background.

The GUI equivalent, if you'd rather not touch Terminal: Xcode → Settings → Locations → Derived Data, click the small arrow next to the path to reveal it in Finder, then delete the folder (or specific project subfolders) from there.

When deleting it actually fixes something, and when it doesn't

DerivedData deletion genuinely resolves a specific category of Xcode misbehaviour: stale build artefacts causing a build to succeed when it shouldn't, or fail when it shouldn't, because Xcode's incremental build system made an incorrect assumption about what needed rebuilding. Symptoms include a build that "just won't pick up" a change you made, autocomplete suggesting symbols that no longer exist in your code, or "Find Callers" missing recently added call sites.

It does not fix: actual compiler errors in your code, missing dependencies, provisioning profile or signing issues, or SwiftUI preview crashes caused by a genuine runtime problem rather than a stale cache. If you delete DerivedData and the same error reappears identically on the next clean build, the cache was never the cause — the folklore advice sometimes gets reached for before actually reading the error message.

Scoping the deletion to one project

If only one project is misbehaving, there's no need to nuke every project's DerivedData:

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

This preserves build caches and index data for every other project you have open, at the cost of only that one project needing a fresh build and re-index.

Changing where DerivedData lives

Some developers move DerivedData to a different volume — useful if your main disk is an internal SSD you want to keep leaner, and you have a fast external or secondary drive to spare. This is configured per-project or globally under Xcode → Settings → Locations, with a custom path instead of the default. Worth knowing about even if you don't use it, since a Mac with DerivedData already redirected elsewhere won't show the expected growth under the default path — the space is simply somewhere else.

SwiftUI previews add their own layer on top

If you work with SwiftUI, it's worth knowing that Xcode Previews build and run a separate lightweight process to render your views live in the canvas, and the artefacts that support this — a preview-specific build of your view hierarchy and its dependencies — are also stored within the relevant project's DerivedData folder rather than somewhere separate. This is part of why a project using SwiftUI previews heavily can show a larger DerivedData footprint for its size than an equivalent UIKit-only project: every preview refresh potentially triggers incremental rebuild work that lands in the same cache.

Deleting DerivedData resets this too, and previews will take longer to come back up the first time after a clean, the same way a full app build does — Xcode has to reconstruct the preview's dependency graph from scratch rather than reusing anything incremental.

A sensible routine

  1. du -sh ~/Library/Developer/Xcode/DerivedData/* to see which projects are contributing the most.
  2. Delete subfolders for projects you no longer have on disk, or duplicate entries for projects you've moved — these are pure waste.
  3. If a specific project is behaving strangely in Xcode, delete just that project's folder before assuming the problem is in your code.
  4. For general disk pressure with no build problems, deleting the whole folder is safe and reasonably common practice among iOS developers who do it every few weeks as routine maintenance.

Where VolumeLens fits in

DerivedData is one of the most consistently large, consistently safe-to-delete folders on any Mac used for iOS or macOS development, and yet it sits inside ~/Library where most people never look. VolumeLens surfaces it immediately in a scan, sized honestly, alongside Xcode's other large consumers like Archives and iOS DeviceSupport. Insights recognises DerivedData by name specifically so you don't have to remember the path.