Where Did Derived Data Go? Deleting It in Modern Xcode

Why this happens

Derived Data is the scratch space Xcode uses for everything it generates while building: compiled object files, the index store, module caches, logs, and the .app products themselves. It is not part of your project, and it is safe to throw away — Xcode rebuilds it on the next build.

In older Xcode versions there was a Projects page in the Preferences window that listed every project with a Delete button next to its derived data. That page was removed, which is why the old instructions no longer match what you see on screen. The functionality did not disappear; it moved into the per-project settings and into the Locations tab.

When derived data goes stale or corrupt, the symptoms are usually odd rather than obvious: a build that fails with a linker error for a file you deleted, autocomplete that suggests symbols that no longer exist, or a change that simply refuses to appear in the running app. Clearing derived data is the standard first move for all of those.

How to fix it

1. Use File > Project Settings (the direct replacement)

With a project open, go to File > Project Settings. If you are working in a workspace (for example, one that contains a Pods project), the menu item reads File > Workspace Settings instead.

In that sheet you will see a Derived Data section with a path and a small grey arrow beside it. Click the arrow and Finder opens directly at the derived data folder for that project. Delete the folder for your project — or the whole DerivedData directory if you want a full reset — and build again.

This is the closest equivalent to the old Projects page, and it is the option that survives across Xcode versions.

2. Clean the build folder with a keyboard shortcut

If you only need to discard build products and intermediate files, you do not have to touch Finder at all. Press:

Shift + Option + Command + K

Xcode asks for confirmation with a message along the lines of Are you sure you want to clean the build folder for “MyProject”? This will delete all of the products and intermediate files in the build folder. Confirm and rebuild.

Note the difference from the plain Product > Clean (Shift + Command + K), which removes build products but keeps much of the intermediate state. Clean Build Folder is the stronger of the two and is usually enough to fix a confusing incremental build.

3. Change or inspect the location in Preferences

Open Xcode > Settings (called Preferences in older versions) and select the Locations tab. The Derived Data row shows the current path — by default ~/Library/Developer/Xcode/DerivedData — with the same reveal arrow. You can also switch it to a custom folder here, which is handy if you want derived data on an external drive or in a directory you can wipe with a script.

If you change the location, Xcode starts from scratch in the new place; the old folder is left behind and can be deleted manually.

4. Delete the folder from Terminal

When Xcode itself is misbehaving, or you want to clear every project at once, quit Xcode first and remove the directory:

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

Quitting first matters: if Xcode is running, it will happily recreate folders and hold file handles while you are deleting. After relaunching, the first build will be slow because everything is recompiled and re-indexed — that is expected, not a new problem.

To remove only one project’s data, list the folders first. Each one is named after the project with a random suffix:

ls ~/Library/Developer/Xcode/DerivedData
rm -rf ~/Library/Developer/Xcode/DerivedData/MyApp-abcdefghijklmnop

5. Keep derived data out of the way for CI

On a build machine you rarely want a shared, ever-growing derived data folder. xcodebuild accepts an explicit path, so each job can build into a throwaway directory:

xcodebuild -workspace MyApp.xcworkspace \
           -scheme MyApp \
           -configuration Release \
           -derivedDataPath ./build/DerivedData \
           clean build

Because the path is inside the workspace, cleaning up is a single rm -rf ./build and no job can poison the next one with stale state.

6. If the problem comes back immediately

Deleting derived data fixes state, not code. If a build error reappears right after a clean, the cause is in your project: a file referenced in the project but missing on disk, a stale framework search path, or two targets compiling the same source. Check the full error in the build log rather than assuming the cache is at fault again.

How to prevent it

• Clear derived data after switching branches that change project structure, not after every build.
• Keep the folder out of any backup or sync tool — it is large, changes constantly, and is worthless to restore.
• If disk space is tight, point Derived Data at an external volume via the Locations tab instead of deleting it repeatedly.
• Use -derivedDataPath on CI so each build starts clean without touching the developer’s machine.
• When a build behaves strangely, try Clean Build Folder first; it is faster than a full derived data wipe and fixes most incremental-build confusion.

FAQ

Is it safe to delete Derived Data?

Yes. It contains only generated files — build products, indexes, module caches and logs. Xcode recreates everything on the next build. The only cost is a slower first compile and a re-index of your project.

Why can’t I find the Projects page in Xcode anymore?

That page was removed from the Preferences window. Its job is now split between File > Project Settings (or Workspace Settings) for a per-project view and the Locations tab in Settings for the global path.

Does deleting Derived Data fix code signing errors?

Sometimes, when the cached build products are stale, but it is not a signing fix. If Xcode reports a provisioning profile or certificate problem, resolve that in the Signing & Capabilities tab and the developer portal; a clean build will not supply a missing profile.