How to clear Xcode DerivedData (rm DerivedData)

What Xcode actually stores on your disk

Everything lives under ~/Library/Developer/. Run this to see the damage:

du -sh ~/Library/Developer/* | sort -hr

A typical active iOS developer's breakdown looks like this:

How to clear Xcode DerivedData

Quit Xcode first. DerivedData holds build products, module caches, the source-code index, and build logs. It does not hold the source you wrote. Xcode regenerates it. The cost is one full rebuild per project, then a few minutes of indexing.

du -sh ~/Library/Developer/Xcode/DerivedData
rm -rf ~/Library/Developer/Xcode/DerivedData

Or open Xcode Settings, then Locations, then the arrow next to Derived Data, and delete one project folder.

DevCleaner can show DerivedData as separate rows: Compilation Cache, Module Cache, Symbol Cache, SDK Stat Caches, and per-project folders. That lets you clear one cache without deleting every project folder. Finder can also overstate Compilation Cache size when the files are sparse. The Compilation Cache guide compares apparent size with allocated size. The same scan, without Terminal, is described on the Xcode cleaner page.

DerivedData: the big one

It is safe to delete DerivedData. It contains nothing you authored ; only build products, module caches, the source-code index and build logs. Xcode regenerates all of it. The cost: your next build of each project is a full rebuild, and indexing (autocomplete, jump-to-definition) takes a few minutes to come back.

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

Or per-project from Xcode itself: Settings → Locations → DerivedData → arrow icon, then delete the folder named after your project.

Compilation Cache and allocated sizes

DerivedData includes CompilationCache.noindex, Module Cache, Symbol Cache, SDK Stat Caches and project-specific data. DevCleaner separates these so you can review one cache without deleting every project folder. Sparse Compilation Cache files can have a large logical size but much smaller allocated usage. Compare both measurements in the Compilation Cache guide.

Simulators: where the silent gigabytes are

Each simulator device keeps its own data directory, and unavailable simulators ; devices left over from old Xcode versions ; keep theirs forever. Delete every simulator that the current Xcode can no longer use:

xcrun simctl delete unavailable

To see what each remaining simulator weighs:

du -sh ~/Library/Developer/CoreSimulator/Devices/* | sort -hr

Erasing a simulator's content (apps, photos, caches) without deleting the device:

xcrun simctl erase <device-udid>

iOS DeviceSupport: old symbols are removable, but not zero-cost

Every time you attach an iPhone running an iOS version Xcode hasn't seen, it copies that version's debug symbols to ~/Library/Developer/Xcode/iOS DeviceSupport. Deleting an older folder frees space, but Xcode re-downloads its symbols the next time you connect a matching device. Treat it as a Warning, not a pure cache: keep the versions you still debug and remove only older ones.

DevCleaner lists DeviceSupport per version and, by default, keeps the two newest versions. Older versions are opt-in. If you clean manually, remove one confirmed-old version at a time rather than wiping the entire folder:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/<old-ios-version>

Archives: be careful here

~/Library/Developer/Xcode/Archives holds your .xcarchive bundles ; including the dSYM files you need to symbolicate crash reports for versions that are live on the App Store. Delete old archives of versions nobody runs anymore; keep anything still in production. This is why archives should never be part of an automatic "clean everything" sweep.

The rest of the list

• SwiftUI Previews ; ~/Library/Developer/Xcode/UserData/Previews, fully regenerable.
• Old simulator runtimes ; macOS keeps downloaded iOS runtimes as disk images. List them with xcrun simctl runtime list and delete superseded ones with xcrun simctl runtime delete <id>.
• Module cache ; inside DerivedData, goes with it.
• Documentation cache ; ~/Library/Caches/com.apple.dt.Xcode, safe.

FAQ

Is it safe to delete Xcode DerivedData?

Yes ; it's all regenerable build state. The only cost is one full rebuild per project and a few minutes of re-indexing. Just don't do it while a build is running.

How often should I clear it?

Whenever it gets big or builds start behaving strangely. Many developers clear it monthly; an automatic age-based rule (e.g. "delete anything untouched for 30 days") keeps it bounded without losing warm caches for active projects.

Does "Clean Build Folder" in Xcode do the same thing?

No. ⇧⌘K only cleans the current project's build products. It leaves indexes, logs, other projects, and everything else in this guide untouched.

Can I move DerivedData to an external disk?

You can (Settings → Locations), but build performance suffers on anything slower than internal NVMe. Cleaning regularly is usually the better trade.

References and scope

Reviewed for DevCleaner 1.14.5 on October 4, 2026. Paths depend on tool version and configuration. Size ranges are illustrative, not measured savings or a recovery guarantee. Check the installed tool’s version/help before running cleanup commands.

• Apple Xcode build settings