How do I safely delete Xcode DerivedData?

A working iOS engineer wrote a blog post last year titled Reclaim 100+ GB from Xcode: The Cleanup Script I Wish I'd Written Years Ago. He had been shipping apps for a decade. He still ended up writing a personal shell script, because Xcode does not clean up after itself and a typical iOS developer Mac carries somewhere between 80 and 150 GB of Xcode-only artifacts at any given moment. The single biggest contributor to that pile is ~/Library/Developer/Xcode/DerivedData/.

The question this post answers: can you actually delete it? What is inside? What breaks if you do? And what is the safest way to do it on a working machine you cannot afford to reset?

What is Xcode's DerivedData folder, and what is inside it?

DerivedData is the per-project working directory Xcode uses while it compiles. Every time you build, run, or even open a Swift file, Xcode reads from and writes to this folder. The default path is:

~/Library/Developer/Xcode/DerivedData/

Inside, each project gets its own subfolder. The name is the project name followed by a hash, like MyApp-bxqgxyfygpvnaxbymtoughdkbnam. The hash makes the folder unique per project location, so two clones of the same repository each get their own cache instead of stomping on each other.

Each subfolder typically holds these pieces:

The pattern is consistent. Everything in DerivedData is regenerated from your source code, your project file, and the network. None of it is a source of truth.

Is it safe to delete DerivedData on a working project?

Yes. The short answer is unambiguous, but the longer one helps you predict the side effects so you do not get caught off guard.

When you delete DerivedData, the very next time you open Xcode and build:

• Compile time will be longer. A full clean build for a medium iOS app is 1 to 5 minutes depending on Swift Package count.
• SwiftUI previews need to recompile before they preview. Expect a 30 to 90 second pause the first time you open a View file.
• Indexing kicks off. The "Indexing" indicator in the Xcode toolbar will run for several minutes on a large project before symbol search becomes reliable again.
• Swift Package Manager will reresolve and redownload packages. If you are offline, this fails until you reconnect.

Things that do not change when you delete DerivedData:

• Source files, project files, scheme settings, build settings.
• Code signing identities, provisioning profiles, certificates in your keychain.
• Simulators, simulator runtimes, downloaded iOS DeviceSupport.
• Anything in ~/Library/Developer/Xcode/Archives/, which is your shipped builds.
• Anything in ~/Library/Developer/CoreSimulator/, which is your installed simulator devices.

DerivedData is the safest large folder to clear on an iOS developer Mac. It is built to be rebuilt.

How do I delete Xcode DerivedData from Terminal?

The two reliable approaches are Finder and Terminal. Both work. The Terminal approach is faster on a 50 GB folder because it skips the Finder size pre-scan.

# Quit Xcode first so it isn't writing to the folder
osascript -e 'quit app "Xcode"'

# Check the size before
du -sh ~/Library/Developer/Xcode/DerivedData

# Option A: move the whole folder to Trash (safe, reversible)
mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/DerivedData-$(date +%s)

# Option B: clear just the contents (keeps folder permissions)
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# Reopen Xcode. It will recreate the folder on the next build.
open -a Xcode

Two notes on the snippet above.

First, the mv into ~/.Trash is recoverable for as long as you do not empty Trash. rm -rf is not. On a working machine where you might want to roll back if a project misbehaves, prefer the move.

Second, quitting Xcode matters more than people think. If Xcode is running and writing to Build/Intermediates.noindex/ while you delete the parent folder, the build process can hold onto unlinked inode handles and waste disk in /Volumes/.Trashes/, or worse, leave a half-deleted index that confuses the next open.

Does Xcode's Clean Build Folder do the same thing as deleting DerivedData?

No. They are different operations with different scopes.

Clean Build Folder is the right tool when a single build is acting up and you want to recompile from scratch. It does not touch indexes, the module cache, or other projects.

Deleting DerivedData is the right tool when your disk is full and you want the whole 50 GB pile gone. It costs you a longer build on the next compile across every project, but the reclaim is an order of magnitude larger.

What is the most disk-efficient way to manage DerivedData long term?

Three habits cover most of the value.

1. Set a custom location on an external drive if your internal disk is small. In Xcode, go to Settings, Locations, Derived Data, Custom, and point at an external SSD. You lose nothing except a small amount of build performance for the first few seconds.
2. Delete on a schedule, not on a panic. Once a month is enough for most iOS developers. The cost is a single slow build per project per month, in exchange for a flat disk usage curve.
3. Audit before you nuke. If one project's subfolder is 15 GB while everything else is 1 GB, that is a signal something is wrong with that project's package graph or asset catalog, not a sign that you need to delete more often.

For the audit-before-nuke step, this command gives you a sorted per-project breakdown:

du -h -d 1 ~/Library/Developer/Xcode/DerivedData 2>/dev/null \
  | sort -hr \
  | head -20

That is the same audit CleanMyDev runs on every scan, bundled with one-click move-to-Trash, last-modified dates, and a risk label for every other folder under ~/Library/Developer/Xcode/. The Xcode disk space full fix guide walks through the full Xcode cleanup beyond DerivedData. If you want to keep going after this folder and start on simulators next, see reclaim disk from Xcode simulators.

When should I not delete DerivedData?

A short list, because most of the time it is fine.

• During a release build for the App Store, do not delete halfway through. Wait until the archive lands in ~/Library/Developer/Xcode/Archives/, which is not inside DerivedData and is safe.
• During an active CI run on a shared build machine. The agent owns that folder for the duration of the job.
• Right before a demo where you do not have five minutes for a rebuild. Delete after the demo, not before.
• If a particular project takes 30 minutes to build cold, time-box your deletion to weekends. Cold builds compound across a working day.

That is the whole list. Outside those cases, the answer is yes.

How does DerivedData fit into the larger System Data picture?

DerivedData is the headline number, but it is rarely the only Xcode-related folder eating disk. The full Xcode footprint on a long-running developer Mac looks like this:

DerivedData is the largest single contributor, but the rest add up to roughly the same amount on a 12 to 18 month old machine. Clearing DerivedData buys you the biggest reclaim per click, then the simulator runtimes are the next obvious target.

Get DerivedData on a one-click move-to-Trash

CleanMyDev was built because manually managing ~/Library/Developer/Xcode/DerivedData/ is the kind of task developers do once during a disk-full panic and then forget about for six months. Every CleanMyDev scan shows DerivedData with its size, last modified date, and per-project breakdown, alongside the 110-plus other developer paths that drive System Data growth on an iOS developer Mac. Move-to-Trash by default. Lifetime license, no subscription, no telemetry. Get CleanMyDev on the pricing page.

Related reading

• Reclaim disk from Xcode simulators
• Xcode disk space full: a 100 GB cleanup walkthrough
• The Xcode Archives folder, explained