How to delete Xcode DerivedData safely

What DerivedData is

Every time Xcode builds, indexes or previews a project, it writes the results to a folder called DerivedData. By default that's here:

~/Library/Developer/Xcode/DerivedData

Inside are folders named after your projects, each with a random-looking suffix, such as MyApp-abcdefghijklmnop. Each one holds that project's build products, intermediate files, the index that powers search and code completion, and build logs. For projects that use Swift packages it also holds checked-out copies of those packages. Xcode keeps a few shared caches there too, with names ending in .noindex.

None of it is source. It's all output Xcode can make again, which is why it's the first place developers look when the disk fills up. It grows with every project you build, and folders for projects you stopped opening stay until you remove them.

~/Library/Developer/Xcode/DerivedData

Xcode build data

Made by

Xcode

What it is

Build products, indexes and logs Xcode makes for each project.

Does it come back?

Comes back when it's needed

Without it

Xcode rebuilds it the next time you build or open each project, which can take a while.

If you changed where Xcode keeps it, Xcode, then Settings, then Locations shows the current path. The options there are Default, Relative and Custom, and the setting applies to all projects. Command-line builds that pass xcodebuild -derivedDataPath write wherever that option points, such as a build folder inside the repository.

Is it safe to delete Xcode DerivedData?

Yes. Deleting DerivedData doesn't touch your code, your project file, your schemes or your archives. On the next build Xcode recreates what it needs. You pay for it in time:

• The first build of each project is a full build, not an incremental one.
• Xcode re-indexes the project, so search, jump-to-definition and code completion are slow or incomplete for a while.
• Swift packages are resolved and checked out again, which may need a network connection.

Because Xcode rebuilds DerivedData as you work, the space you free comes back for the projects you're still building. The lasting win is in folders for projects you no longer open. Measuring each project folder first tells you which those are:

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

The biggest folders print last.

Clean Build Folder: one project, from inside Xcode

For the project you have open, choose Product, then Clean Build Folder or press ⇧⌘K. Apple's developer support recommends this as the easiest way to remove the build products and intermediate files Xcode made for a project (Apple Developer Forums).

It's the gentlest option. It works on one project at a time and clears its build output rather than its whole DerivedData folder, so you usually get less space back than by removing that folder. It's also the right first step when a build behaves oddly.

Delete DerivedData with Finder

This is the method most people want: clear several projects at once, with the Trash as a safety net.

1. 1

   Quit Xcode

   Choose Xcode > Quit Xcode so nothing is building or indexing while you remove its files.

2. 2

   Open the DerivedData folder

   In Finder, choose Go > Go to Folder (Shift-Command-G), type ~/Library/Developer/Xcode/DerivedData and press Return.

3. 3

   Pick the folders to remove

   Each folder is named after a project plus a random suffix. Select the ones you want to clear, or press Command-A to select them all.

4. 4

   Move them to the Trash

   Press Command-Delete to move the selected folders to the Trash. You can leave the empty DerivedData folder where it is.

5. 5

   Empty the Trash when you're sure

   Open a project in Xcode and build it. When it builds as expected, empty the Trash to get the space back.

~/Library is hidden in Finder by default. Go to Folder opens it anyway, so you don't need to show hidden files.

If Xcode is open while you do this, it can recreate folders immediately or report missing files in the build it's running. Quitting first avoids both.

Delete derived data from Terminal

Quit Xcode first in Terminal too. On macOS 15 and later there's a built-in trash command that moves items to the Trash instead of deleting them. Its manual page (man trash) says it first appeared in macOS 15.0.

To move every project folder to the Trash:

trash ~/Library/Developer/Xcode/DerivedData/*

To clear just one project, list the folders and use the project's name:

ls ~/Library/Developer/Xcode/DerivedData

trash ~/Library/Developer/Xcode/DerivedData/MyApp-*

The classic one-liner deletes everything permanently:

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

rm -rf skips the Trash and can't be undone. That's acceptable for DerivedData, since Xcode can rebuild all of it, but check the path before you press Return. A typo in an rm -rf line can remove something that can't be rebuilt.

In zsh, the default shell on macOS, these commands print "no matches found" if the folder is already empty. Nothing is removed in that case.

When deleting DerivedData helps, and when it doesn't

Clearing a project's DerivedData folder is a common fix because it throws away everything Xcode derived and makes it start again. It tends to help when:

• Search, jump-to-definition or code completion is wrong or missing, which points to a stale index.
• A build fails with errors that don't match the code, after switching branches or changing build settings.
• Swift packages won't resolve, or Xcode keeps using an old version of a package.

It rarely helps with code signing, provisioning profiles or errors that are really in your code. A long-running Apple Developer Forums thread makes the same point about signing problems (Apple Developer Forums). Try Clean Build Folder first, then the project's folder, before clearing everything.

Keep DerivedData from growing back

Most of DerivedData's growth comes from projects you've stopped opening. A few habits keep it in check:

• Clear old projects, not current ones. The du listing above shows which folders are big. The ones for projects you finished months ago free space that stays free.
• Keep scripted builds inside the repository. xcodebuild -derivedDataPath build/DerivedData keeps a command-line build's output next to the project, where removing the project folder removes it too.
• Know what Relative does. Setting the location to Relative in Xcode's Locations settings puts DerivedData next to each workspace instead. It's a global setting, so it changes every project at once.

What's safe to remove, and what isn't

Not everything under ~/Library/Developer/Xcode is a cache. Here's how the main folders compare:

Deleting DerivedData doesn't touch simulators or simulator runtimes, which can take more space than all your build data. Those live elsewhere and have their own tools. See how to delete iOS simulators and the full tour of why Xcode takes up so much space.

How MacClearings does it

MacClearings has a Suggestions rule for DerivedData. It lists each project folder inside it with its size, and checks them for you, because they're safe to lose and Xcode makes them again only when you build that project.

Suggestions rule · Xcode

Xcode DerivedData

Build products and indexes. Xcode rebuilds them the next time you build each project.

• ~/Library/Developer/Xcode/DerivedData/*

Checked for you, because it's safe to lose and doesn't come straight back.

A few details that matter for developers:

• It moves project folders, never the DerivedData folder itself. That folder is on MacClearings' list of places it never moves, so Xcode always finds it where it expects.
• Nothing moves until you review it. Checked folders wait in the Cleanup tray. Review & Clean Up… shows the full list, and Move to Trash is the only button that moves anything.
• It checks again right before moving. A folder that changed since it was measured, for example because Xcode built into it a minute ago, is skipped, and so is anything a running process has open. MacClearings tells you what it skipped and why.
• Every cleanup can be undone. History has Undo for the whole cleanup and Put Back for single items, as long as they're still in the Trash. MacClearings never empties the Trash, so the space comes back when you empty it.

Afterwards, History measures each cleaned place again after a day, a week and a month. For DerivedData of projects you still build, it will show the space coming back, which is expected. For old projects it shows the space that stayed free. Suggestions uses those results to order its groups by space that lasts.

The developer page lists every rule MacClearings has for Xcode, simulators, package managers and project build folders.