If you develop on a Mac, Xcode's caches, simulators, and derived data have probably eaten through more of your disk than you realize. Knowing how to clean Xcode on Mac properly — without breaking active projects or deleting something you actually need — is one of those skills that pays for itself the first time your SSD hits 90% capacity. This guide walks through both approaches: hand-rolled Terminal commands and GUI cleaner tools, with honest notes on speed, safety, and what each method tends to leave behind.
What Exactly Is Xcode Junk?
Before you delete anything, it helps to know which categories of data are safe to remove and which ones you should leave alone. Xcode accumulates several distinct types of disk waste:
- Derived Data — build artifacts stored in
~/Library/Developer/Xcode/DerivedData/. Safe to delete; Xcode rebuilds these on the next build (which will be slower the first time). - Archives —
~/Library/Developer/Xcode/Archives/. These are your signed app archives. Delete only old ones you no longer need for distribution or debugging. - Simulator runtimes — stored under
~/Library/Developer/CoreSimulator/and in/Library/Developer/CoreSimulator/Volumes/(macOS 13+). Old runtime images for iOS versions you no longer test against can be several gigabytes each. - Xcode caches —
~/Library/Caches/com.apple.dt.Xcode/. Generally safe to remove. - Device support files —
~/Library/Developer/Xcode/iOS DeviceSupport/. Safe to delete for devices and OS versions you no longer connect. - Documentation —
~/Library/Developer/Shared/Documentation/DocSets/. Large but re-downloadable.
The Xcode Developer folder as a whole (~/Library/Developer/) is not safe to delete wholesale — it contains your code signing identities and provisioning profile data alongside the junk.
The Terminal Approach: xcrun and rm Commands
The traditional way to clean the Xcode developer folder is a set of targeted rm and xcrun commands. Here is the standard sequence most developers use.
Step 1 — Clear Derived Data
rm -rf ~/Library/Developer/Xcode/DerivedData/This is the safest delete on this list. Derived Data is purely a build cache; nothing you can't regenerate lives here.
Step 2 — Clear the Xcode cache
rm -rf ~/Library/Caches/com.apple.dt.Xcode/Step 3 — Remove old iOS Device Support files
ls ~/Library/Developer/Xcode/iOS\ DeviceSupport/Review the list first, then delete only the versions you no longer need:
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.0\ \(20A362\)/Step 4 — Remove unused Simulator runtimes (macOS 13+)
Apple moved simulator runtime management to xcrun simctl in Xcode 14. The correct way to remove a runtime image is:
# List installed runtimes
xcrun simctl runtime list
# Delete a specific runtime by identifier
xcrun simctl runtime delete "com.apple.CoreSimulator.SimRuntime.iOS-16-4"Avoid deleting files directly from /Library/Developer/CoreSimulator/Volumes/ — the simctl command updates the runtime index properly; a manual rm can leave the database in an inconsistent state.
Step 5 — Delete old Archives (carefully)
open ~/Library/Developer/Xcode/Archives/Open Finder and review archives by date. Delete entire year folders you know you no longer need. Alternatively, use Xcode's Organizer window (Product → Organizer → Archives) to delete archives one at a time with full visibility into what you're removing.
What the Terminal approach misses
- It operates blind — no disk-size preview before you commit to deletion.
- It does not surface orphaned simulator containers from deleted apps, which can accumulate under
~/Library/Developer/CoreSimulator/Devices/. - It won't catch Xcode-related leftovers in
~/Library/Application Support/,/var/folders/temp caches, or system-level caches owned bycom.apple.dt.*services. - A typo in an
rm -rfpath is unrecoverable — the Trash is bypassed.
The GUI Cleaner Approach
If you prefer to see what you're deleting before it's gone, a native Mac cleaner handles most of the same targets without requiring you to remember paths.
Crumb is a menu-bar cleaner built for exactly this workflow. Its one-click Clean pass picks up Xcode-related caches, system temp files, and purgeable space. More useful for Xcode specifically is its Visualize tab, which shows a disk map of your largest directories — making it immediately obvious that ~/Library/Developer/ has ballooned to 40 GB. From there you can drill into Derived Data or old simulator runtimes, see their sizes, and decide what to remove with full context.
The Uninstall tab is worth mentioning here too: if you've ever removed an old version of Xcode by dragging it to the Trash, there's a good chance leftover files remain in /Library/Developer/ and elsewhere. Crumb surfaces those orphaned files alongside the app so you can remove everything in one pass.
The main trade-off is that a GUI tool won't match a shell script for automation or CI pipelines. If you need to clean a build agent on every run, the xcrun and rm route wins by default.
Side-by-Side Comparison
| Factor | Terminal (xcrun / rm) | GUI Cleaner (e.g. Crumb) |
|---|---|---|
| Preview before deleting | No (unless you run ls first) | Yes — sizes shown before removal |
| Speed | Fast once you know the commands | Fast with one-click scan |
| Automation / scripting | Yes — scriptable, CI-friendly | No |
| Risk of accidental deletion | Higher (typos bypass Trash) | Lower (removes to Trash or previews) |
| Orphaned Xcode leftovers | Must know paths manually | Surfaced by disk map / Uninstall tab |
| Simulator runtime management | xcrun simctl (correct approach) | Varies by tool |
| System-wide / other-user caches | Requires sudo + extra commands | Handled with authorization prompt |
| Learning curve | Medium (need to know the paths) | Low |
What Is Safe to Delete vs. What to Keep
- Safe to delete: Derived Data, Xcode caches, old iOS Device Support folders, simulator runtimes for iOS versions you don't test, DocSets you don't reference.
- Think before deleting: Archives (keep anything you may need to re-export or dSYM-symbolicate a crash report from), simulator device containers (you lose in-progress simulator app data).
- Do not delete:
~/Library/MobileDevice/Provisioning Profiles/,~/Library/Keychains/, or anything under~/Library/Developer/Xcode/UserData/(contains your custom key bindings and snippets).
Cleaning is permanent when done via Terminal. If you are not certain what a folder contains, open it in Finder first or use Crumb's Is this safe to delete? feature, which explains any folder's purpose and estimated removal risk before you act.
Putting It Together: A Practical Routine
- Run
rm -rf ~/Library/Developer/Xcode/DerivedData/freely — this is always safe and often recovers 10–20 GB. - Use
xcrun simctl runtime listto audit simulator runtimes, then delete only the ones you haven't used in months. - Open Xcode's Organizer to review and prune old archives interactively.
- For a broader sweep of caches, temp files, and anything you might have missed, run a one-time pass with a disk cleaner to see the full picture before committing. Download Crumb if you want a native, no-account option that shows you sizes before it deletes anything.
Conclusion
There is no single best xcode disk cleaner — the right choice depends on how you work. If you live in the Terminal and need scripted automation, a handful of rm and xcrun simctl commands is all you need, provided you keep a cheat sheet of the paths and resist the urge to use wildcards in the wrong directory. If you prefer to see what you're removing and want a safety net before anything is gone for good, a GUI approach gives you that visibility with much less risk of an expensive mistake. In either case, the biggest gains come from the same three targets: Derived Data, old simulator runtimes, and unused Device Support files — together those almost always account for the bulk of Xcode's disk footprint.