How to clear Xcode DerivedData on Mac

Published 2026-11-11

DerivedData is the folder where Xcode puts everything it generates while building: compiled objects, module caches, indexes, logs and build products. It lives at ~/Library/Developer/Xcode/DerivedData, one subfolder per project. It commonly reaches 5 to 30 GB and can pass 100 GB for someone with many large projects. It is safe to delete. Xcode rebuilds it, so the only cost is a slow first build, and nothing in it is your source code.

Check the size

du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -h | tail

Each subfolder is named ProjectName- plus a 28-character hash of the project's path. The second command shows which projects are largest. On a Mac without Xcode, or one that has never built anything, the folder is empty or missing, and du prints 0B or "No such file or directory".

You can see where Xcode is pointed. Xcode > Settings > Locations shows Derived Data with an arrow that opens it in Finder. A project or a teammate may have changed it to a custom path, in which case the path above is empty and your space is somewhere else.

Method 1: from Xcode

1. Open Xcode > Settings > Locations.
2. Click the small arrow next to the Derived Data path to open it in Finder.
3. Quit Xcode.
4. Move the project folders you want gone to the Trash, or the whole contents.

Quitting first matters. Xcode keeps files in DerivedData open, and removing them under a running Xcode produces build errors and index failures that look like a broken project. They go away on restart.

Method 2: Terminal

All of it:

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

This permanently removes build products, indexes and module caches for every project. It does not touch source, Archives, settings, or simulators. It cannot be undone, because rm bypasses the Trash. If you prefer a way back, use Finder.

One project only, which is usually what you want:

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

Check the ls output first. A glob such as MyApp-* also matches MyApp-Extras-... if you have one.

Only the old ones:

find ~/Library/Developer/Xcode/DerivedData -mindepth 1 -maxdepth 1 -type d -mtime +30

That lists project folders whose own modification time is older than 30 days. A folder's time changes when files directly inside it are added or removed, so it is a rough guide. It deletes nothing. Add -exec rm -rf {} + once you are happy with the list.

What you lose, and what you do not

• Lost: compiled products, the code index, module caches, build logs. The first build afterwards takes minutes on a big project, and Xcode's search and jump-to-definition are limited until it reindexes.
• Kept: your source, .xcodeproj or .xcworkspace, Swift Package checkouts that live in your project, signing settings, schemes, breakpoints and Archives.

Breakpoints and scheme settings are stored in the project and in xcuserdata inside it, not in DerivedData. If you see that advice elsewhere it is old.

The folders next to it that matter more than they look

Several guides stop at DerivedData. These other folders under ~/Library/Developer are the rest of the bill:

Archives is the dangerous one. It has the same parent folder, a name that sounds like backups of old builds, and a size that shows up in the same du run. The dSYM files you need to symbolicate crash reports sit inside each archive. A rebuild from the same source usually gets a different build UUID, so its dSYMs do not match the shipped app.

Things that look safe and are not

• Deleting DerivedData to fix a build error, over and over. It fixes stale module caches. It does not fix a real code or signing problem, and it pays the rebuild cost every time. Use Product > Clean Build Folder (Shift-Command-K) for the current project first.
• Deleting it while a build runs. Check Activity Monitor for xcodebuild, swift-frontend and swift-build. CI-style builds on your Mac write here too.
• Assuming it holds Swift package downloads. Swift Package Manager keeps cloned repositories in ~/Library/Caches/org.swift.swiftpm and, for projects, SourcePackages inside DerivedData. Removing DerivedData therefore forces package clones again, and an offline machine cannot do that. If you are on a plane, leave it alone.
• Custom location. A relative or shared DerivedData path set in Xcode or defaults may sit inside a project folder. Confirm the path in Settings before running rm against a glob.

Stop it coming back

DerivedData refills every build. The only lasting control is the habit: clear projects you have not opened in a month. The find -mtime +30 command above is the recurring version. Do not set a cron job to wipe the whole folder. It runs while Xcode builds and breaks the build.

Where Spotless fits

The Developer page in Spotless lists DerivedData per project, with sizes, and skips folders touched in the last 2 days or while Xcode is building. It also lists DeviceSupport, simulator caches and Swift package caches. It shows Archives but never offers them for removal. Removed items go to the Trash first. It looks in the default location, so a custom DerivedData path set in Xcode is not covered.

Keep going

• node_modules is taking up space on Mac: what to delete: Find every node_modules folder on your Mac, see which are largest, delete the ones you can reinstall, and clear the npm, pnpm and Yarn caches safely.
• Docker is taking up space on Mac: how to reclaim it: Why Docker Desktop holds tens of GB on a Mac, how to see what is inside, which prune commands are safe, and why the disk file may not shrink.
• How to clear the Homebrew cache on Mac: Find the Homebrew cache with brew --cache, preview what brew cleanup removes, and avoid the folders that look like cache but are your installed software.
• How a Spotless clean works: Scan, look, choose, review, Trash.

More guides