Xcode DerivedData: what’s inside, why It Grows, and when I delete it
Short answer: DerivedData is the folder where Xcode keeps everything it generates while building a project: compiled products, intermediate object files, the code index, module caches and build logs. It lives at ~/Library/Developer/Xcode/DerivedData, it is safe to delete because Xcode rebuilds it, and the cost of deleting it is a slower next build, not lost work.
I stopped treating it as a black box the first time a Mac ran low on disk and the biggest folder in ~/Library turned out to be a build cache. The rest of this is the model I use to decide what to delete and what to leave.
What is Xcode DerivedData?
DerivedData is a cache. Nothing in it is a source of truth: your code, assets and project settings live in the project, and every file in DerivedData can be regenerated from them. Xcode creates one subfolder per project or workspace, named after the project plus a hash of its path, for example MyApp-bwcfgxqzkdnmpbaxwtkwqwrvnrls.
Because the hash comes from the path, the same project opened from two different locations gets two different folders. That detail explains most of the growth I see.
What is inside a DerivedData folder?
Opening one of those folders in Finder for the first time, I expected a mess, and it is actually fairly tidy. Most of the weight sits in a handful of subfolders:
- Build/Products holds the built apps, frameworks and test bundles. Losing it costs a rebuild.
- Build/Intermediates.noindex holds object files and per-target build state. Losing it means a full rebuild, usually the slowest part.
- Index.noindex holds the index behind code completion, jump-to-definition and search. Losing it means a re-index, and completion is degraded until that finishes.
- Logs holds build, test and run logs. Losing it only removes the old logs.
- SourcePackages holds Swift Package Manager checkouts, when packages are resolved here. Losing it means the packages are fetched again.
- info.plist holds metadata, including the path of the project the folder belongs to. Losing it costs nothing, since it is recreated.
Next to the project folders, at the top level, sits a shared ModuleCache.noindex with precompiled Clang modules that several projects reuse, which is why it can survive when every project folder around it is gone. The .noindex suffix, as far as I can tell, exists so Spotlight skips build output, and I read it as Apple’s own hint that these folders are expected to be big and expendable.
Why does DerivedData keep growing?
In my experience the growth has three sources, and none of them is dramatic on its own. Every project gets a folder, and each configuration and platform it is built for adds another set of products and intermediates, so an app that targets a device and a few simulators carries all of those at once. Because folders are keyed by path, a project that was moved, renamed, re-cloned or deleted leaves its old folder behind, and Xcode never told me that a given folder had become an orphan. Finally the index and module cache scale with the code and its dependencies, so an app pulling in many Swift packages ends up with a large index even when the source itself is small.
On a machine used for several active projects over a year or two, this can reach tens of gigabytes. I did not measure a typical figure across machines, so I am only claiming the order of magnitude.
How do I see what is taking the space?
Before deleting anything I look at where the space actually went, mostly because I have been wrong about it before and the biggest folder was not the one I assumed.
# total size
du -sh ~/Library/Developer/Xcode/DerivedData
# per-project size, largest last
du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -hThe size alone does not say much, since the folder names are hashes. What does help is the info.plist inside each folder, which records the project the folder was created for, so a small loop can print size and owner together:
for d in ~/Library/Developer/Xcode/DerivedData/*/; do
path=$(/usr/libexec/PlistBuddy -c "Print :WorkspacePath" "$d/info.plist" 2>/dev/null)
size=$(du -sh "$d" | cut -f1)
echo "$size $(basename "$d") -> ${path:-unknown}"
doneWhenever the listed path no longer exists on disk, the folder belongs to a project that is gone, and that is where I start deleting.
Is it safe to delete DerivedData?
Yes, and the one condition I keep is that Xcode is closed first, because deleting the folder under a running Xcode can leave it holding an index that points at files that no longer exist.
rm -rf ~/Library/Developer/Xcode/DerivedDataWhat I lose, and what I do not:
What is lost: compiled products and intermediates, the code index, the module cache, and resolved package checkouts in SourcePackages.
What is not lost: source code, project settings and schemes, archives (which live in ~/Library/Developer/Xcode/Archives), and provisioning profiles and certificates.
Get Hlib Serediuk’s stories in your inbox
Join Medium for free to get updates from this writer.
The trade-off is time. The next build is a cold build, the index is rebuilt in the background, and package dependencies may be fetched again, which needs network access. For a large project that is minutes, not seconds. When the disk is nearly full this is a good deal. When I am about to demo something, it is not, so I do not do it five minutes before.
I usually do not delete everything either. Removing only the orphaned folders, or only the ones I have not opened in a month, keeps the active projects warm:
# folders untouched for 30+ days
find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mindepth 1 -type d -mtime +30Does “Clean Build Folder” do the same thing?
Not quite. Product → Clean Build Folder (Shift-Cmd-K) removes the build products of the current project. It does not remove the index, the module cache, or the folders of other projects. It is the right tool for “this target built wrong”, and the wrong tool for “I need disk space”.
When does deleting DerivedData fix a bug?
Deleting it is often the first thing suggested for strange build errors, and it works for a specific class of problems where the cache and the source disagree:
- errors such as “Cannot find X in scope” in code that is clearly correct, usually a stale index
- “Module compiled with Swift X cannot be imported by Swift Y” after an Xcode update, a stale module cache
- a target that keeps using an old version of a dependency
- code completion that stopped working or points at the wrong symbols
It does not fix real compile errors, signing problems or misconfigured build settings. If deleting the folder changes nothing, the cause was never the cache, and I stop retrying it.
What else takes space next to DerivedData?
DerivedData is rarely the only large folder under ~/Library/Developer. The other usual suspects:
- ~/Library/Developer/Xcode/Archives holds archived builds. It is not a cache, so I check before removing anything, since I may still need the dSYMs.
- ~/Library/Developer/Xcode/iOS DeviceSupport holds symbols copied from physical devices, one folder per OS version.
- ~/Library/Developer/CoreSimulator/Devices holds simulator data, one folder per device.
For simulators, xcrun simctl delete unavailable removes devices whose runtimes are no longer installed, which is safe and often recovers a lot of space.
Can I change where DerivedData lives?
Yes. Xcode’s Locations setting lets the Derived Data location be the default, relative to the workspace, or a custom path. For command-line and CI builds, xcodebuild accepts -derivedDataPath:
xcodebuild -scheme MyApp -derivedDataPath ./build buildI find this useful on CI, where a fixed path makes the cache easy to keep or discard on purpose.
Further reading
- man xcodebuild for -derivedDataPath and the other build flags
- man xcrun and xcrun simctl help for simulator management
- Xcode’s Settings → Locations pane for the Derived Data location
Frequently asked questions
Where is Xcode DerivedData located? At ~/Library/Developer/Xcode/DerivedData by default. The location can be changed in Xcode’s Locations settings.
Is it safe to delete DerivedData? Yes. It is a cache, and Xcode regenerates it. Quitting Xcode first avoids a stale index, and the only cost is a slower next build.
Will deleting DerivedData delete my code? No. Source files, project settings and archives are stored elsewhere.
Why is my DerivedData so large? It keeps one folder per project path, with products, intermediates, an index and a module cache. Moved or deleted projects leave orphaned folders behind.
Is “Clean Build Folder” the same as deleting DerivedData? No. It removes the current project’s build products, not the index, module cache or other projects’ folders.
