If you have ever opened Disk Utility and wondered why macOS is reporting far more storage used than your actual projects seem to warrant, Xcode is almost certainly the culprit. A fresh install sits around 7–8 GB, but after a few months of active development the total footprint across hidden caches and support files commonly reaches 50–100 GB or more. The good news is that the space is spread across just six well-known locations, and knowing which one is the offender makes safe cleanup straightforward.
Why Xcode storage bloat happens
Xcode does a lot of work invisibly: it compiles every framework dependency from source, stores full OS images for every device you have ever plugged in, and keeps build artifacts around so incremental builds stay fast. None of that is wrong in principle, but the housekeeping almost never runs automatically, so the files pile up indefinitely. The sections below walk through each location, where to find it, roughly how large it can grow, and whether deleting it is safe.
The 6 hidden folders eating your disk
1. DerivedData — the biggest offender
Location: ~/Library/Developer/Xcode/DerivedData/
DerivedData holds build artifacts, indexes, and compiled module caches for every project you have ever opened. A mature codebase with many dependencies can accumulate 10–30 GB here, and projects that use Swift Package Manager tend to grow even faster because each resolved package gets its own build graph.
Deleting DerivedData is safe. The only cost is a slower next build, because Xcode must recompile from scratch. You can delete it from Xcode itself without touching the Terminal:
- Open Xcode and choose Xcode → Settings → Locations.
- Click the arrow next to the Derived Data path to reveal it in Finder.
- Delete the folder contents, or individual project folders inside it.
Or from the Terminal:
rm -rf ~/Library/Developer/Xcode/DerivedData2. DeviceSupport — one image per iOS version per device
Location: ~/Library/Developer/Xcode/iOS DeviceSupport/ (and equivalents for watchOS, tvOS, visionOS)
Every time you connect a physical device running a version of iOS that Xcode has not seen before, it copies a multi-GB disk image from the device so it can symbolicate crash logs. These images are version-locked, so the folder fills with one entry per OS version per platform — often 20–40 folders over time, at 1–3 GB each. It is not unusual to find 30–60 GB here.
Entries for OS versions your devices no longer run are safe to delete. Keep only the versions that match devices you still test on.
ls -lh ~/Library/Developer/Xcode/iOS\ DeviceSupport/Review the list, then remove old entries individually rather than wiping the entire folder.
3. Archives — your entire release history
Location: ~/Library/Developer/Xcode/Archives/
Each time you archive a build for App Store submission or ad-hoc distribution, Xcode writes a .xcarchive bundle here. These bundles include the full compiled binary, dSYM debug symbols, and a copy of the app. A single archive for a large app can exceed 1 GB; years of monthly releases add up quickly.
Archives are safe to delete once you no longer need to re-export or symbolicate crashes from that version. If you distribute outside the App Store, keep the dSYM files separately before deleting. You can manage archives inside Xcode via Window → Organizer → Archives.
4. Simulators — whole OS images on disk
Location: ~/Library/Developer/CoreSimulator/Devices/
Each simulator runtime — iPhone 15 running iOS 17, iPad running iOS 16, and so on — is a self-contained virtual device image. Xcode preserves every device you have ever created. Simulators themselves are small, but their associated runtimes (stored separately, see below) are large. Still, accumulated device images across many runtime versions can reach 10–20 GB.
Removing simulators you no longer test on is safe. Use the simctl command-line tool that ships with Xcode:
- List all simulators:
xcrun simctl list devices - Delete unavailable (already uninstalled) simulators:
xcrun simctl delete unavailable - Delete a specific device by its UDID shown in the list:
xcrun simctl delete <UDID>
You can also delete runtimes you no longer need from Xcode → Settings → Platforms.
5. CoreSimulator caches — often invisible, often huge
Location: ~/Library/Caches/com.apple.dt.Xcode/ and /Library/Developer/CoreSimulator/Profiles/Runtimes/ (system-level)
The simulator runtime images themselves live at the system level — /Library/Developer/CoreSimulator/Profiles/Runtimes/ — at roughly 5–10 GB per runtime version. These are separate from the per-device folders above. Additionally, Xcode keeps its own user-level cache under ~/Library/Caches/com.apple.dt.Xcode/ for things like documentation downloads and module maps.
Runtime images can be removed safely through Xcode → Settings → Platforms; do not delete them manually from the system path, as the package manager tracks them. The user-level cache is safe to clear at any time.
6. Swift Package Manager cache — the silent accumulator
Location: ~/.swiftpm/ and ~/Library/Caches/org.swift.swiftpm/
SPM keeps a local clone of every package repository it has ever resolved, plus compiled build products for each version. Projects with many dependencies, or projects that switch between dependency versions frequently, can leave several gigabytes of orphaned clones here.
Both locations are safe to delete. SPM will re-clone and rebuild on the next swift build or Xcode open.
rm -rf ~/.swiftpm/checkouts
rm -rf ~/Library/Caches/org.swift.swiftpmQuick reference: which folder to check first
| Folder | Typical size | Safe to delete? | Rebuild cost |
|---|---|---|---|
| DerivedData | 10–30 GB | Yes | Slower next build |
| DeviceSupport | 20–60 GB | Yes (old versions) | Re-downloaded on connect |
| Archives | 5–30 GB | Yes (old releases) | Cannot re-export that build |
| Simulators (devices) | 5–20 GB | Yes | Recreated on demand |
| CoreSimulator runtimes | 5–10 GB each | Yes, via Xcode UI | Re-downloaded from Xcode |
| SPM cache | 1–10 GB | Yes | Re-cloned on build |
How to find the actual culprit fast
Before deleting anything, it helps to confirm which folder is really consuming the space on your specific machine. You can use du in the Terminal to measure:
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport
du -sh ~/Library/Developer/Xcode/Archives
du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh ~/Library/Caches/com.apple.dt.Xcode
du -sh ~/.swiftpmIf you would rather skip the Terminal altogether, Crumb's whole-Mac audit automatically locates and sizes all of these folders — along with everything else on your Mac — and surfaces the largest items so you can see at a glance which location is the real offender before you touch anything.
A note on safety before you delete
All of the folders covered here are regenerable — Xcode will recreate them as needed — so the risk is low. The main exceptions are Archives: once deleted, you cannot re-export that specific binary or use its dSYMs to symbolicate old crash reports. If you submit to the App Store and keep crash reporting enabled, hold on to at least the dSYM bundles from recent releases before clearing old archives.
Deleting is permanent. There is no undo beyond a backup. If you are unsure about a specific subfolder, check its modification date before removing it — anything untouched for more than a year is almost certainly stale.
Keeping Xcode storage manageable going forward
- Clear DerivedData after finishing a major feature branch, not just when disk space runs low.
- After each App Store release, archive the dSYM files to a separate folder and delete the
.xcarchive. - Remove simulator runtimes for iOS versions you no longer need to test, especially after a major OS release cycle ends.
- Disconnect devices you no longer develop for — their DeviceSupport images will stop accumulating.
For a one-time deep clean that covers Xcode leftovers alongside system caches, logs, and other storage hogs, you can download Crumb and run a full audit to see exactly where your gigabytes are going before committing to any deletions.