Xcode is eating the disk: DerivedData, simulators and archives

Q: Why did the free space not change after I deleted all that?

Check the Trash first if you dragged rather than used rm. If the space still has not appeared, macOS may be holding it in local Time Machine snapshots or reporting it as purgeable, both of which release on their own schedule rather than immediately.

9 September 2026 · 5 min read

Xcode.app is several gigabytes on its own. Everything else it accumulates lives outside the app, mostly under ~/Library/Developer, and on a machine that has been building for a year or two that folder is usually the larger number. Almost all of it regenerates, which makes it the easiest large thing on a developer’s Mac to reclaim.

The question is not whether it is safe to delete. It is what deleting each part costs you the next time you build.

Measure it first

Quit Xcode, open Terminal and look before you touch anything.

du -sh ~/Library/Developer/Xcode/*
du -sh ~/Library/Developer/CoreSimulator
du -sh /Applications/Xcode.app

du walks every file, so on a large DerivedData folder this takes a minute or two. Let it finish. What usually comes back is one or two folders holding the majority of the total and a long tail that is not worth your attention.

Do the same for /Library/Developer (no tilde) if you have ever installed command line tools or extra platform support system-wide.

DerivedData

~/Library/Developer/Xcode/DerivedData holds build products, module caches and the index that powers jump-to-definition. There is one folder per project, named after the project with a hash appended, and nothing in there is source.

It is safe to delete in full. The cost is a clean rebuild of everything you touch next, plus reindexing, which on a large project is minutes rather than seconds.

You can delete it from the command line:

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

Or reveal it first from Xcode: Settings, Locations, then the arrow beside the Derived Data path. Revealing it in Finder is the better habit, because you can sort by size and delete only the folders belonging to projects you no longer have. Those are the ones that never get rebuilt and never shrink.

One thing to know: resolved Swift package checkouts live inside each project’s DerivedData folder under SourcePackages. Deleting them means the next build re-resolves and re-downloads dependencies, so do not do it on the plane.

Simulators and runtimes

Two separate things share a name here, and they behave differently.

Simulator devices are the individual iPhone and iPad instances, each with its own installed apps and data, under ~/Library/Developer/CoreSimulator/Devices. List them with:

xcrun simctl list devices

Anything marked unavailable belongs to a runtime you no longer have. Remove those:

xcrun simctl delete unavailable

To start over completely, xcrun simctl delete all removes every simulator device. Xcode recreates the standard set on next launch. Screenshots, databases and anything else you left inside a simulator go with it.

Simulator runtimes are the operating system images themselves, and they are the bigger number. Current Xcode downloads them separately from the app: look in Xcode’s settings under the Platforms tab, which is called Components in older versions. Each runtime you have ever installed stays until you remove it there. Keep the versions you actually test against and the oldest one you support. Deleting one you still need means a large download to get it back.

Device support and archives

~/Library/Developer/Xcode/iOS DeviceSupport (and the watchOS and tvOS equivalents) holds one folder of debugging symbols per OS version of every physical device you have ever plugged in. Delete freely. The next time you connect a device running that version, Xcode copies the symbols again, which takes a few minutes and a plugged-in phone.

~/Library/Developer/Xcode/Archives is the one to be careful with. Every time you archive a build, the result is stored here with its debug symbols. Those symbols are how you turn a crash report from a user into a line number, so the archive for a version that is out in the world is worth keeping. Everything else, the eleven archives you made while fighting a signing problem last March, is not. The folder is organized by date, which makes it easy to keep the handful you shipped and remove the rest.

The caches nobody mentions

A few more that add up:

~/Library/Caches/com.apple.dt.Xcode, Xcode’s own cache, safe to remove with Xcode quit.
~/Library/Caches/org.swift.swiftpm, the shared Swift package cache, rebuilt on demand from the network.
Downloaded documentation, if you have pulled offline docsets.
Old copies of Xcode itself. If /Applications contains more than one version, decide whether you genuinely need the older one for a build you still ship.

Leave ~/Library/Developer/Xcode/UserData alone. Code snippets, key bindings, themes and breakpoints live there, and none of it regenerates. Provisioning profiles are also not disposable in the way the rest of this is, so leave those where they are unless you are certain you can re-download them.

If you would rather see the whole picture before deciding, a menu bar auditor like Crumb groups Xcode data and build artifacts as their own categories alongside the rest of the Mac’s System Data, and shows the total before anything is removed. The commands above do the same job for free if you are comfortable in Terminal, and they are worth knowing either way.

A routine that keeps it flat

Monthly, and it takes five minutes:

Delete DerivedData folders for projects that no longer exist on the machine.
Run xcrun simctl delete unavailable.
Open the Platforms tab and remove runtimes you have stopped targeting.
Delete archives that were never shipped.
Clear device support folders for OS versions you no longer test.

Doing this occasionally is far less disruptive than doing it in a panic the evening a release build fails on a full disk. If the disk is already at that point, which caches are safe to delete on a Mac covers the non-developer half of the same problem.

Questions

Will deleting DerivedData break my project? No. Nothing in there is source or configuration, and Xcode recreates the folder on the next build. The only real cost is time: a full rebuild and a reindex. If a project is behaving strangely, deleting its DerivedData folder is often the fix rather than the risk.

Why did the free space not change after I deleted all that? Check the Trash first if you dragged rather than used rm. If the space still has not appeared, macOS may be holding it in local Time Machine snapshots or reporting it as purgeable, both of which release on their own schedule rather than immediately.

Do I need to keep old simulator runtimes? Only for versions you actually test against. If your app’s deployment target is two versions back, keep that one and the current one; the four in between are download-on-demand. Removing one you later need is an inconvenience, not a loss.

Is Docker taking space too? Very likely, and it hides differently: the file looks enormous in Finder while using much less on disk. Docker.raw is huge on a Mac explains how to tell the reserved size from the real one.