Xcode DerivedData: what it is, where it lives, how to delete it

DerivedData is the folder where Xcode keeps everything it makes from your projects: build products, intermediate files, the code index, build and test logs, and copies of your Swift packages.

To delete derived data in Xcode 27, open the project and choose Product › Delete Derived Data…. In Xcode 26, or to clear every project at once, open the folder from Xcode › Settings › Locations, quit Xcode, and move what you don't need to the Trash.

It's safe. Xcode makes all of it again the next time you build or open the project, so nothing you wrote is lost. What it costs is time: a full build, a fresh index, and a new download of each project's packages.

It lives at ~/Library/Developer/Xcode/DerivedData, with one folder per project and a few shared folders next to them. On a Mac that has built many projects, or the same project from many places, it often reaches tens of gigabytes.

This post goes deep on DerivedData alone: what each part does, how deleting it differs from Clean Build Folder, and how custom locations, git worktrees and build servers change the picture. For everything else Xcode stores, see why Xcode takes up so much space.

What is DerivedData in Xcode?

When you build, Xcode doesn't write its output next to your source files. It keeps it in a separate place it manages, so your project folder holds only what you made. That place is DerivedData: data derived from your project, which can always be derived again.

Despite the name, Unreal Engine's Derived Data Cache is unrelated: it belongs to the game engine, not to Xcode.

Where is the DerivedData folder?

By default it's ~/Library/Developer/Xcode/DerivedData, inside the Library folder in your home folder. Finder hides that Library folder, so the easiest way in is through Xcode itself.

1. In Xcode, choose Xcode › Settings.
2. Click Locations.
3. Next to Derived Data, click the small arrow at the end of the path. Finder opens the folder.

If the path there isn't the default one, you or a teammate's setup changed it; the section on custom locations below covers the options.

Why can't you see DerivedData in Finder?

Because the Library folder in your home folder is hidden by default. Two other ways in work without Xcode: in Finder, choose Go › Go to Folder… and enter the path, or hold the Option key while you open the Go menu, choose Library, then open Developer, Xcode and DerivedData.

While you're there, leave the rest of the Library folder alone. It holds every app's settings and data, and DerivedData is one of the few parts of it that's entirely rebuildable.

Does Storage settings show DerivedData?

Not by name. On a Mac with Xcode, System Settings › General › Storage often lists a Developer category, and developers report entries there for Xcode's caches and project build data. Apple doesn't document what each entry covers.

The routes in this post are more predictable: they show exactly which project's folder you're removing, and the Finder route keeps it in the Trash until you're sure.

Why is there a folder for every project?

Xcode gives each workspace or project its own folder, named after it with a string of letters added, such as App-abcdefghijk. The letters come from where the project lives on your disk, so the same project opened from two places gets two folders.

That's why DerivedData often holds two or more folders with the same name. One usually belongs to a copy you moved, renamed, cloned again or built from a git worktree, and it stays behind after you stop using that copy.

How big does DerivedData get?

The research behind the app's rules catalog puts DerivedData at about 5 to 100 GB on a developer's Mac. Where a Mac lands depends on how many projects it has built, for how many platforms, and how many copies of each it has built from.

Each project folder is usually hundreds of megabytes to a few gigabytes. Projects with large binary packages, many targets, or builds for several platforms sit at the top of that range.

• Package downloads (one copy of a project)3,886 MB · Safe
• Shared module cache662 MB · Safe
• Prebuilt SDK modules417 MB · Safe
• Swift packages (another copy)411 MB · Safe
• Build products and intermediates396 MB · Safe
• Code index55 MB · Safe
• Build and test logs3 MB · Safe

Measured with Xcode 27 on the Mac this post was researched on: two copies of one native Mac app with five Swift packages, and the shared folders every project uses. The first copy's packages were mostly downloaded binary frameworks. Your projects will differ.

The chart shows a pattern worth knowing. Build output isn't always the largest part: package downloads, and the module caches every project shares, can outweigh it.

What's inside each project's folder

Open one project's folder and you'll see a handful of subfolders. Each one has its own job, and losing each one costs something different.

Folder	What it holds	What losing it costs
Build/Products	The apps, frameworks and test bundles you built	A full build
Build/Intermediates.noindex	Object files and other in-between files	A full build
Index.noindex	The index behind code navigation, search and completion	Indexing time
Logs	Build, test, launch and package logs	The history in the Report navigator
SourcePackages	Checkouts, clones and binaries of your Swift packages	A new download of every package
info.plist	The project's path and when Xcode last opened it	Nothing; Xcode writes it again

Newer versions of Xcode may add more, such as a folder for test results. None of it is source code, and none of it is the only copy of anything you made.

Build: products and intermediate files

Build/Products holds what a build produces, in one folder per configuration and platform, such as Debug or Debug-iphonesimulator. Build/Intermediates.noindex holds the compiled pieces Xcode assembles them from.

Together they're what makes the next build incremental: Xcode compiles only what changed since the last build. Remove them and the next build compiles everything.

Index.noindex: the code index

Xcode indexes your project so it can jump to definitions, find callers, rename symbols and complete code. The index lives in Index.noindex, and Xcode rebuilds it in the background when it's missing.

While it rebuilds, navigation and completion can be slow or incomplete. On a large project that can take a while, so deleting DerivedData right before you need to find your way around the code is poor timing.

Logs and test results

Logs holds the build, test, launch and package logs that the Report navigator shows. Test runs also keep their result bundles here, with screenshots and attachments when your tests make them.

Deleting them empties that history. That matters only if you were still looking at an old build log or test result; Xcode starts a new history with the next build.

SourcePackages: your Swift packages

When a project uses Swift packages, Xcode keeps them in the project's own SourcePackages folder: a clone of each package's repository, a checkout of the version you use, and any binary frameworks a package downloads. Each project folder has its own set.

That's why package-heavy projects grow so large, and why deleting DerivedData means downloading every package again, which needs a network connection. Swift Package Manager also keeps a shared cache, the Swift Package Manager cache, which can make that download quicker.

Do Swift packages built outside Xcode use DerivedData?

No. When you build a package with Swift's own command-line tool, its output goes into Swift package .build folders, next to the package's Package.swift file. Those folders are just as rebuildable, but they live with your code, so clearing DerivedData doesn't touch them.

info.plist: which project a folder belongs to

Most project folders contain a small file named info.plist. Select it in Finder and press the Space bar: Quick Look shows WorkspacePath, the project the folder belongs to, and LastAccessedDate, when Xcode last opened it.

It's the most reliable way to match a folder to a project. Folders made by command-line builds may not have one; for those, the folder's name and Finder's Date Modified column are the clues.

The shared folders: module caches and the compilation cache

Next to the project folders sit a few that every project uses. Their names vary between Xcode versions; on a Mac with Xcode 27 they include ModuleCache.noindex, SDKExplicitPrecompiledModules, SDKStatCaches.noindex and CompilationCache.noindex.

What are the module caches?

Swift and Objective-C code imports modules: Apple's frameworks, your packages, your own targets. Compiling a module takes time, so Xcode keeps compiled modules and reuses them across builds and across projects.

Apple's documentation explains that since Xcode 16, the build system schedules module builds as explicit tasks and reuses them when the options match. The shared folders are where that reusable work is kept, which is why they can reach hundreds of megabytes.

Is it safe to delete the module cache?

Yes. Like everything in DerivedData, it's rebuilt as needed. The first build of every project afterwards takes longer, because modules every project shares have to be compiled again.

Stale modules can also cause odd build errors, and clearing the module caches is a common fix for them. Deleting the whole DerivedData folder includes them.

What is the compilation cache?

Xcode 26 introduced compilation caching as an opt-in feature. Apple's release notes say it keeps the results of compiling a given set of source files and reuses them when the same files are compiled again, which helps most when you switch branches or make a clean build.

You turn it on with the Enable Compilation Caching build setting. By default its folder, CompilationCache.noindex, sits inside DerivedData, and Xcode › Settings › Locations has its own entry for it, so it can live somewhere else.

Does deleting DerivedData clear the compilation cache?

If the cache is in its default place inside DerivedData, yes. That's worth knowing if your team turned caching on precisely to make clean builds fast: deleting the whole folder throws that saved work away.

To clear build output and keep the cache, delete the project folders and leave CompilationCache.noindex where it is, or give the cache its own location in Locations settings.

How to delete derived data in Xcode

There are three ways, and they differ in how much they remove and whether you can undo them.

Delete Derived Data in Xcode 27

Xcode 27 added a menu command for it. At WWDC26, the Xcode team was thanked for adding it, after years of developers deleting folders by hand or with scripts.

1. Open the project or workspace.
2. Choose Product › Delete Derived Data….
3. Read the confirmation and click Delete Derived Data.

The confirmation says the project's derived data, such as build output, logs, index and snapshots, will be deleted immediately and that you can't undo it. It doesn't go to the Trash. That's fine for build output, but it's the reason to be sure you don't need an old log or test result first.

Delete it in Finder

In Xcode 26 and earlier, and whenever you want to clear projects you no longer open, use Finder. This route also keeps a way back, because items go to the Trash first.

1. In Xcode, choose Xcode › Settings, click Locations, and click the arrow next to the Derived Data path.
2. Quit Xcode, so it isn't writing to the folder while you remove it.
3. Select the project folders you don't need, or all of them, and choose File › Move to Trash.
4. Open a project and build it to check everything comes back as expected.
5. Empty the Trash when you're sure. Until then, the space isn't freed.

Moving the DerivedData folder itself to the Trash also works; Xcode creates it again. Selecting the folders inside is tidier, because it leaves any custom setup alone.

Which project folders should you delete?

Start with the ones that cost nothing to lose. In order:

• Folders for projects that no longer exist, such as deleted clones and removed worktrees. Their info.plist points to a path that's gone.
• Duplicates: two or more folders with the same project name, where only one matches the copy you use now.
• Projects you've finished or put away for months. Sort by Date Modified in Finder's list view to find them.
• Your current projects, last, and only if you need the space or a build is misbehaving.

Leaving active projects alone keeps their incremental builds fast. Clearing everything works too, but then every project you open pays for a full build.

Is it safe to delete DerivedData?

Yes. The catalog rates Xcode DerivedData as Safe: Xcode rebuilds it the next time you build or open the project, and nothing you made is lost.

Your source code, project file, schemes and breakpoints are stored with the project, not in DerivedData. Your Xcode archives are in a separate folder too, so deleting DerivedData never touches a build you shipped.

What happens after you delete it?

Nothing at first. The cost arrives the next time you work on each project.

What you'll notice	Why	How long it lasts
The first build is slow	Every file and module is compiled again	One build per project
Navigation and completion lag	The index is being rebuilt	Until indexing finishes
Packages download again	Each project's package folder was removed	One download per project
SwiftUI previews take longer	They share the build's products	The first preview
The Report navigator is empty	Old build and test logs were removed	Until the next build

The disk space comes back as you delete, and part of it fills again as you build. Only folders for projects you no longer open stay gone.

Clean Build Folder versus deleting DerivedData

Xcode has several commands that sound alike. They remove different things, for different reasons.

Command	What it removes	Use it when
Product › Clean Build Folder…	This project's build products and intermediate files	You want a full build of this project
Product › Delete Derived Data… (Xcode 27)	This project's whole folder: build output, logs, index and more	A clean build didn't fix it, or you need the space
File › Packages › Reset Package Caches	Xcode's cached package state, so packages resolve again	Packages won't resolve or seem stuck
Product › Clear Test Results (Xcode 27)	Old test results	You want a clean test history
Finder, as above	Any folders you choose, to the Trash	Clearing many or old projects

What does Clean Build Folder remove?

It removes the build products and intermediate files of the project you have open. Xcode 27's confirmation says exactly that, and an Apple engineer on the developer forums describes it the same way.

Its shortcut is Shift-Command-K. Hold Option while the Product menu is open and the command becomes Clean Build Folder Immediately, which skips the confirmation.

It leaves other projects' folders alone, and it isn't aimed at the index, the logs or the downloaded packages. So it frees only part of one project's space, and the next build doesn't download packages again.

When should you delete DerivedData instead?

When a clean build doesn't fix a problem, or when you need the disk space. Stale module caches, a confused index or a broken package checkout survive a clean build, and deleting the folder clears them.

At WWDC26, Xcode engineers were frank that deleting DerivedData is often a workaround, for a bug in Xcode or a hidden problem in the project, such as a missing dependency between two targets. If you need it again and again for the same failure, they suggested looking for that cause and reporting it.

What does Reset Package Caches do?

It's in File › Packages, with Resolve Package Versions and Update to Latest Package Versions. It makes Xcode drop its cached package data and resolve the project's packages again.

Apple doesn't document exactly which folders it clears. It's the right first step when packages fail to resolve; deleting the project's DerivedData folder goes further, because it removes the project's package checkouts too.

Custom DerivedData locations

You don't have to keep DerivedData in your Library folder. Xcode lets you move it for every project, or for one.

What do Default, Relative and Custom mean?

In Xcode › Settings › Locations, the Derived Data menu has three choices:

• Default keeps it in ~/Library/Developer/Xcode/DerivedData.
• Relative puts a DerivedData folder inside each project's or workspace's own folder.
• Custom lets you choose any folder, such as one on another drive.

The choice applies to every project. Relative suits people who like each project's build data to travel with it; Custom suits a small internal disk.

Can one project use a different location?

Yes. With the project open, choose File › Workspace Settings…, or File › Project Settings… when you opened a project rather than a workspace. These per-user settings have their own Derived Data choice, which overrides the one in Xcode's settings for that project only.

Per-user means they're yours alone: they're saved in your user data inside the project, not shared with your team unless you commit that folder.

What does the Advanced button change?

The Advanced… button next to Derived Data controls the build location: where products and intermediates go inside it. Xcode 27 offers Unique, a unique subfolder per project, which is the usual setting; Shared Folder, one shared subfolder; Legacy; and Custom, relative to DerivedData, to the workspace or as absolute paths.

Most people never need to change it. Leave it at Unique unless a build setup you rely on asks for something else.

Can DerivedData live on an external drive?

Yes. An Apple engineer in Developer Technical Support has said that Xcode itself and the three items in Locations settings, Derived Data, Archives and Compilation Cache, can all move to an external drive. Format the drive as APFS: the same answer warns that Mac work on a FAT32 drive eventually runs into odd problems.

Use a fast drive, because Xcode reads and writes DerivedData constantly. And test before you rely on it: one developer reported on Apple's forums that framework tests run on My Mac failed with DerivedData on an external drive, while other tests worked.

Is DerivedData in your Time Machine backups?

Apple doesn't document how Xcode handles this. On the Mac this post was researched on, Xcode 27 had marked each project folder it created as excluded from Time Machine, but not the shared module folders or a folder made by a command-line build.

To keep all of it out of your backups, choose Apple menu › System Settings, click General, then Time Machine, and click Options. Click the Add button, select the DerivedData folder, and click Done. Backing it up gains you nothing, since Xcode can make it again.

Worktrees and several checkouts

Git worktrees let you check out several branches of one repository side by side, each in its own folder. They've become common, partly because AI coding agents often work in a worktree of their own.

Why does each worktree get its own DerivedData folder?

Because each worktree is a different path on disk, and Xcode names project folders by path. Opening the project from a new worktree starts a new folder, with its own full build, its own index and its own copy of every package.

The Xcode team said as much at WWDC26: worktrees create a new build folder for the project, and after too many of them you may want to clean up.

On the Mac this post was researched on, one project had seven folders in DerivedData, from about 200 MB to 3.6 GB each, one for each copy it had been built from.

How do you clean up after removing a worktree?

Removing a worktree with git deletes its folder but not its DerivedData folder, which lives in your Library folder. Xcode doesn't know the worktree is gone, so the folder stays until you remove it.

Look for folders whose info.plist points to a path that no longer exists, or folders named after the project that haven't been modified since you removed the worktree. Those are Safe to move to the Trash.

Should worktrees use the Relative location?

It's worth considering. With Relative, each worktree's DerivedData lives inside the worktree's own folder, so removing the worktree removes its build data too. Nothing is left behind in your Library folder.

Two things to check first. Add the DerivedData folder to your repository's ignore list, so it never gets committed. And remember the setting applies to all your projects, unless you set it per project in File › Workspace Settings….

Setup	Where each copy's build data goes	What happens when the copy is removed
Default location	A new folder in your Library's DerivedData	It stays until you remove it
Relative location	A DerivedData folder inside the worktree	It goes with the worktree
Custom location	A new folder in the folder you chose	It stays until you remove it
Per-project setting	Wherever that project's setting says	Depends on the location chosen

DerivedData on CI and build servers

A build server builds the same projects over and over, often from fresh checkouts. That makes DerivedData both more useful, as a cache, and more likely to pile up.

How does Xcode Cloud handle derived data?

Xcode Cloud manages it for you. Apple's documentation says it stores each build's derived data and other cached information, privately, to make later builds faster.

When you need a build without cached data, open the workflow in Xcode or App Store Connect, go to its Environment section and select Clean. Apple notes that clean builds take much longer, and that a workflow that distributes a new version to external testers with TestFlight needs one.

What happens on a Mac you run builds on yourself?

On a self-hosted Mac, such as a CI runner or a shared build machine, Xcode's command-line build tool uses the same default DerivedData folder as the app. Every fresh checkout path adds a project folder, so the disk fills over weeks unless something clears it.

Two setups keep it in check. Many teams point each job's derived data at a folder inside the job's own working folder, using an option of Xcode's build tool, so it's removed with the job. Others keep a shared folder on purpose, as a cache, and clear stale project folders on a schedule.

Should CI keep or clear DerivedData?

It's a trade-off between speed and certainty. Keeping it makes builds incremental and fast. Clearing it makes each build start from the same state, which is what you want for release builds.

Approach	Speed	Disk use	Best for
Fresh DerivedData every job	Slowest	None left behind	Release builds
A folder kept per branch or job type	Fast	Grows with branches	Pull request checks
Compilation caching on	Faster clean builds	A cache to manage	Teams that clean often
Shared, cleared on a schedule	Fast	Grows between clean-ups	One machine, many projects

Some teams also turn off the Enable Index-While-Building Functionality build setting for CI builds. Apple describes it as controlling whether the compiler writes index data while building; a CI machine never browses the code, so it doesn't need that data.

Habits that keep DerivedData small

DerivedData can't stay empty while you work, and it shouldn't: it's what makes builds fast. The aim is to keep only the folders you use.

What should you do regularly?

• After removing a worktree or a clone, move its DerivedData folder to the Trash.
• When you finish or shelve a project, delete its folder, with Product › Delete Derived Data… in Xcode 27 or in Finder.
• After a major Xcode update, consider clearing the shared module folders, which hold modules built by the previous version.
• Every few months, sort the folder by Date Modified and clear anything you haven't built in that time.

A worked example

Say DerivedData holds 40 GB, and you work on two apps. One of them you've built from four git worktrees over the past month, three of which you've since removed.

1. Open the folder from Xcode › Settings › Locations, then quit Xcode.
2. Switch Finder to list view and sort by Date Modified.
3. For each folder named after your apps, Quick Look its info.plist. Three point to worktrees that no longer exist: move them to the Trash.
4. Move folders for projects you haven't opened this year to the Trash too.
5. Leave the two current projects' folders and the shared module folders alone.
6. Build both apps, check they run, then empty the Trash.

Your current projects keep their fast incremental builds, and only folders nothing uses are gone.

What should you avoid?

• Deleting DerivedData while Xcode is building. Quit Xcode first when you use Finder.
• Deleting it before a demo, a release or a flight. The next build needs time, and the packages need a network.
• Clearing everything as a reflex after every build error. If a clean build fixes it, use that, and look for the cause when the same error keeps coming back.
• Pasting commands from a web page to delete it. Commands skip the Trash, so a mistyped path can't be put back.

Will deleting DerivedData make Xcode faster?

Not on its own. It frees disk space, and it can fix builds that went wrong because of stale data. But the first build, index and preview afterwards are slower, not faster, until Xcode has made everything again.

Space is the real benefit, and on a nearly full disk it's a real one: room for an Xcode update, a simulator runtime or a macOS update.

How the app does it

Wombit explains DerivedData like everything else on the disk. Select the folder in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

DerivedData is Safe, so it counts toward the safe total and starts checked in Cleanup. Folders go to the Trash, where you can put them back, and every removal is logged.

• ~/Library/Developer/Xcode/DerivedData

  Xcode DerivedData

  Build products, indexes and logs Xcode keeps for every project you've built.

  Safe · Moves it to the Trash

• ~/Library/Caches/com.apple.dt.Xcode

  Xcode caches

  Cached network data and other temporary files that Xcode and its command-line build tool keep so they don't have to fetch them again.

  Safe · Moves it to the Trash

• ~/Library/Caches/org.swift.swiftpm

  Swift Package Manager cache

  Package repositories, manifests and binaries that Swift Package Manager keeps so packages aren't downloaded again for every project.

  Safe · Moves it to the Trash

For the rest of Xcode's data, from simulator runtimes to archives, see the Xcode cleanup guide.

Seeing all of this is free. Removing it is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.