DerivedData cleanup
Xcode DerivedData cleanup without deleting projects
DerivedData can grow while you build, index, preview, and test. That does not make every item inside it an equally safe cleanup target.
The bounded answer
Do not treat the whole DerivedData folder as one disposable block. BuildSweep 1.0 limits actionability to verified Index.noindex and Build/Intermediates.noindex leaves inside supported DerivedData entries, then revalidates the exact plan before moving anything to Finder's Trash.
A safer review sequence
- 1Close or pause active Xcode work before diagnosing generated storage.
- 2Separate rebuildable leaves from Archives, test results, SourcePackages, simulator data, and project source.
- 3Review the exact path and frozen plan before any move.
- 4Move selected verified leaves to Finder's Trash; empty Trash later only when you choose.
Check the storage shape locally
Use the manual planner without sharing paths, project names, inventories, or exact values with VaultDevLabs.
Open the Xcode storage planner →Primary references and product boundary
- Apple: Running tests and interpreting results
- Apple: Distributing apps for beta testing and releases
- Apple: Managing files and folders in an Xcode project
Apple documents Xcode archives, test-result bundles, and project-file operations. The exact two-leaf action boundary described here is BuildSweep 1.0's deliberately narrower product policy, not a claim that Apple designates every DerivedData item as safe to remove.
Diagnose before you move anything
BuildSweep reviews supported Xcode-generated storage locally and requires an exact frozen plan before selected leaves move to Finder's Trash.
View BuildSweep in the Mac App Store