DerivedData is Xcode's build cache. It speeds up builds and grows quietly, often to tens of gigabytes across old projects.
By MacMonitor · Published · Updated · macOS 26; app requires macOS 14 or later
Short answer: the default DerivedData location is ~/Library/Developer/Xcode/DerivedData. Stop builds, quit Xcode, and move an unneeded project's derived-data folder to the Trash in Finder. Xcode recreates indexes and build products; your next build and indexing pass may take longer.
In Xcode, open Settings → Locations and inspect Derived Data. Apple allows a custom or project-relative location, so the default path may not describe your setup. Use the arrow next to the location to open it in Finder.
DerivedData stores project indexes, logs and build products, including intermediate files. It is separate from your source repository and release archives. A project folder may have a name such as ExampleApp-…; that is a path pattern, not a measured cleanup result.
Consider it for an old project you no longer build, or as a targeted troubleshooting step after a build problem. Clearing every project's data after each build discards reusable work. Save any diagnostic logs or generated outputs you need first.
Product → Clean Build Folder affects the current project's build products. It is not a disk-wide cleanup of all projects.
| Data | Purpose and decision |
|---|---|
| DerivedData | Regenerable build products and indexes. Check custom locations. |
~/Library/Developer/Xcode/Archives | Archived releases and symbols. Keep what you need for distribution and crash investigation. |
| Simulator runtimes | OS images managed under Xcode Settings → Components in current Xcode; older versions use Platforms. Removing a runtime is different from erasing a test device. |
| Simulator device data | Installed test apps and their data. Follow the simulator cleanup guide; erasing removes that data. |
| iOS DeviceSupport | Support data associated with connected OS/device versions in some Xcode installations. It is not DerivedData; verify your Xcode version and debugging needs before removing it. |
If you are looking for “Xcode DerivedData delete” instructions because a build failed, first record the actual error. A missing signing identity, a dependency-version conflict and a stale build artifact are different problems. Clearing build data can remove one source of state, but it does not repair every configuration issue.
For storage cleanup, start with projects you no longer open regularly. For troubleshooting, target the affected project and preserve the logs that describe the failure. This makes the cleanup a controlled experiment: you can see whether the same project succeeds after its generated data is recreated.
A default folder is only the starting point. A project, workspace, command-line build or separate development environment may direct output elsewhere. If you clear the standard directory and it barely changes the disk total, do not assume the cleanup failed. Inspect the location actually used by the build you are investigating.
Keep source folders and generated output distinct in your notes. A directory near a project can still contain a mixture of source, downloaded dependencies and generated files. Before removing it, confirm its purpose in the project’s settings or build instructions rather than deciding from the word “build” alone.
Imagine that you have an active app, a training project and several abandoned prototypes. This is an illustrative scenario. Rebuilding the active app every day benefits from reusable build products, while old prototypes may be better candidates for a deliberate storage review.
Close Xcode and any separate build processes, inspect the relevant derived-data folders, and move only the old projects’ generated data to Trash. Keep the source repositories and release archives. Reopen the active project afterward to check that its configuration and normal build still work. There is no need to clear its cache just because other generated folders were removable.
Regenerable does not mean free to recreate. The next build may spend more time compiling and indexing. A dependency that is no longer available locally might require a network download or valid access to its source. A work session with a deadline or no internet connection is a poor moment for a broad reset.
Save any generated artifact that you deliberately use outside the build. If another workflow depends on a file inside an output directory, understand that dependency before removal. Ideally the project can recreate it from documented inputs, but a cleanup should not assume that every development environment is organized ideally.
An archive is a record of a distribution build, not simply another temporary project directory. Its value may include the ability to export a release or investigate a crash associated with that build. Decide archive retention according to your release and support needs.
If you store archives elsewhere, check that the copy is complete and usable before deleting the local one. A source-code tag is valuable, but it is not automatically a substitute for every artifact and symbol associated with a shipped binary. Treat this as a release-management decision rather than an extension of “clear Xcode cache.”
This distinguishes a folder size from storage actually returned to the disk. APFS sharing, snapshots and other running workloads can affect the difference. Record what you observed instead of treating the selected size as a guaranteed saving.
Stop active builds and quit the tools using the data first. Removing output while another process is writing it makes the result harder to interpret and can interrupt a build. A project-scoped cleanup from Xcode’s own menu is a different workflow from deleting folders in Finder.
A successful build and indexing pass recreate useful generated data. Growth after rebuilding is expected. If the folder keeps expanding unexpectedly, compare individual projects and build configurations instead of repeating a complete deletion.
DerivedData cleanup is separate from simulator device storage. If you want to inspect installed runtimes or erase a test device, follow the simulator guide and preserve any test state you need.
No blanket recommendation is appropriate. The contents and location can vary with the Xcode and device versions in use. Check your debugging requirements and Apple’s current documentation rather than applying a command copied for another setup.
Prefer a documented way to recreate generated output from the correct source, dependencies and tool versions. If a handoff relies on a file that exists only in DerivedData, identify and preserve that dependency before cleanup. A colleague being able to build the project from its documented inputs is a more reliable handoff than inheriting an unexplained cache folder. Release artifacts and required symbols deserve their own retention plan alongside that reproducible setup.
Cleaner → Build Caches groups supported developer cleanup candidates. Inspect the category, path and consequence before confirming. Simulator erasure is permanent; it does not share the recovery behavior of a Trash move.