Why Xcode takes up 50+ GB on your Mac (and what's safe to delete)

Open Storage settings after a year of iOS work and Xcode's fingerprints are everywhere, except Xcode never appears by name. If Xcode is taking up space on your Mac, it's buried inside "Developer" and "System Data": build caches, per-device symbol folders, and simulator runtimes that pile up and never clean themselves. Here's exactly where the gigabytes go, and which folders you can delete without losing anything you can't regenerate.

Why Xcode keeps taking up space on your Mac

None of the big folders are your source code. They're generated artifacts and caches that Xcode creates as you build, run, and debug, and most of them are never pruned automatically. An active developer's Xcode footprint commonly totals 20–50 GB, and it's easy to climb past that. Here's the breakdown, each with its real path:

The two silent killers are DeviceSupport and CoreSimulator. Every physical device on a new iOS version leaves its own 5–8 GB symbol folder, and those never get deleted. Debug against three phones over two iOS releases and you've got 30 GB of symbols alone. Simulators are worse: each installed runtime is multiple GB, and old ones linger long after you've stopped targeting that iOS version.

See the big hitters first

Before deleting anything, measure. This lists each top-level Developer folder by size, so you delete the actual offenders instead of guessing:

du -sh ~/Library/Developer/*

To drill into the per-version DeviceSupport folders:

du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

What's safe to delete

DerivedData: always safe

DerivedData is a pure cache. Deleting it is the single safest, highest-value cleanup:

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

Xcode rebuilds it from your project on the next build. That first build after is slower, since indexes and the module cache have to regenerate, and then you're back to normal. It's the Xcode equivalent of deleting node_modules: generated, not source, fully reproducible. (See is it safe to delete node_modules for the same logic on the JavaScript side.)

Old simulators and runtimes

Remove simulators whose runtimes you no longer have installed:

xcrun simctl delete unavailable

That clears the orphaned devices. To reclaim the runtimes themselves (the multi-GB disk images), delete unused ones in Settings → Components (Xcode 16+), or list and remove them with xcrun simctl runtime list and xcrun simctl runtime delete. You can also delete individual simulators under Window → Devices and Simulators.

Old DeviceSupport folders

These are the ones nothing prunes for you. Each folder is named for an iOS version (e.g. 17.4, 18.1). Delete the ones for versions you no longer debug against:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.4

If you plug that device back in later on that iOS version, Xcode regenerates the folder; it just takes a minute the first time.

Archives you've already shipped

Archives at ~/Library/Developer/Xcode/Archives accumulate one per build you distribute. Old ones are safe to delete with one caveat: each archive contains the .dSYM debug symbols needed to symbolicate crash reports for that build. If a version is still live in the App Store and you rely on readable crash logs, keep its archive (or at least export and stash the .dSYM) before deleting. For builds long retired, delete freely from Window → Organizer.

Xcode 16 cleans up some of this, but not the big stuff

Newer Xcode versions improved automatic cleanup of certain internal caches, so DerivedData is a little better behaved than it used to be. But the folders that actually dominate your disk (DeviceSupport, simulator runtimes, and Archives) still need manual attention. They're not touched by any auto-pruning, which is why a machine that's been building iOS apps for a couple of years quietly holds 30–80 GB of reclaimable Xcode data. If your whole disk feels mysteriously full, this is often a big slice of the "System Data" that Storage settings won't itemize. See where hidden storage actually goes on a Mac for the full map.

Do it without hunting through Terminal

Running du, eyeballing version numbers, and hand-deleting folders works, but it's tedious, and one careless rm -rf in the wrong directory is unforgiving. Plumby finds Xcode's DerivedData, every old iOS DeviceSupport folder, and stale simulators, shows each one with its exact path and measured size, and clears only what you approve. It acts only on your command, and it never touches your source, just the regenerable build junk. If you want the wider picture of a developer machine's cruft (node_modules, Docker.raw, package caches), the best Mac cleaner for developers breakdown covers the rest.