Cleaning developer caches on macOS without losing anything you need
Every build tool keeps a cache. On a working machine they add up to tens of gigabytes. The rule that makes cleaning safe is narrow, and it is worth stating before any command: delete only what the tool can rebuild from scratch.
The 13 things you can delete without losing data
| Category | Path | What rebuilding costs |
|---|---|---|
| Xcode build cache | ~/Library/Developer/Xcode/DerivedData | The next build is a full build |
| Xcode intermediates | DerivedData/*/Build/Intermediates.noindex | Same, but index data survives |
| SwiftPM cache | ~/Library/Caches/org.swift.swiftpm | Dependencies are re-resolved |
| CocoaPods cache | ~/Library/Caches/CocoaPods | Pods are re-downloaded |
| npm download cache | ~/.npm/_cacache | Packages are re-downloaded |
| pnpm store | ~/Library/pnpm/store | Every package, for every project, again |
| Yarn cache | ~/Library/Caches/Yarn | Packages are re-downloaded |
| Go build cache | ~/Library/Caches/go-build | Every package is recompiled |
| Gradle cache | ~/.gradle/caches | Dependencies and plugins are re-downloaded |
| Python bytecode | any __pycache__ | Recompiled on the next import |
| Rust build output | any target/ | A full cargo build again |
| Crash and hang reports | ~/Library/Logs/DiagnosticReports | Nothing — they are diagnostic output |
| Homebrew download cache | ~/Library/Caches/Homebrew | Formulae are re-downloaded |
Notice what every row has in common: the tool can regenerate it without asking you for anything. That is the whole test.
What looks like a cache and is not
~/Library/Developer/Xcode/Archives— your shipped builds and their dSYMs. Deleting these can cost you the ability to symbolicate a crash report from a version that is already in customers' hands.…/Xcode/iOS DeviceSupport— re-downloaded the next time you connect the device. Safe, but it is the difference between debugging now and debugging after a multi-gigabyte download.…/Xcode/UserData— code snippets, breakpoints, key bindings. Configuration, not cache.~/Library/Application Support/MobileSync/Backup— local iPhone/iPad backups. This is user data.~/Library/Containersand~/Library/Group Containers— application data.- Docker or OrbStack volumes — container data, not build output.
/Library/Caches— system-wide, needs admin rights, and can break running software.
Doing it by hand
Measure first, delete second:
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Caches/go-build ~/.gradle/caches ~/.npm/_cacache 2>/dev/nullThen remove only what you actually need the space from:
rm -rf ~/Library/Developer/Xcode/DerivedData/*
rm -rf ~/Library/Caches/go-build/*Two cautions nobody mentions until they bite: quit Xcode before removing DerivedData (a running build will keep writing into it), and never delete a cache while its tool is running.
Why we quarantine before we delete
A cache is safe to delete in principle. The interesting failures are the ones where the rule is slightly wrong for your setup: a project pinned to an old cache, a tool that keeps state in there, an archive you had forgotten was an archive.
So the app never deletes on the first pass. It measures, moves the payload into a quarantine folder, and starts a 30-day clock. If something breaks inside that window, one click restores it. Permanent deletion happens only after the window, is off by default, and requires six conditions to hold at once — fail any one and it aborts.
What to expect
For an actively used iOS project, DerivedData is usually the single biggest item (5–50 GB). Node and Rust caches are commonly 1–10 GB each; Gradle and Go a few GB. If your total is under a gigabyte, cleaning is not your disk problem — the Storage panel will show you what actually is.
See where your space actually went first. DisplayPilot's Storage panel breaks the disk down by category, tells you which of the 13 groups are worth cleaning, and quarantines everything for 30 days before it removes anything. 14-day trial, every feature, no account.
← Back to home