Xcode is using 50 GB: DerivedData, simulators, archives and device support

Where the 50 GB is

Xcode itself is around 10–15 GB in /Applications. Everything else lives in ~/Library/Developer, and unlike the app it grows monotonically: nothing in there is ever cleaned up automatically, across years and Xcode versions.

Rank it before deleting anything. This is read-only:

du -h -d 2 ~/Library/Developer 2>/dev/null | sort -rh | head -25
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/CoreSimulator

DerivedData — always safe to delete

Path: ~/Library/Developer/Xcode/DerivedData. It holds build intermediates, module caches, indexes and build products for every project you have ever opened, keyed by a hash of the project path — which means renaming or moving a project leaves the old directory behind forever.

It is entirely rebuildable. The only cost of deleting it is one slow rebuild and a re-index per project. On a machine with a year of iOS work it is often 20–60 GB, and it is the single best first action.

Quit Xcode first, then delete the contents rather than the directory itself.

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

# Safer: move it to the Trash so it is recoverable
mv ~/Library/Developer/Xcode/DerivedData/* ~/.Trash/

rm -rf has no undo. The second form is the one to use unless you are certain.

Simulator runtimes and devices — the usual second-largest item

Path: ~/Library/Developer/CoreSimulator. Two things live here and they behave differently.

Downloaded runtimes are the actual iOS/watchOS/tvOS system images, 6–10 GB each. Upgrading Xcode downloads a new one and keeps the old, so a machine that has been through four Xcode releases can be holding 30 GB of runtimes for OS versions nobody targets any more. Manage them in Xcode → Settings → Platforms, or with simctl.

Simulator devices are the individual simulated iPhones under CoreSimulator/Devices, each with its own installed apps and data. They accumulate as Xcode creates a device per model per runtime. `simctl delete unavailable` removes any device whose runtime no longer exists — it is safe and usually the biggest easy win here.

# List what exists
xcrun simctl runtime list
xcrun simctl list devices

# Remove devices whose runtime is gone (safe)
xcrun simctl delete unavailable

# Remove a specific runtime by its identifier from the list above
xcrun simctl runtime delete <identifier>

iOS DeviceSupport — safe, and it comes back

Path: ~/Library/Developer/Xcode/iOS DeviceSupport (also watchOS and tvOS variants). Every time you debug against a physical device running an OS version Xcode has not seen, it copies that version's symbols to your Mac — 3–8 GB per version.

You can delete any of them. The only consequence is that reconnecting a device on that version triggers the copy again, which takes a few minutes. Delete the folders for OS versions you no longer have devices on.

du -h -d 1 ~/Library/Developer/Xcode/"iOS DeviceSupport" | sort -rh

Archives — read this before deleting

Path: ~/Library/Developer/Xcode/Archives. This is the one directory in Xcode that is not regenerable, and it is where people make an expensive mistake.

An archive contains the compiled app *and its dSYM debug symbols*. The dSYM is what turns a crash report from a shipped build into readable line numbers. Delete the archive for a version that is live in the App Store and you lose the ability to symbolicate crashes from your own users, permanently — you cannot recreate it, because a rebuild produces different UUIDs.

The right policy is to keep archives for every version currently in the store or in TestFlight, plus a couple of releases back, and delete the rest — plus every archive from a debug or ad-hoc build you never shipped, which is most of them. Better still, upload dSYMs to your crash reporter and keep archives only for shipped builds.

Archives are not backed up by Xcode anywhere. If they are not in your Time Machine backup, deleting them is final.

The smaller directories

Several more grow quietly and are all safe:

• ~/Library/Developer/Xcode/UserData/Previews — SwiftUI preview build products. Rebuildable, often several GB.
• ~/Library/Caches/com.apple.dt.Xcode — Xcode's own cache. Rebuildable.
• ~/Library/Developer/CoreSimulator/Caches — downloaded runtime disk images awaiting install. Safe.
• ~/Library/Developer/Xcode/DocumentationCache and downloaded documentation sets — re-downloadable.
• ~/Library/Developer/XCPGDevices — Playground devices. Safe.
• ~/Library/Application Support/MobileSync/Backup — iOS device backups. Not Xcode, but it sits next door and is often several GB per device. Delete these through Finder's device screen, not by hand.
• ~/Library/Developer/Xcode/Products and old Instruments traces (.trace) — safe once you are done with them.

Why it grows without bound

It is worth understanding the mechanism, because it explains why this is a recurring chore rather than a one-off.

DerivedData is keyed by a hash of the project's absolute path. Move a project, rename its enclosing folder, or check the same repository out twice, and Xcode creates a second directory and never removes the first. Over a year of moving things around, a large share of DerivedData belongs to paths that no longer exist.

Simulator runtimes are additive by design: Xcode 26 does not assume you have stopped supporting iOS 17, so it keeps the old runtime installed. That is the right default — nothing is worse than a toolchain that deletes something you needed — but it means the decision to remove them has to be yours, and nothing will ever prompt you to make it.

iOS DeviceSupport is keyed by OS build number, not by device, so a single phone that updates monthly leaves a new several-gigabyte directory behind every time. Archives accumulate one per build you archived, including every failed upload attempt.

None of this is a bug. It is a set of caches with no eviction policy, on the reasonable assumption that a developer machine has a large disk. The assumption stops holding somewhere around the second year.

A sensible routine

After every major Xcode upgrade: clear DerivedData, run `xcrun simctl delete unavailable`, and remove runtimes for OS versions below your deployment target. That takes two minutes and typically returns 20–40 GB.

Once a year: review Archives against what is actually live, and clear iOS DeviceSupport for devices you no longer own.

Dropit bundles these as Quick Wins with the sizes already computed, so you can see that DerivedData is 34 GB and that you are holding four unused simulator runtimes without running anything. Each row carries the reason it is safe — "Xcode regenerates this on the next build" — and archives are deliberately classified as needing review rather than safe, for the dSYM reason above. Looking is free; staging the selection and sending it to the Trash is the paid half.