How Xcode DerivedData grows—and what a safe review includes
Review a known generated-data location without widening the rule to source code, projects, or unrelated developer files.
Direct answer
DerivedData contains build products, indexes, and intermediate files that Xcode can regenerate. A safe rule matches the exact generated-data boundary, explains the cost of regeneration, and rechecks the path immediately before moving it to Trash.
When this guide applies
- Xcode storage has grown after repeated builds, indexing, previews, or documentation generation.
- You need to distinguish generated build data from source repositories and permanent archives.
- You want a reversible review process that explains the next-build cost before moving generated data.
Step-by-step review
Stop active build work
Finish or cancel builds, tests, previews, and documentation generation before reviewing a DerivedData directory.
Confirm the exact boundary
Match the project-specific directory under the configured Derived Data location; do not widen the selection to the entire Developer folder.
Inspect identity and recency
Review the path, allocated size, modification time, project association, and whether Xcode is still using the directory.
Account for regeneration
Expect the next build, index, preview, or documentation build to take longer while Xcode recreates required output.
Move, verify, and recover deliberately
For a supported rule, move the exact directory to Trash, rescan the original scope, and retain the recovery location until you are confident it is no longer needed.
Technical context
Keep the boundary exact
The rule must match the known DerivedData location, not an entire Developer directory and never a source tree.
Show the regeneration cost
Removing generated data can make the next build or index slower. That consequence belongs beside the expected storage effect.
Verify the result honestly
Moving to Trash does not immediately free disk space. DiskStory rescans the original scope and records the Trash recovery location without claiming the Trash was emptied.
Risks and actions to avoid
The Developer directory is not disposable
It can also contain device support, simulators, archives, documentation, and other data with different recovery characteristics.
Source trees are outside the rule
A similarly named project folder, checkout, package cache, or custom build location must not be inferred to be DerivedData.
Active work can recreate or mutate files
Removing generated data while Xcode or a build tool is using it can produce confusing results or immediate regeneration.
What the Omuuz product can—and cannot—do
What it can do
DiskStory can identify a supported exact DerivedData boundary, show allocated size and recency, explain regeneration cost, and reverify before a reversible move to Trash.
What it cannot do
DiskStory does not treat the whole Developer directory as generated data, select source code, empty Trash, or guarantee that removing DerivedData fixes a build problem.
Product evidence
