What Xcode actually hoards under ~/Library/Developer

If you ship Apple-platform code, this folder is silently the second-biggest thing on your disk after your home directory. Five buckets, 50–200 GB on a typical working Mac. Here is what each one is for, and which ones you can clear today without breaking anything tomorrow.

Why Xcode keeps so much

Xcode is, structurally, a build system that caches very aggressively, plus a simulator host that mounts macOS-sized DMGs for every iOS version it has ever supported, plus an archive store that keeps full app bundles around for App Store re-submission and crash symbolication. None of that is wrong on its own, each cache exists for a reason. The problem is that Xcode never thins them automatically. Files from 2021 still live there next to files from yesterday.

Result: on a Mac that has shipped a few apps and run a few WWDC betas, ~/Library/Developer grows to 50–200 GB without anyone noticing. Here are the five things inside it.

1. DerivedData, the easy GB

Path: ~/Library/Developer/Xcode/DerivedData/<workspace>-<hash>/

What it is: per-project module caches, build products, indexes, logs. Recreated on the next build. Usually 1–8 GB per active project, and there is one folder per project you have ever opened.

Safe to delete? Always. Xcode rebuilds whatever it needs. The only side effect is the next build of any active project is a clean build (slower), and the in-IDE index has to rebuild (a few minutes of "Indexing…" in the status bar).

Common mistake: deleting DerivedData while Xcode is running, which can wedge the build system mid-write. Quit Xcode first. (Aguacatech's Xcode Cleanup refuses to touch DerivedData while Xcode is running.)

2. Archives, the one that needs thought

Path: ~/Library/Developer/Xcode/Archives/<date>/

What it is: .xcarchive bundles produced by Product → Archive. Each archive contains the app's binary, its dSYMs (debug symbols), and the build manifest. Roughly 100–500 MB each.

Safe to delete? Mostly, with a caveat. You need the dSYMs from an archive to symbolicate crash reports from that build, and you can't re-upload a build to App Store Connect without the original archive. So:

• Archives from apps you no longer ship: safe.
• Archives older than 6 months for an app you do ship: usually safe (App Store Connect retains the dSYMs you uploaded). Aguacatech flags these as "legacy candidates".
• Archives from the last 60 days for an active app: keep them.

3. iOS Device Support, usually safe, occasionally surprising

Path: ~/Library/Developer/Xcode/iOS DeviceSupport/<ios_version> <build>/ (plus watchOS, tvOS, visionOS variants).

What it is: per-device, per-iOS-version symbol files for every real iPhone or iPad you have ever plugged in to debug. 1–5 GB each. Required for live debugging against that device+OS combo.

Safe to delete? Yes for old majors (iOS 13/14/15/16), maybe for the current major. Xcode re-downloads the support folder for any device you plug in again, it just takes a few minutes the first time. If you only debug on the latest iOS, you can nuke everything older today.

4. Simulator Runtimes, the silent giant

Path: mounted DMG-backed volumes at /Library/Developer/CoreSimulator/Volumes/<runtime>/, plus cache bundles under ~/Library/Developer/CoreSimulator/Caches/.

What it is: one full macOS-sized DMG per iOS version (or watchOS, or tvOS, or visionOS) that you have installed. 4–9 GB each. On a dev Mac that has been keeping current for two years across iOS 16/17/18, plus watchOS, you can easily have 50+ GB in here.

Safe to delete? Yes for runtimes you haven't used in 90+ days. Xcode → Settings → Platforms can re-download any of them in 10 minutes. The trap is that these are root-owned mounted volumes, so they don't go to Trash, they delete permanently via xcrun simctl runtime delete <identifier>. Aguacatech shows a pre-clean confirmation sheet that names every runtime by ID and version before deleting.

5. Simulator Devices, the dust under the rug

Path: ~/Library/Developer/CoreSimulator/Devices/<uuid>/, enumerated via xcrun simctl list -j devices.

What it is: every simulated device you have ever created, including the dozen Xcode auto-spawns the first time you use a new iOS version. Each device has its own data directory which can accumulate gigabytes of test app sandboxes, screenshots, and Core Data stores.

Safe to delete? Yes for devices not booted in 90+ days. Same caveat as runtimes, these delete permanently via xcrun simctl delete <uuid>, not to Trash. Aguacatech surfaces last-boot date and pre-selects only the genuinely stale ones.

The realistic order to clean

1. Quit Xcode. Non-negotiable for DerivedData and runtime operations.
2. DerivedData + Xcode Caches, the no-think wins. 5–30 GB on most Macs.
3. Old iOS DeviceSupport majors, anything before the current iOS version is fair game if you don't debug on those devices anymore.
4. Simulator Runtimes not used in 90+ days, usually the biggest single line item. 30–70 GB.
5. Simulator Devices not booted in 90+ days, 1–10 GB of accumulated test app state.
6. Archives older than 6 months for shipped apps, only after you have confirmed the dSYMs are in App Store Connect.

What we deliberately do not touch (yet)

• CocoaPods caches at ~/Library/Caches/CocoaPods. Often a few GB. Separate cleanup pass.
• Swift Package Manager caches at ~/Library/Caches/org.swift.swiftpm. Smaller but real.
• Carthage (yes, still). ~/Library/Caches/org.carthage.CarthageKit.

These will land in a future Aguacatech build. Today, if you want to clean them, a one-liner rm -rf on those paths is safe, they all rebuild on next use.

One last thing

Path-based items in the Aguacatech Xcode Cleanup tab (DerivedData, Xcode Caches, Archives, iOS DeviceSupport) all move to Trash via FileManager.trashItem. Finder → Put Back works if you change your mind. Only the two Simulator categories, runtimes and devices, delete permanently, because they are managed by simctl rather than the filesystem. Aguacatech shows a pre-clean sheet that lists every runtime and device by name and version before committing.