Roomier
The safe question is not “Can I delete Xcode files?” It is: What created this directory, what will I lose, and how does it come back?
Start with the large category, not a cleanup command
Pause active builds and simulator work. A large directory proves size; it does not prove that the contents are stale or safe to remove.
| Category | What it contains | Safer action | Recovery cost |
|---|---|---|---|
| Derived Data | Per-project intermediates, indexes, logs, and generated products | Close Xcode, identify one project entry, and move only that entry to Trash when the project can rebuild | A full rebuild and re-index; the next build may be materially slower |
| Archives | Release archives, symbols, and distribution metadata | Review in Xcode Organizer and retain every archive and dSYM needed for a shipped build | The exact archive may not be reproducible from today’s source, tools, or signing state |
| Simulator runtimes | Shared operating-system images | Use Xcode Settings → Components for OS versions you no longer test | A large download before that runtime can be used again |
| Simulator devices | Per-device apps, data, settings, and test state | Use Window → Devices and Simulators for devices whose state is no longer needed | Installed apps and local test data are lost; a clean device can be recreated |
| Device support | Files Xcode uses with physical OS and device versions | Leave it alone until the exact Xcode and device recovery path is verified | Debugging that device may require preparation or another download |
| Project output | Tool-owned directories such as SwiftPM .build | Prefer the build tool’s cleanup path; otherwise move the exact rebuildable output to Trash | Dependencies and products rebuild or download again |
Treat Derived Data as rebuildable, not free
Derived Data is often the first useful place to look because Xcode regenerates build products and indexes. Close Xcode, stop related build tools, identify the folder belonging to a project you still have, then move that one folder to Trash. If you cannot connect a folder to a project you can rebuild, leave it alone.
Protect archives for anything you shipped
Archives are not ordinary cache. They can hold the exact product and debug symbols needed to understand a customer crash. Keep the archive and dSYMs for every supported or distributed version. “The source still exists” is not the same as “the exact archive can be recreated.”
Remove simulator runtimes through Xcode
A runtime is an entire platform operating system shared by simulator devices. Use Xcode Settings → Components for platform versions outside the active compatibility matrix. The removal is reversible by download, but projects cannot run against that simulator version until it returns.
Separate simulator devices from runtimes
A simulator device carries its own installed apps, documents, settings, and test state. In Xcode, open Window → Devices and Simulators and remove only devices whose state you no longer need. Keep any device holding a reproduction, seeded database, login state, or other evidence.
Leave physical-device support out of blanket cleanup
Device-support recovery behavior changes with Xcode and the connected device. Do not apply a recursive delete rule to the category. First verify the installed Xcode, physical OS versions still under test, and the current supported recovery path.
Clean project output through its owning tool
Project output is easier to reason about when the manifest and build tool identify its owner. SwiftPM .build data can be recreated, but the next dependency resolution and build may cost time and network access. Prefer the tool’s own clean action when it exists and move manual cleanup to Trash before emptying it.
A safe order of operations
- Finish or cancel active builds and simulator jobs.
- Identify the largest category and its owning project, simulator, platform, or tool.
- Preserve shipped archives and simulator state used for an active reproduction.
- Use Xcode’s Components and Devices and Simulators controls for runtimes and devices.
- Move one rebuildable project output or Derived Data entry to Trash.
- Reopen the project and verify the expected build, simulator, and debugging workflow.
- Empty Trash only after that check; space in Trash may not appear as free yet.
What Roomier can do today
The current development build can scan a chosen folder or volume, draw relative storage, report inaccessible items, recognize developer-artifact families, and explain evidence on-device. Direct cleanup is narrower than recognition: eligible SwiftPM .build, unambiguous Git-ignored node_modules, verified default Next.js .next output, and metadata-proven individual Xcode Derived Data project entries can enter the immutable cleanup plan. Shared containers, archives, simulator data, device support, custom output, package source checkouts, and unproven families remain inspect-only or provider-managed.