GuidesXcode Storage Guide

What's eating space in Xcode DerivedData (and what's safe to delete)

Yes, you can delete Xcode DerivedData. Quit Xcode, empty ~/Library/Developer/Xcode/DerivedData, and the next build recreates everything. Your source code, Git history, project files, and signing setup do not live there. The cost is time: one slow full build and a re-index before autocomplete and jump-to-definition feel normal again. Apple's own Xcode 26 release notes tell developers to "clean out the DerivedData for the project" as a workaround for build problems.

The harder question is everything next to it. Xcode's real footprint is mostly in ~/Library/Developer, not in Xcode.app. Device support files, simulators, runtimes, and Archives pile up there too, and they do not all carry the same risk. One of them (Archives) cannot be rebuilt at all.

This guide covers what each folder is, how to measure it, and the order to clear it by hand. You can follow every step without installing anything. If the space you are chasing is not from Xcode, start with what system data is on a Mac instead.

What DerivedData actually holds

Open Xcode → Settings → Locations. The Derived Data row shows the current path, with a small arrow that opens it in Finder. The default is ~/Library/Developer/Xcode/DerivedData, but a custom location set here (or a build script using xcodebuild -derivedDataPath) puts it somewhere else. Trust the arrow over the default path.

Inside, you will see one folder per project, named like MyApp-abcdefghijklmnop. Each holds build products, intermediates, the index that powers code completion, and build logs. Swift Package dependencies usually land in a SourcePackages folder inside the project's entry.

There are also shared caches beside the project folders:

That second one has become a common surprise. A thread on r/iOSProgramming titled "Xcode 26: CompilationCache.noindex using 26 GBs of storage" describes it filling back up to the same size after being cleared. Treat it like the rest of DerivedData: safe to delete, and likely to grow back if you keep building the same projects.

Reports of total size vary a lot. The original Stack Overflow question on this topic started with a 22 GB DerivedData folder. An Ask Different answer on "Project Build Data and Indexes" puts it bluntly: some projects take 50 kB, some take 50 GB. No average will tell you what yours holds, so measure it (below).

Clean Build Folder is not a disk cleanup

Product → Clean Build Folder (Shift-Command-K) removes build products for the project you have open. It is a troubleshooting tool. It leaves the index, the shared module and compilation caches, every other project's folder, device support files, simulators, and Archives in place.

So if you ran Clean Build Folder and free space barely moved, nothing went wrong. You need to delete the folders themselves.

Why Storage shows it as Developer or System Data

In System Settings → General → Storage, macOS sometimes groups Xcode's build data under a Developer category, listed as "Project Build Data and Indexes", with a Delete option. That entry is DerivedData across all your projects.

The rest of ~/Library/Developeroften ends up in System Data, because Storage categories are groupings, not folders. If System Data is still huge after you clear Xcode's leftovers, local Time Machine snapshots and VM disks are the next suspects. The Mac system data guide covers those.

Measure before you delete

Quit Xcode and Simulator, then paste this into Terminal. It only reads sizes:

du -sh ~/Library/Developer/Xcode/DerivedData \ ~/Library/Developer/Xcode/*DeviceSupport \ ~/Library/Developer/Xcode/Archives \ ~/Library/Developer/Xcode/DocumentationCache \ ~/Library/Developer/CoreSimulator/Devices \ ~/Library/Developer/CoreSimulator/Caches \ ~/Library/Developer/XCTestDevices \ ~/Library/Caches/com.apple.dt.Xcode 2>/dev/null

To see which projects inside DerivedData are the heavy ones:

du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -h

In Finder, use Go → Go to Folder (Shift-Command-G) and paste any of those paths. Deleting from Finder sends things to Trash, which gives you an undo. Storage will not change until you empty it.

A cleanup order, safest first

Work top to bottom and stop once you have enough room. The early steps cost you rebuild time. The later ones cost downloads, simulator state, or data you cannot get back.

1. Quit Xcode and Simulator

Deleting DerivedData while Xcode is indexing or building tends to produce strange errors until you restart anyway. Quit both first.

2. Delete DerivedData

Pick one:

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

The Terminal version skips Trash, so double-check the path. It does not need sudo. If you see forum advice that adds sudo here, ignore it. The folder belongs to your user, and running rm -rf as root only raises the stakes of a typo.

If one project is misbehaving, you can delete only its Name-hash folder and leave the rest warm.

3. Clear simulator caches and dead simulators

~/Library/Developer/CoreSimulator/Caches is safe to empty. The first simulator boot afterwards is slower.

For simulator devices, let the tools do it. This removes devices whose runtime your current Xcode no longer supports:

xcrun simctl delete unavailable

Devices you still use but no longer need can go from Window → Devices and Simulators. Deleting a simulator wipes the apps and data installed on it, so keep any that hold test accounts or a state you set up by hand.

4. Remove old DeviceSupport versions

Each time you connect a physical device running a new OS version, Xcode copies support files into folders such as:

Old versions pile up across phone upgrades. The accepted Ask Different answer is that it is safe to delete old ones, and suggests sorting by Date Modified to see which are still in use. Keep the versions that match devices you still debug on. If you delete one you needed, Xcode copies it again the next time that device connects. You wait a few minutes, nothing breaks.

5. Remove simulator runtimes you no longer test against

Runtimes are full OS images, and they are often the biggest single items after an Xcode upgrade or two. Do not hunt for them in Finder. Use Xcode → Settings → Components. Apple's documentation says that screen shows how much storage you can recover. Click the information button next to a runtime and choose Delete.

From Terminal, the same job is:

xcrun simctl runtime list xcrun simctl runtime delete <identifier>

Getting a runtime back means downloading it again. Run xcrun simctl delete unavailable afterwards to clear devices that pointed at it.

6. Documentation and Xcode app caches

~/Library/Developer/Xcode/DocumentationCache re-downloads when you browse docs. ~/Library/Caches/com.apple.dt.Xcode is an ordinary app cache that Xcode rebuilds on launch. Both are safe with Xcode closed, though they are rarely where the big numbers are.

7. Archives, last and by hand

~/Library/Developer/Xcode/Archives is not a cache. Every Product → Archive creates an .xcarchive holding the built app and its dSYM files. Xcode will not regenerate those. Delete the archive for a build that is live on the App Store and you lose the easy path to symbolicated crash logs for that version.

Open Window → Organizer, look at the dates, and remove archives for builds nobody runs anymore. Keep the archives (or at least the dSYMs) for every version still installed on users' devices. This is the one folder on the page where a mistake is permanent.

What usually works

SituationLikely causeFirst move
Clean Build Folder freed almost nothingIndex and caches untouchedQuit Xcode, delete DerivedData contents
DerivedData is big even after clearingCompilationCache.noindex refillingMeasure it separately; expect it to return as you build
Free space dropped after an Xcode upgradeOld and new simulator runtimes side by sideSettings → Components, delete runtimes you do not test against
iOS DeviceSupport is largeOne copy per device OS version you ever connectedDelete versions older than your current devices
Hundreds of simulators in the run menuLeftover devices from old runtimesxcrun simctl delete unavailable
Archives holds years of buildsEvery release you ever shippedReview in Organizer; keep dSYMs for live versions
System Data still huge after all thisNot XcodeRead the system data guide

What not to do

Prevention that is not a cleaner upsell

DerivedData will grow back. That is how it is supposed to work, so plan on clearing it every few months rather than once.

Where a careful cleaner fits

Once you know which buckets are regenerable, the remaining chore is visiting the same paths every few months. Purge is an open-source Mac cleaner that can list those Xcode items for you and move them to Trash.

It only offers allowlisted paths. DerivedData, CoreSimulator caches, the Documentation cache, and Xcode's app cache are marked Safe. DeviceSupport, Archives, and shut-down simulator devices are marked Check First, because each one costs you something. Purge does not remove simulator runtimes. That stays with Settings → Components or simctl. There is no telemetry, and you can read the code on GitHub.

Use Organizer and Components for the decisions that are hard to undo. Use Purge for the named junk you already understand.

Download PurgeView on GitHub

Sources