Is it safe to delete DerivedData on a working Mac?

A working iOS engineer published a piece called Reclaim 100+ GB from Xcode: The Cleanup Script I Wish I'd Written Years Ago. He shipped apps for a decade and still wrote a personal shell script, because every iOS dev asks the same question at 11pm with a red "disk almost full" banner in the corner: is it safe to delete DerivedData, or am I about to break something I cannot rebuild?

The answer is yes, with a handful of edge cases worth knowing. This post is the safety audit, not the how-to. If you just want the commands, the safely delete Xcode DerivedData guide covers those. Here we look at what can actually go wrong, what cannot, and how a cautious dev should think about clearing the largest folder on the average iOS developer Mac.

What does "safe" actually mean for a build cache?

The word "safe" gets thrown around loosely in the Mac cleaner space. For a working dev Mac it has a specific meaning, and DerivedData passes the test on every axis.

Safe to delete means four things at once:

1. No source of truth is lost. Your code is in git. Your project file is in git. Your signing identities are in Keychain.
2. The folder is regenerated automatically on the next normal use of the tool. No manual reinstall, no license rekey, no resync.
3. The deletion cannot escalate out of the user account. The folder is owned by your user and read only by Xcode tooling.
4. The worst case is a slow first build, not a corrupted project.

DerivedData clears all four bars. The only thing you lose is the time Xcode previously spent compiling, which it will spend again on the next build. That trade is almost always worth it when the folder is 40 GB and your disk is 95 percent full.

What is actually inside DerivedData, and which of it has any value?

People treat DerivedData as a single blob. It is not. Six things live inside, with very different value to you.

Notice what is not in the list. There is no source code, no .xcodeproj file, no entitlements, no provisioning profile, no code signing certificate, no archive, no simulator runtime, no preview cache that ships to a user. Everything in DerivedData is downstream of your real project. Everything is recomputable.

The only entry worth a second thought is Logs/. If you are debugging a flaky CI failure and want to compare today's build log to yesterday's, those logs are gone after the delete. For 99 percent of cleanup runs nobody opens them. For the 1 percent that does, copy Logs/ out before the delete.

When is it not safe to delete DerivedData?

This is where most "safe to delete" posts hand-wave. There are exactly four situations where the timing matters, and one where the answer flips.

The four timing edge cases:

• A build is running. Xcode is mid-compile, writing object files into Build/Intermediates.noindex/. Deleting the folder under it can leave the build process holding open file handles to paths that no longer exist. Worst case: Xcode hangs and you have to force quit. Always quit Xcode first.
• A simulator is recording an .xcresult you have not opened yet. The .xcresult lives inside the Logs/Test/ subfolder. If you have not opened the result in Xcode and you delete DerivedData, the test report is gone. Same fix: quit Xcode and review the result first.
• A SwiftUI preview is rendering. Previews use the same module cache. A mid-render delete throws a "preview crashed" error in your face. Wait until previews are idle.
• You are about to demo. Deleting DerivedData triggers a 1 to 5 minute first build. Do not do this 10 minutes before a stakeholder call. Do it after.

None of these are corruption. They are inconvenience.

The one situation where the answer flips: if you are using a project that depends on a build artifact you cannot reproduce. This is rare but real. Some legacy iOS apps import a closed-source .framework that lives only inside DerivedData/Build/Products/ because nobody checked it into git or set up a binary dependency. If you cannot find the original .framework, do not delete DerivedData until you do. Run this check first:

# List every framework currently sitting in DerivedData
find ~/Library/Developer/Xcode/DerivedData -name "*.framework" -type d 2>/dev/null

# Cross-reference with what your project references
grep -r "framework" ~/path/to/YourProject.xcodeproj | grep -v "SDKs"

If you find a framework in DerivedData that your project references but git does not track, stop. Copy it out before the delete. Otherwise carry on.

Is rm -rf ~/Library/Developer/Xcode/DerivedData/ dangerous?

The rm -rf command is the operation everyone is nervous about. The nervousness is usually about the wrong thing. rm -rf is dangerous when:

• The path is wrong. A typo at the root, an unquoted variable that expands to /, a stray space between rm -rf / and a folder name.
• The path has elevated privileges. sudo rm -rf can reach into system folders that should never be touched.
• The path is on a network mount. Recursively deleting a mounted share can wipe shared state.

None of these apply to the standard DerivedData path. It is fully qualified, it lives under your home folder, it requires no sudo, and it is on the local volume. The command is mechanically safe.

The reason CleanMyDev still prefers mv to Trash over rm -rf is not that rm -rf would harm macOS. It is that Trash is undoable. If you delete DerivedData and then discover that one of those .framework files mattered, Trash is a one-click recovery and rm -rf is not. Reversibility is a feature, not a performance cost.

# What CleanMyDev runs under the hood, on click
mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/DerivedData-$(date +%s)

# Equivalent rm command, faster but unreversible
rm -rf ~/Library/Developer/Xcode/DerivedData

Pick the first form on a project you might still need to debug today. Pick the second on a CI runner where speed matters and the cache is reproducible from scratch.

What about iCloud Drive, Time Machine, or backup software?

Three more "but what about" questions worth closing.

iCloud Drive does not sync ~/Library/Developer/. Apple specifically excludes the developer library from iCloud, so deleting DerivedData has zero effect on any cloud copy because no cloud copy exists.

Time Machine, by default, excludes ~/Library/Developer/Xcode/DerivedData/ from backup. Apple ships the exclusion in /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist. So no, your backup is not bloating because of DerivedData, and no, deleting it will not destroy a Time Machine snapshot.

Third-party backup tools, including Backblaze and Arq, often follow Apple's exclusion list by default. If you customized those exclusions, check. Otherwise you are fine.

How does a "is it safe" reader compare DerivedData to other dev caches?

DerivedData is the safest large folder on an iOS dev Mac. But "safest" is relative, so here is the honest ranking against the other big targets a developer cleaner will offer.

DerivedData sits at the top of the safety list. Archives sit at the bottom. The AI coding tool folders sit in the middle. The full safety ranking is the point of a review-first cleanup philosophy: some folders you can delete blind, some you should audit first, and some you should never touch without understanding what is inside.

What does CleanMyDev do differently for DerivedData?

The skeptical answer to "is it safe to delete DerivedData" is yes. The realistic problem is not safety, it is friction. You have to remember the path, quit Xcode, confirm the size is worth the rebuild time, remember whether you set up unusual build dependencies, and do it again next month.

CleanMyDev replaces the ritual with three lines on a screen:

• Total size of every DerivedData subfolder, computed live.
• Last build date, so you know if the cache is from this week or from October.
• A list of .framework and .a files inside, so you can spot anything that does not come from a known dependency.

Then it moves the folder to Trash by default, not rm -rf. You can recover in one drag. That is the model: receipts before deletion, reversible by default, no surprise sudo prompts. If you have ever asked "is it safe to delete DerivedData" at 11pm with a near-full disk, CleanMyDev for $9.99 lifetime is the version of yes that gives you receipts.

Related reading

• Safely delete Xcode DerivedData on Mac
• Move to Trash vs rm -rf: what dev cleaners should actually do
• The CleanMyDev safety model, explained