How to Delete Xcode DerivedData Safely

What DerivedData is

Every time Xcode opens, indexes or builds a project, it writes the results to ~/Library/Developer/Xcode/DerivedData. Nothing in there is source code. It is output Xcode can produce again from your project, so deleting it never loses your work. The catch is that Xcode never cleans it up on its own: a project you opened once two years ago still has its folder there.

On one developer's Mac we measured 17 GB in DerivedData spread over more than a hundred folders. Projects you build often, apps with many Swift packages and Flutter iOS builds (they show up as Runner-…) tend to be the largest.

What is inside

Each project gets its own folder named after the project plus a random-looking hash, for example MyApp-abcdefghijkl. Inside you will typically find:

• Build – compiled products and intermediate files for each configuration and destination.
• Index.noindex – the index that powers code completion, jump to definition and search.
• Logs – build, test and run logs shown in the Report navigator.
• SourcePackages – checkouts of the Swift packages the project depends on.

Next to the project folders there are shared caches used by all projects. ModuleCache.noindex holds precompiled Clang and Swift modules; recent Xcode versions also keep SDKExplicitPrecompiledModules. These are often several GB on their own and are just as safe to delete.

The hash in a folder name tells you nothing about where the project lives. Each folder has an info.plist with a WorkspacePath key, so you can map folders to projects from Terminal:

cd ~/Library/Developer/Xcode/DerivedData
# Size of each folder, largest last
du -sh * | sort -h
# Which project each folder belongs to
for f in */info.plist; do echo "${f%%/*}  $(plutil -extract WorkspacePath raw "$f")"; done

If the WorkspacePath points to a folder that no longer exists, that DerivedData folder belongs to a deleted or moved project and can go without a second thought.

Xcode's own way

Xcode does not have a single "delete DerivedData" button, but it shows you where the folder is. Open Xcode › Settings (⌘,), go to the Locations tab and look at Derived Data. Click the small arrow next to the path to open it in Finder. If you changed the location in the past, this is the path that counts, not the default one.

Product › Clean Build Folder (⇧⌘K) is not the same thing. It removes the build products of the current project so the next build starts from scratch, but it leaves the index, logs, package checkouts and the shared module cache in place. Use it when a build behaves oddly; delete DerivedData when you want the space back.

Deleting from Terminal

Quit Xcode first. If Xcode is open, it may still be writing into the folder, and it will immediately start recreating the folder of the open project.

# Everything (all projects and shared caches)
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# One project only (replace MyApp with the folder prefix)
rm -rf ~/Library/Developer/Xcode/DerivedData/MyApp-*

# Only the shared module cache
rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex

If you prefer the Trash, run open ~/Library/Developer/Xcode/DerivedData and drag folders there instead. Remember to empty the Trash, or the space will not come back.

Deleting per project is the better habit. Clear projects you no longer work on and keep the one you are building every day, so you only pay the rebuild cost where it buys you something.

What happens afterwards

Nothing breaks, but the next open of each project is slower:

• The first build is a full build. For a small app that is seconds; for a large app with many dependencies it can take many minutes.
• Xcode re-indexes the project. Code completion and jump to definition work poorly until indexing finishes.
• Swift packages are resolved and fetched again, which may need a network connection.
• Old build logs and test results in the Report navigator are gone for good. They are not usually needed, but if you were keeping a log to compare against, save it first.

When not to delete it

• During a build, test run or archive. Wait for it to finish or stop it.
• While an app you launched from Xcode is still running on a simulator or device and you are debugging it.
• Right before a deadline or a demo, if a full rebuild of your main project takes a long time. Clear old projects now and the active one later.
• When a fresh build is not possible right now, for example offline with packages that are not cached.

Archives live somewhere else

Archives you create with Product › Archive are not in DerivedData. They are in ~/Library/Developer/Xcode/Archives, sorted into folders by date, and they are not rebuildable in the same way: each archive holds the exact build you shipped together with its dSYMs, which you need to symbolicate crash reports from that version. Delete old archives from the Organizer (Window › Organizer › Archives), and keep at least the newest archive of every version that is still in users' hands unless its dSYMs are stored somewhere else. More on the other large developer folders in where macOS System Data comes from on a developer Mac.

Another folder in the same place, iOS DeviceSupport, also grows quietly; see what iOS DeviceSupport is and which versions to keep.

Doing it with CleanDev

The full edition of CleanDev (direct download, launching soon) scans DerivedData, including ModuleCache.noindex, and shows each folder with its project and size. Scanning is free; cleaning needs a subscription. CleanDev Lite on the Mac App Store does not handle Xcode folders.

• DerivedData of an app that is running or a build in progress is kept.
• Anything built in the last day is marked for review instead of being selected.
• Old archives go to the Trash, never straight to deletion; the newest archive and archives from the last 90 days are marked for review.