Developer cleanup

How to Clear Xcode DerivedData, DeviceSupport & Archives (Reclaim 50 GB+)

If Xcode is taking up space on your Mac and you are not sure what is actually safe to delete, you are not alone. A busy developer's ~/Library/Developer folder can quietly accumulate 30, 50, even 100 GB of build artifacts, device support images, simulator runtimes, and app archives — most of which you will never need again. This guide walks through every major Xcode cache directory, gives you the exact Terminal commands to clear each one, and tells you honestly which folders are truly safe to nuke and which ones will cause pain if you touch them.

Why Xcode Eats So Much Disk Space

Xcode writes to several locations as you build and test apps. None of them clean themselves up automatically, and Apple's own Xcode preferences only expose a subset of them. The four biggest offenders are:

  • DerivedData — per-project build intermediates, indexes, and module caches
  • iOS / watchOS / tvOS DeviceSupport — a full symbol set copied from each physical device you have ever plugged in, per OS version
  • Archives — release builds you have distributed or exported via Organizer
  • CoreSimulator / Devices — simulator runtime data and installed app sandboxes

Clear Xcode DerivedData

DerivedData is the largest and most frequently abused accumulator. Its root is:

~/Library/Developer/Xcode/DerivedData/

Inside you will find one subfolder per project (named ProjectName-<hash>), plus three shared caches:

  • ModuleCache.noindex — compiled Swift and Clang module artifacts (can reach 200–400 MB on its own)
  • CompilationCache.noindex — an explicit compilation cache; Xcode 15+ uses this for incremental Swift builds
  • SDKStatCaches.noindex — small stat caches used by the build system

What is safe to delete

Everything inside DerivedData is regenerable. Xcode will rebuild it the next time you open a project. The only cost is a longer first build — typically a few minutes. There is no permanent data loss.

Delete DerivedData from Xcode

  1. Open Xcode.
  2. Go to Xcode → Settings → Locations (or Preferences → Locations in Xcode 13 and earlier).
  3. Click the arrow next to the DerivedData path to open it in Finder.
  4. Select all folders and move them to the Trash.

Delete DerivedData from Terminal

rm -rf ~/Library/Developer/Xcode/DerivedData/*

This removes all project-specific folders and the shared module caches in one shot. If you only want to clear a single project, delete its named subfolder instead.

Delete iOS DeviceSupport (and watchOS / tvOS)

Every time you connect a physical iPhone, iPad, Apple Watch, or Apple TV running a new OS version, Xcode copies a multi-gigabyte symbol package to your Mac. These live here:

~/Library/Developer/Xcode/iOS DeviceSupport/
~/Library/Developer/Xcode/watchOS DeviceSupport/
~/Library/Developer/Xcode/tvOS DeviceSupport/
~/Library/Developer/Xcode/visionOS DeviceSupport/

Each folder is named after the OS version (e.g., 16.6.1 (20G81)). On a machine used for a few years, these easily total 20–40 GB.

What is safe to delete

Any version you are no longer actively testing against is safe to remove. If a device running that OS version is connected again later, Xcode will re-copy the symbols. The one caution: if you still need to symbolicate crash reports from a specific OS version, keep that folder until you are done.

Delete old DeviceSupport from Terminal

# List iOS DeviceSupport folders with sizes
du -sh ~/Library/Developer/Xcode/"iOS DeviceSupport"/*

# Remove a specific version (adjust the version string)
rm -rf ~/Library/Developer/Xcode/"iOS DeviceSupport"/"16.6.1 (20G81)"

# Remove all (you will be reprompted to re-download when needed)
rm -rf ~/Library/Developer/Xcode/"iOS DeviceSupport"/*
rm -rf ~/Library/Developer/Xcode/"watchOS DeviceSupport"/*
rm -rf ~/Library/Developer/Xcode/"tvOS DeviceSupport"/*

Delete Xcode Archives

When you archive a build for distribution via Product → Archive, Xcode saves the result to:

~/Library/Developer/Xcode/Archives/

Archives are organized by date. Each .xcarchive bundle includes the compiled binary, dSYM symbol files, and Info.plist. They can range from a few hundred MB to several GB depending on app size and bitcode.

What is safe to delete — and what is NOT

This is the one area to pause before deleting:

  • Safe to delete: Archives for app versions that are no longer on the App Store, beta builds you never shipped, and archives where you have already exported the IPA elsewhere.
  • Do NOT delete without a backup: Archives for live App Store versions if you might need to re-export or resign the IPA. The dSYM inside the archive is required to symbolicate live crash reports from that exact binary. Once deleted, this is permanent — Xcode cannot regenerate a dSYM for a build it did not compile freshly.

Best practice: before deleting, export the dSYM from the archive via Xcode Organizer (Window → Organizer → Archives, right-click → Show in Finder) and store it somewhere safe.

Delete archives from Xcode Organizer

  1. Open Window → Organizer.
  2. Select the Archives tab.
  3. Select the archive, then press Delete.

Delete archives from Terminal

# List all archives with sizes
du -sh ~/Library/Developer/Xcode/Archives/*/*

# Remove a specific date's archives
rm -rf ~/Library/Developer/Xcode/Archives/2024-03-15

CoreSimulator: Simulator Runtimes and Device Data

Simulator data lives separately from Xcode:

~/Library/Developer/CoreSimulator/Devices/    # per-simulator app sandboxes
~/Library/Developer/CoreSimulator/Caches/     # runtime caches

Simulator runtime images (the actual .simruntime files for iOS 16, 17, 18, etc.) are stored system-wide by simctl and can each be 5–10 GB.

List and remove unused simulator runtimes

# List installed runtimes
xcrun simctl runtime list

# Delete an unused runtime (e.g., iOS 16.4)
xcrun simctl runtime delete "iOS 16.4"

# Delete unavailable/corrupted runtimes
xcrun simctl delete unavailable

Removing a simulator runtime is permanent — you will need to re-download it from Xcode's Platform settings if you need it again. Do not remove the runtime for the iOS version you are currently targeting.

Reference: Xcode Cache Paths and Safety at a Glance

Directory Typical Size Safe to Delete? Rebuilds Automatically?
~/Library/Developer/Xcode/DerivedData 5–30 GB Yes Yes — on next build
~/Library/Developer/Xcode/iOS DeviceSupport 2–5 GB per version Yes (old versions) Yes — when device reconnected
~/Library/Developer/Xcode/watchOS DeviceSupport 1–3 GB per version Yes (old versions) Yes — when device reconnected
~/Library/Developer/Xcode/Archives 500 MB–5 GB each Caution — see above No — permanent deletion
~/Library/Developer/CoreSimulator/Devices 1–10 GB Yes (unavailable sims) Yes — simulators recreated on demand
Simulator runtimes (simctl) 5–10 GB each Yes (unused versions) Must re-download from Xcode

The One-Click Way: Crumb's Developer Cleanup

If you would rather not remember six different paths and run them one by one, Crumb surfaces all four Xcode cache categories — DerivedData, DeviceSupport, Archives, and simulator device data — grouped by size so you can see at a glance which one is hoarding your disk. A single click clears the selected category. It also includes an "Is this safe to delete?" explanation for each item, which is useful if you have inherited a machine or are not sure how old a device support folder is. You can download Crumb and use the Developer cleanup as a free scan to find out exactly how much you are carrying around before committing to anything.

Preventing Accumulation Going Forward

A few habits keep Xcode's footprint manageable:

  • After shipping a major release, open Organizer and delete archives for versions more than two major releases back. Export the dSYMs first.
  • When you update to a new iOS beta, run xcrun simctl delete unavailable to remove stale simulator devices.
  • Once a year (or after a major Xcode upgrade), nuke DerivedData entirely. The next build takes longer but you start with a clean slate.
  • Keep only the simulator runtimes for the OS versions you actively test. Every unused runtime is 5–10 GB sitting idle.

Conclusion

Xcode's disk usage is almost entirely made up of caches and build artifacts that will rebuild on demand. DerivedData, DeviceSupport folders for older iOS and watchOS versions, and unused simulator runtimes can all be deleted without any permanent consequence. Archives require more care — keep them (or at least their dSYMs) for any version with live users. Run through this checklist once and most developers recover 30–60 GB without breaking a single build.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

Will clearing Xcode DerivedData break my project?
No. DerivedData contains only build intermediates and caches. Xcode regenerates it automatically the next time you build. The only side effect is a slower first build — usually a few extra minutes for a large project.
How do I delete iOS DeviceSupport files without losing the ability to debug?
You can safely remove DeviceSupport folders for iOS versions you are no longer testing against. If you reconnect a device running that OS version, Xcode will re-copy the symbols automatically. The only reason to keep an old folder is if you still need to symbolicate crash reports from that specific OS build.
Is it safe to delete Xcode Archives?
It depends. Archives for versions no longer on the App Store are generally safe to delete. For live versions, you should first export the dSYM from the archive (via Xcode Organizer) and store it separately — without the dSYM you cannot symbolicate crash reports from that binary. Once an archive is deleted, it cannot be recovered.
Why does Xcode take up so much space even after I delete DerivedData?
DerivedData is only one of several storage consumers. Simulator runtimes (each 5–10 GB per iOS version), DeviceSupport symbol packages (2–5 GB per device OS version), and older Archives often account for more space than DerivedData itself. Check CoreSimulator and the DeviceSupport directories as well.