Delete Xcode DerivedData & Developer Caches Safely

What DerivedData is and why it gets huge

DerivedData is where Xcode keeps everything it derives from your source code: intermediate build objects, compiled products, module caches, symbol indexes for code completion and jump-to-definition, and build logs. It lives at ~/Library/Developer/Xcode/DerivedData by default, with one subfolder per project or workspace you have ever opened.

It grows for a structural reason: Xcode creates a DerivedData folder for every project you open — including one-off clones you built once and never touched again — and it never deletes any of them. Each folder holds separate build products per configuration and destination (Debug and Release, simulator and device), so a single mid-sized project can occupy several gigabytes, and the folder as a whole commonly reaches 20-50 GB on a working dev machine.

Everything in it is regenerable by definition — that is what "derived" means. Deleting DerivedData never touches your source code, your project settings, or anything under version control. The only cost is time: the next build of each project is a full clean build, and indexing runs again in the background for a few minutes.

Delete DerivedData

There are three ways to do it, and they end in the same place. Xcode's Clean Build Folder command (Product > Clean Build Folder, or Command-Shift-K) only clears build products for the currently open project — useful for fixing a weird build, but it barely moves the disk-space needle. To reclaim real space, delete the DerivedData folders themselves.

Deleting per-project is the surgical option: keep DerivedData for the two or three projects you build daily, and remove the folders for everything else. Deleting the whole thing is the fast option, and it is fine too — you just pay the full-rebuild cost on every project at once.

1. Quit Xcode first. Deleting DerivedData while Xcode is running can leave its indexer confused, and files Xcode has open may not delete cleanly.
2. Find the folder: in Xcode, open Settings > Locations, and click the small arrow next to the DerivedData path to reveal it in Finder. Or in Finder press Command-Shift-G and enter ~/Library/Developer/Xcode/DerivedData directly.
3. Sort the project subfolders by size, select the ones you want gone (or Command-A for all of them), and move them to the Trash. Trash first is the safer habit — you can restore instantly if you change your mind.
4. From Terminal instead: rm -rf ~/Library/Developer/Xcode/DerivedData deletes everything in one shot. It is faster than Finder for very large folders, but read the note below before using it.
5. Reopen Xcode and build. Expect the first build of each project to take noticeably longer, and expect "Indexing" to run in the activity bar for a while — both are one-time costs.

Be careful with rm -rf: it bypasses the Trash and deletes permanently, with no undo. Type the path exactly, never run it with sudo for this task, and if you are not comfortable in Terminal, the Finder route does the same job reversibly.

Clear old simulator runtimes

Simulators are usually the second-biggest developer space hog after DerivedData. Every iOS, watchOS, or tvOS runtime you have ever downloaded occupies 5-8 GB, and each simulated device keeps its own data folder under ~/Library/Developer/CoreSimulator/Devices. If you have been through a few Xcode upgrades, you likely have runtimes for iOS versions you stopped targeting years ago.

The quickest win is the built-in cleanup command: run xcrun simctl delete unavailable in Terminal. It deletes every simulator device whose runtime is no longer installed — the orphans left behind by old Xcode versions — and touches nothing you can still use.

For the runtimes themselves, open Xcode's Settings > Platforms (called Components in older Xcode versions). You will see each installed simulator runtime with its size; select an old one and delete it. Keep only the latest runtime per platform unless you actively test on older OS versions.

You can also prune individual simulated devices in Window > Devices and Simulators: switch to the Simulators tab, right-click any device you never use — the six duplicate iPhone models with data from old test runs — and choose Delete. Each device's saved data and apps go with it.

Archives, device support files, and caches

Archives accumulate at ~/Library/Developer/Xcode/Archives every time you run Product > Archive to distribute a build. Each archive contains a full app build plus its dSYM debug symbols, often 100 MB to 1 GB apiece. Before deleting, know the trade-off: the dSYMs inside are what let you symbolicate crash reports for that exact build. Keep archives for versions still live on the App Store or TestFlight (or confirm App Store Connect has the dSYMs), and delete the rest — the safest route is Xcode's Organizer (Window > Organizer > Archives), where you can review and delete them with context.

iOS DeviceSupport, at ~/Library/Developer/Xcode/iOS DeviceSupport, holds debugging symbols that Xcode copies from every physical iPhone or iPad you have ever plugged in — one folder per iOS version, typically 2-5 GB each. Folders for iOS versions none of your devices run anymore are pure dead weight: delete them, and if you ever connect a device on that version again, Xcode simply re-copies the symbols (you will see "Preparing debugger support" once). Sibling folders exist for watchOS and tvOS devices too.

Xcode also keeps its own caches under ~/Library/Caches/com.apple.dt.Xcode, and simulators keep theirs in ~/Library/Developer/CoreSimulator/Caches — both safe to clear when Xcode and the Simulator app are not running, and both rebuilt on demand.

Package manager caches (SwiftPM, CocoaPods, npm, Homebrew)

Package managers keep every dependency they have ever downloaded so future installs are fast. That is good engineering and bad disk hygiene: the caches only grow, and on a machine that has seen a few years of projects they quietly add up to 10-20 GB. All of them are safe to clear — the worst case is that your next install re-downloads packages.

Swift Package Manager caches downloaded packages at ~/Library/Caches/org.swift.swiftpm, and each project's resolved checkouts also live inside its DerivedData folder — so clearing DerivedData already clears those. The shared cache you can delete from Finder, or with rm -rf on that path.

CocoaPods keeps its downloaded pods at ~/Library/Caches/CocoaPods. The clean way to empty it is the built-in command: pod cache clean --all. Your projects' Pods folders are untouched; only the download cache goes.

npm's cache lives at ~/.npm and can reach many gigabytes on a JavaScript-heavy machine. Run npm cache clean --force to empty it (npm insists on the flag because the cache is self-healing and normally never needs cleaning — deleting it is still perfectly safe). pnpm users can run pnpm store prune instead.

Homebrew hoards old downloads and outdated package versions. brew cleanup removes outdated versions and stale downloads; brew cleanup --prune=all also empties the entire download cache. Run brew cleanup -n first if you want a dry-run list of what would go.

Automate it

Everything above works, but developer junk is a treadmill: DerivedData is back within a week of normal work, caches refill, and every Xcode update strands another runtime. If you would rather not re-run six manual procedures every month, this is the part worth automating — with a tool that shows its reasoning instead of silently bulk-deleting.

AskClean treats developer files as first-class categories: one scan itemizes Xcode DerivedData per project, old simulator runtimes (read via simctl, keeping the latest per platform), device support files, and package-manager caches for npm, SwiftPM, cargo, uv, and more. It also catches the newer space hogs — Hugging Face and Ollama model caches — which it lists per model and leaves unchecked by default.

Every item comes with an explanation — what it is, whether it can be rebuilt, what deleting costs — and nothing runs until you confirm it. Deletions go to the Trash so a mistaken click is a drag-and-drop away from undone, and your source code, documents, and photos are never touched. It is the same checklist as this guide, minus the hour of Terminal work.

FAQ