If you have ever poked around ~/Library/Developer/Xcode/DerivedData and found gigabytes of folders with cryptic names, you are not alone. Understanding what is DerivedData in Xcode — and whether you can safely remove it — is one of the most common questions macOS developers ask. The short answer is: yes, it is always safe to delete, and Xcode will rebuild everything it needs the next time you open a project.
What Is DerivedData in Xcode?
DerivedData is Xcode's build cache directory. Every time you build, index, or run a project, Xcode writes intermediate and final build products into a per-project subfolder inside ~/Library/Developer/Xcode/DerivedData/. The folder name is your project name followed by a unique hash — for example, MyApp-gzqcufxlkrtflofjfgbmwmyfmkdo.
What Exactly Is Stored Inside?
- Build products — compiled
.appbundles, frameworks, and libraries produced during a build. - Intermediate build files — object files (
.o), Swift module files (.swiftmodule), and other compiler outputs that are reused when you rebuild incrementally. - Source-code index — the full index that powers Xcode's code completion, jump-to-definition, and the Issue navigator. Rebuilding this after deletion takes a few minutes on a large codebase.
- Test results and logs —
.xcresultbundles from previous test runs, plus build logs. - Preview content — cached SwiftUI canvas previews.
None of this is source code. Your actual project files live in whatever location you chose when you created the project. DerivedData is purely derived — hence the name — and every byte of it can be reproduced by Xcode from your sources.
Why Does DerivedData Get So Large?
DerivedData accumulates over time because Xcode writes a fresh subfolder for each project you open, and old folders are rarely cleaned up automatically. A single large Swift project can produce several gigabytes of intermediates. Developers who juggle many projects — or who switch between Xcode versions — often find 20–50 GB sitting in DerivedData without realising it.
Swift module files are a particularly large contributor. Each target produces one .swiftmodule per architecture, and with Universal builds (arm64 + x86_64) that doubles the size. SwiftUI preview builds add another layer on top.
Is It Safe to Delete DerivedData?
Yes — deleting DerivedData is completely safe. It contains no original source code, no project settings, and nothing that cannot be regenerated. Apple's own documentation treats it as a disposable cache. Experienced iOS and macOS developers routinely delete it as a first debugging step when Xcode behaves oddly.
The only real cost is time: your next build after deletion will be a clean build rather than an incremental one, and the source-code index will be rebuilt in the background. On a fast Mac with a large project this might add a minute or two to your first build.
What Happens After You Delete It?
- Your source files are untouched.
- Xcode performs a clean build the next time you build the project.
- Code completion and jump-to-definition may be unavailable for a few minutes while the index rebuilds in the background.
- SwiftUI Previews will be slow on first load until their caches are rebuilt.
- Previous test results (
.xcresultbundles) inside DerivedData are gone, but your source and any CI-stored results are unaffected.
How to Delete DerivedData in Xcode
There are three main ways to remove DerivedData, depending on how much you want to delete.
Method 1: Via Xcode Settings (Recommended for One Project)
- Open Xcode and go to Xcode → Settings (or press ⌘,).
- Click the Locations tab.
- Next to the Derived Data path, click the small arrow to reveal the folder in Finder, then delete only the subfolder for your project — or delete the entire
DerivedDatadirectory to clear everything.
Method 2: Product Menu — Clean Build Folder
- With a project open in Xcode, hold Option and click the Product menu.
- Choose Clean Build Folder… (the option only appears while holding Option).
- Confirm the prompt. Xcode deletes the build products for that project but leaves the index intact.
Method 3: Terminal (Deletes Everything at Once)
rm -rf ~/Library/Developer/Xcode/DerivedDataThis removes the entire DerivedData directory. Xcode will recreate it the next time you build any project. Run it while Xcode is closed to avoid any file-locking issues.
Other Xcode Caches Worth Knowing About
| Location | What it stores | Safe to delete? |
|---|---|---|
~/Library/Developer/Xcode/DerivedData |
Build products, indexes, test results | Yes — always |
~/Library/Caches/com.apple.dt.Xcode |
Download caches, asset caches | Yes |
~/Library/Developer/CoreSimulator/Caches |
Simulator runtime caches | Yes, but expect slow first launch |
~/Library/Developer/CoreSimulator/Devices |
Simulator device images and installed apps | With care — deleting removes simulated data |
~/Library/Developer/Xcode/Archives |
Exported app archives used for App Store submission | Only if you have submitted and no longer need them |
Not Sure About an Unfamiliar Folder? Ask Before You Delete
DerivedData is straightforward, but macOS developers encounter plenty of other mysterious directories — SPM caches, simulator runtimes, Instruments traces — where the consequences of deletion are less clear. If you ever hover over an unfamiliar folder and wonder whether it is safe to remove, Crumb's Is this safe to delete? AI explains exactly what a folder contains and what will happen if you remove it, before anything is touched. It is a useful sanity check when you are not certain.
How Often Should You Clear DerivedData?
There is no fixed schedule. Most developers delete it reactively — when Xcode starts behaving strangely (unexpected build errors, stale autocomplete, broken previews) or when disk space is running low. If you work across many projects and Xcode versions, a monthly clean-out is a reasonable habit.
You do not need to delete DerivedData as part of a normal workflow. Incremental builds that reuse cached intermediates are faster, so leave it in place unless you have a specific reason to remove it.
Freeing Up Space Beyond DerivedData
DerivedData is often the single largest recoverable cache on a developer's Mac, but it is not the only one. Xcode simulator runtimes, SPM package caches at ~/.swiftpm, CocoaPods caches, and Docker images can collectively consume tens of gigabytes. If you want a full picture of what is taking up space on your Mac — not just Xcode files — download Crumb to get a visual disk map and a ranked list of your largest files and folders, so you can make informed decisions about what to remove.
Summary
DerivedData is Xcode's build cache: compiled products, indexes, test results, and intermediates. It is never your source code, and deleting it is always safe — Xcode regenerates everything from scratch on the next build. Use Xcode's built-in Clean Build Folder for a targeted clear, or run rm -rf ~/Library/Developer/Xcode/DerivedData in Terminal to wipe the slate completely. The only side effect is a slower first build and a few minutes of index rebuilding, both of which resolve on their own.