Is Xcode DerivedData safe to delete? How to clear it
Yes. DerivedData is safe to delete. Everything in it is generated by Xcode, and Xcode builds it again the next time you build or open a project. You lose time (the next build is a full one), not work.
Where DerivedData lives
By default it is here:
~/Library/Developer/Xcode/DerivedDataEach project gets its own folder named after the project plus a hash, such as MyApp-bzvfqkxwhgdnxccyzkcmbzgoitfn. To see how much space it uses:
du -sh ~/Library/Developer/Xcode/DerivedDataIf you changed the location, open Xcode → Settings → Locations. The DerivedData path is shown there, and the small arrow next to it opens the folder in Finder.
What is inside
| Folder | What it is | Rebuilt? |
|---|---|---|
Build |
Compiled apps, frameworks and intermediate files | On the next build |
Index.noindex |
The index behind code completion and jump to definition | While Xcode indexes the project |
ModuleCache.noindex |
Precompiled module caches | On the next build |
Logs |
Build and test logs | Per build |
SourcePackages |
Swift packages that Xcode downloaded for a project | Packages are fetched again |
The last row matters: if a project uses Swift packages, Xcode re-downloads them after you clear DerivedData, so you need a network connection for the next build.
Three ways to clear it
1. Clean one project from Xcode. Choose Product → Clean Build Folder (⇧⌘K). This removes the build products of the current project only. It is the gentlest option, and it often fixes a stubborn build error.
2. Delete the whole folder from Terminal. Quit Xcode first, then run:
rm -rf ~/Library/Developer/Xcode/DerivedData/*rm -rf has no undo, so check the path before you press Return. The * keeps the DerivedData folder itself and empties what is inside it.
3. Delete one project’s folder. If only one project misbehaves, remove just its folder. Replace MyApp with your project name:
rm -rf ~/Library/Developer/Xcode/DerivedData/MyApp-*Tip: Before deleting, run
ls ~/Library/Developer/Xcode/DerivedDatato see the folder names, anddu -sh ~/Library/Developer/Xcode/DerivedData/*to see which project takes the most space.
When clearing DerivedData actually helps
- A build fails with errors that do not match your code, such as “module not found” or a stale precompiled header.
- Code completion, syntax colouring or jump to definition stopped working.
- You switched Xcode versions and the old build products no longer fit.
- You want disk space back. On a Mac with many projects, DerivedData is often several gigabytes.
What to expect on the next build
The first build after clearing is slower, because Xcode compiles everything again and rebuilds the index. A big project can take minutes. Later builds are fast again. Nothing you wrote is touched.
What not to confuse it with
DerivedData is only one of several Xcode folders. These are separate and have their own rules:
- Archives hold the builds you shipped, and they are not disposable. See Xcode Archives: where they are and what to delete.
- iOS DeviceSupport holds symbols for physical devices. See Xcode iOS DeviceSupport: what it is and can you delete it.
- Simulators keep their own data. See how to reset or delete iOS simulators from Terminal.
For a full tour of everything worth cleaning, read how to free up disk space on a Mac as a developer.
Quick answers
Will deleting DerivedData delete my source code?
No. DerivedData only holds build products, indexes and logs that Xcode generates. Your source files, project settings, schemes and breakpoints live inside your project, not in DerivedData.
Can I delete DerivedData while Xcode is open?
It is better not to. Xcode keeps its index and build files open, and removing them under a running Xcode can cause odd errors. Quit Xcode first, delete, then reopen it.
How often should I clear DerivedData?
Only when you need to: when a build fails for no clear reason, when code completion stops working, or when you want the disk space back. Clearing it by habit just makes every next build slower.