Skip to content

Xcode quietly keeps 50 GB you will never look at

DerivedData, archives, device support files and simulator runtimes accumulate with nothing ever clearing them. Here is what each one is and which are safe to remove.

  • Xcode
  • Developer
  • Cleanup

Xcode is the single largest consumer of disk space on most Macs that have it installed, and the application bundle is the smallest part of that. The rest is spread across four folders in ~/Library/Developer, none of which Xcode ever cleans up, and all of which grow every time you build.

The four folders

PathWhat it holdsSafe to delete
~/Library/Developer/Xcode/DerivedDataBuild output, indexes and module caches, per projectYes, entirely
~/Library/Developer/Xcode/iOS DeviceSupportDebug symbols for every iOS version you ever attached a device runningYes, redownloads on next connect
~/Library/Developer/CoreSimulator/DevicesEvery simulator you have created, with its whole filesystemYes, via the command below
~/Library/Developer/Xcode/ArchivesEvery build you have archived for distributionOnly if you do not need to symbolicate old crash reports

DerivedData, the big one

DerivedData holds a full set of build products and indexes for every project you have opened. It is regenerated on demand, it is never pruned, and stale entries survive long after the project is gone. Deleting the whole folder is safe. The cost is that your next build of each project is a clean build, which for a large project can be several minutes.

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

Deleting DerivedData is also the standard fix for a project that will not build for no visible reason, which is why iOS developers end up doing it regularly anyway.

Simulators, the one people forget

Each simulator device is a complete filesystem image. Create a few over the years across several iOS versions and this passes 30 GB without ever being visible. Xcode has a built-in command for the unused ones:

xcrun simctl delete unavailable

That removes simulators for runtimes no longer installed. To see everything first, run xcrun simctl list devices and delete specific ones by UDID.

Device support, the invisible one

Every time you plug in an iPhone running an iOS version Xcode has not seen, it copies that version's debug symbols to the Mac. They are roughly 3 to 7 GB each, they are kept forever, and a folder for iOS 14.2 is of no use once no device on your desk runs it. Delete the old ones; if you attach such a device again Xcode fetches them back.

What this adds up to

On a machine that has done iOS work for a year or two, 40 to 80 GB across these four folders is normal, and it is all reclaimable. Combined with the node_modules problem it is usually most of what a developer needs to free.

Free Mac's Dev tab lists these four alongside package manager caches and Docker images with current sizes, so you can see the total before deciding. Scanning is free.

Common questions

Is it safe to delete Xcode DerivedData?

Yes. DerivedData contains only build products and indexes, all regenerated from your source. Deleting it forces a clean build the next time you open each project, which takes longer but produces the same result. It is also the standard first fix for a project that has started failing to build for no clear reason.

How much space does Xcode use on a Mac?

The application itself is roughly 10 to 15 GB, but the supporting folders in ~/Library/Developer usually exceed it. DerivedData, simulator devices, iOS device support and archives together commonly reach 40 to 80 GB on a machine used for iOS work over a year or more.

Will deleting simulators lose my app data?

It deletes any app data inside those simulators, which for most development work is test data you can recreate by running the app again. If you have a simulator holding a state that is hard to reproduce, delete the others individually with xcrun simctl delete rather than clearing everything.

Read next