# DerivedData: what Xcode keeps there and when to delete it

> DerivedData is usually the largest folder in a developer's home directory. What Xcode stores in it, why it never shrinks, when deleting it fixes a build, and the one part of it worth keeping.

Canonical: https://bytesweep.app/blog/deriveddata-explained.html
Last updated: 2026-10-16

## DerivedData, and when deleting it is the right answer

`~/Library/Developer/Xcode/DerivedData` is often 20 to 60 GB on a Mac that builds iOS apps, and everything in it can be rebuilt from your source. So whether it’s safe to delete is already settled. What you’re deciding is whether the space is worth a rebuild, and for a good part of the folder the answer costs nothing at all.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 25 September 2026
- Last updated 16 October 2026
- 4 min read
- Part of [Xcode storage cleanup](https://bytesweep.app/xcode-storage-cleanup.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

Start by seeing where the size actually sits:

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

The distribution is usually lopsided. A project you abandoned in 2024 is often bigger than the three you open every day.

### One directory per project path

Xcode creates a directory for each project the first time it builds it, named after the project plus a hash of the project’s path. Inside it:

- `Build` holds object files, built products and the intermediates that make incremental builds fast. This is nearly all of the size.
- `Index.noindex` is the code index behind autocomplete, jump-to-definition and the issue navigator. It’s large and slow to rebuild: on a big project the machine stays busy for several minutes after you delete it.
- `Logs` holds build and test logs, which the report navigator reads. Small.
- `SourcePackages` holds the project’s Swift package checkouts, covered in Swift Package Manager’s caches.

Next to the project directories sits `ModuleCache.noindex`, precompiled module data shared by all of them. Medium-sized, and quick to rebuild.

Xcode never garbage-collects any of this. A project’s directory survives when you delete the project, rename it or move it. Moving is the worst case, because the hash comes from the path: the same project in a new folder gets a brand-new directory, and the old one stays behind for good.

*Moving a project gives it a new hash and a new directory. Nothing ever reads the old one again.*

That’s why the folder on an older machine is mostly archaeology. Sort by modification time and look at the bottom of the list:

```
ls -lt ~/Library/Developer/Xcode/DerivedData | tail -20
```

Anything down there hasn’t been touched in months. Deleting it doesn’t even cost a rebuild, because nothing will build into it again.

### What deleting it fixes, and what it doesn’t

“Delete DerivedData” is the folk remedy of iOS development, and it gets prescribed far more often than it helps. It does fix a real, narrow set of problems:

- stale module or header state after switching branches, where the compiler insists on a symbol that no longer exists
- a build that passes on a colleague’s machine and fails on yours with no relevant difference
- autocomplete that has stopped seeing new symbols (that’s the index, not the build)
- odd linker errors straight after an Xcode upgrade

It won’t fix a genuine compile error, a signing failure, a missing dependency or a simulator that won’t boot. If the error names a file and a line, go and look at the file and the line.

Delete the one project’s directory, not the whole folder. The fix is the same, and every other project on the machine keeps its incremental build.

### Deleting it

In Xcode, open Settings, then Locations, and click the small arrow next to the Derived Data path. That opens the folder in the Finder.

From the terminal, the whole thing:

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

The version worth keeping as a shell function removes only the directories nobody has touched for sixty days:

```
find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mindepth 1 -type d \
  -mtime +60 -print -exec rm -rf {} +
```

Quit Xcode first. Pulling the folder out from under a running Xcode leaves it holding references to files that are gone, and the build failure you get looks far worse than the cause.

### The folder next door is the one to leave alone

Nothing in DerivedData needs keeping. One level up is a different story. `~/Library/Developer/Xcode/Archives` holds your shipped builds and their dSYM files, which are what turn an App Store crash report into a line number. They can’t be regenerated from a later build, so deleting them means you can never symbolicate crashes from versions already on people’s phones. [Archives and dSYMs](https://bytesweep.app/blog/xcode-archives-dsym.html) makes the case in full.

The other big neighbours are fair game while you’re there. `iOS DeviceSupport` keeps a folder for every iPhone build you’ve ever connected ([iOS DeviceSupport is thirty gigabytes of old iPhones](https://bytesweep.app/blog/ios-device-support-cleanup.html)), and simulator runtimes and devices are covered in [deleting unavailable simulators safely](https://bytesweep.app/blog/xcode-simulators-cleanup.html).

### Questions

#### How long does the first build take afterwards?

A full clean build plus a full reindex, so about as long as the very first build of that project on the Mac. On a large project with many Swift packages that can be a long wait.

#### Should I delete it on a schedule?

Deleting stale project directories on a schedule is sensible and free. Deleting the active ones on a schedule means paying for a full rebuild every time, for space you’ll fill again by Friday.

#### Does moving Derived Data to another disk help?

It moves the problem rather than solving it, though pointing it at an external SSD is a fair answer on a 256 GB MacBook. Paths inside the build are handled correctly, so nothing breaks.

### Let Bytesweep clear this for you

Skip the commands. Bytesweep finds this for you, rates every item safe, review first or keep, and clears what you choose. Most of what it removes can be put back for seven days. See what it finds on your own disk, free for 3 days, then pay once with no subscription.

[Try it free for 3 days](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

Related in Bytesweep: [Developer tools](https://bytesweep.app/dev-servers.html)

### Keep reading

- [**iOS DeviceSupport is 30 GB of iPhones you no longer own** Xcode keeps a full symbol cache for every iOS version of every device ever plugged in, and never removes any of them. What the folder is for, when you need it, and how to clear it without breaking debugging.](https://bytesweep.app/blog/ios-device-support-cleanup.html)
- [**Deleting iOS simulators safely, and what simctl really removes** CoreSimulator keeps a runtime per iOS version and a device per configuration, and both accumulate. The commands that remove what is genuinely unused, and the caches simctl does not touch.](https://bytesweep.app/blog/xcode-simulators-cleanup.html)
- [**Xcode Archives and dSYMs: the one folder not to delete** Archives hold the exact binary you shipped and the symbol files that turn a user's crash report into a line number. They cannot be regenerated, and every cleanup guide tells you to delete them.](https://bytesweep.app/blog/xcode-archives-dsym.html)