DerivedData is not the biggest thing in ~/Library/Developer

Every Xcode cleanup guide gives the same instruction: delete DerivedData. It is the right first move, it is completely safe, and on a Mac that has shipped anything it is frequently not the biggest folder in there.

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

Four things account for nearly all of it, and they are not equally safe.

Archives are the one thing here you can lose for good

An archive is the built app plus its debug symbols. Those symbols are what turn a crash report from a shipped build into file names and line numbers. Without them, a crash report from that version is a list of memory addresses and stays that way permanently.

So the rule is not size, it is whether anyone is still running the build. Delete archives for versions nobody has installed any more, and keep the archives for anything currently in the store or in testing, however old they look.

The readable way through them is Xcode's own Organizer: Window, then Organizer, then the Archives tab. It lists them by app and version with a date, which is the context the folder names lack. Right click one and choose Show in Finder to see what it weighs.

du -sh ~/Library/Developer/Xcode/Archives/* | sort -rh

iOS DeviceSupport is per OS build, not per device

Every time you attach an iPhone or iPad, Xcode copies a set of symbols for that exact iOS build so it can debug against it. It keeps a folder per build, forever, including builds that no device you own still runs.

du -sh ~/Library/Developer/Xcode/"iOS DeviceSupport"/* | sort -rh

If you have tested across a couple of years of iOS releases, this is a stack of multi gigabyte folders for versions that are now irrelevant. Deleting them is safe: attaching a device on that build again recreates the folder, which costs a few minutes of waiting once.

The order worth working in

1. Archives for builds nobody runs. Largest safe win per gigabyte, but read the section above first and decide per version rather than in bulk.
2. iOS DeviceSupport for old OS builds. Keep the two or three you actually test against, delete the rest.
3. DerivedData, which is pure build output. The full explanation of what is inside it, including why deleting it fixes a class of build error as a side effect.
4. Simulator runtimes and stale devices, usually the biggest number of the four. Reclaiming simulator space covers unavailable devices, which are the ones that quietly pile up.

Together these four are commonly 40 to 100 GB on a Mac that has done a year of iOS work, and all but the archives regenerate themselves. If the disk is still tight afterwards, the safest order to free 100 GB works through what is left.