Xcode Finally Added “Delete Derived Data”

Xcode adding Product -> Delete Derived Data… sounds like a tiny menu change. For iOS developers, it is more like Apple finally admitting that build caches are part of the debugging surface.

The old workflow was strangely ritualistic: failed build, broken SwiftUI Preview, missing package, stale module, then someone says, “Try deleting Derived Data.” The source material captures exactly that pain: developers used to jump through Settings, Finder, or rm -rf ~/Library/Developer/Xcode/DerivedData just to reset a cache that Xcode itself created.

The useful idea is not “now there is a button.” The useful idea is this: Derived Data is not your source of truth. It is a disposable build cache. When the cache becomes more trusted than the project state, debugging gets weird.

The key idea

Derived Data stores Xcode-generated build products, indexes, module caches, logs, and other intermediate artifacts. Xcode Cloud’s documentation also describes derived data and cached information as something stored to speed up later builds, with clean builds available when reuse is not desired.

That is the correct mental model: cache first, truth second.

When everything is healthy, Derived Data makes builds faster. When it becomes stale or inconsistent, Xcode may behave as if your project is broken even when the real problem is cached state. That is why deleting Derived Data has become the unofficial “reset the build brain” move.

Core example

Problem:

A Swift package was renamed on a branch.
The project builds on CI, but locally Xcode still reports:
"No such module" or "Missing package product".

Naive approach:

# Risky and broad
rm -rf ~/Library/Developer/Xcode/DerivedData

This usually works, but it deletes Derived Data for every project. On a large machine with multiple active workspaces, that means unnecessary rebuilds and lost local build cache.

Better approach in Xcode 27 beta:

Open the affected project
Product -> Delete Derived Data…
Build again

Better approach for automation or CI:

xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -derivedDataPath .build/DerivedData \
  clean build

The xcodebuild manual documents -derivedDataPath as the option that overrides the folder used for derived data when performing an action on a scheme.

Get Hui Wang’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Why this works:

The local error is often not caused by the Swift source file you are staring at. It is caused by Xcode holding onto generated state from an older graph: compiled modules, package resolution artifacts, indexes, or intermediate build outputs. Deleting Derived Data forces Xcode to rebuild that generated state from the current project configuration.

The important distinction is this: cleaning the build folder and deleting Derived Data are not the same mental operation. A clean build removes build products for the current build action. Deleting Derived Data is closer to resetting Xcode’s project-specific memory.

The practical limitation

Do not turn “Delete Derived Data” into a superstition.

If deleting Derived Data fixes the same issue every day, the cache is not the root cause. It is hiding another problem: unstable package configuration, generated files not tracked correctly, branch switching side effects, custom build scripts writing into the wrong location, or a toolchain mismatch.

The new menu item makes the recovery cheaper. It does not make the underlying build graph healthier.

That matters especially in teams. A senior engineer should not stop at “delete Derived Data.” The better question is: why did the generated state become inconsistent with the declared project state?

For local development, the new menu is a quality-of-life improvement. For CI, the better pattern is still to make Derived Data explicit, isolated, and disposable. A CI job should not depend on mysterious shared state from a previous unrelated build.

Practical rule: delete Derived Data when Xcode’s generated state is suspicious; fix the project when deleting it becomes part of the normal workflow.

Conclusion

• Xcode 27 beta’s Delete Derived Data menu is small, but it fixes a very real developer workflow problem.
• Derived Data should be treated as a disposable cache, not as a trusted part of the project.
• The core debugging move is to separate source truth from generated state.
• In interviews, phrase it this way: “Deleting Derived Data works because it forces Xcode to rebuild cached build and indexing artifacts from the current project graph.”
• In real projects, use the new menu for fast recovery — but investigate repeated cache failures instead of normalizing them.