"My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me." That line, from anthropics/claude-code Issue #18869, is the universal opening of a developer Mac disaster. The 472 GB culprit in that case was Claude Code, but on plenty of iOS dev machines the same shape of problem sits quietly under ~/Library/Developer/Xcode/Archives/. Archives never get cleaned, never get warned about, and never show up in the standard "storage full" advice. By the time you notice, the Xcode Archives folder is sitting on 40, 80, sometimes 150 GB of shipped builds you no longer need.
What is the Xcode Archives folder?
An Xcode archive is the output of Product > Archive in Xcode. It is not a build artifact in the DerivedData sense, it is a release-quality bundle Xcode produces so you can submit to the App Store, distribute ad hoc, or symbolicate crash reports later. The folder that holds all of them is one path:
~/Library/Developer/Xcode/Archives/
Inside, Xcode organizes archives by date. Each day you archive, you get a subfolder named YYYY-MM-DD, and inside each subfolder is one .xcarchive bundle per Product > Archive invocation.
# Quick layout check.
ls ~/Library/Developer/Xcode/Archives/
# Per-day breakdown to find the heaviest archive days.
du -sh ~/Library/Developer/Xcode/Archives/* 2>/dev/null | sort -h | tail -20
# Total size of the Xcode Archives folder.
du -sh ~/Library/Developer/Xcode/Archives
A .xcarchive is a macOS bundle, which means Finder renders it as a single file but it is actually a directory. Right-click any .xcarchive and pick Show Package Contents to see what is inside.
What does an .xcarchive actually contain?
Each archive bundles four things, and any one of them can be the reason the archive is huge.
| Subpath inside .xcarchive | What it is | Why it gets large |
|---|---|---|
Products/Applications/<App>.app |
The signed app bundle that ships to users | Embedded assets, ML models, on-device LLM weights |
dSYMs/*.dSYM |
Debug symbol bundles for every binary and framework | One dSYM per architecture per framework, Swift bloats these |
SCMBlueprint/ |
Build snapshot of source control state | Tiny but always present |
Info.plist |
Archive metadata: bundle ID, version, archive date | Tiny |
BCSymbolMaps/ |
Bitcode symbol maps if you shipped with Bitcode | Mostly obsolete since Xcode 14 dropped Bitcode |
The first two are the size drivers. The app binary itself rarely shocks anyone, but the dSYMs/ directory routinely lands at 500 MB to 1.5 GB on Swift codebases with multiple Swift packages, embedded frameworks, and a couple of third-party SDKs. Multiply that by one archive per TestFlight build, multiplied by the apps you ship across the year, and the Xcode Archives folder fills steadily without ever raising a flag.
How is the Xcode Archives folder different from DerivedData?
This is the question that matters for safety. People conflate the two because both live under ~/Library/Developer/Xcode/ and both grow forever, but they have opposite risk profiles.
| Folder | Path | What it holds | What Xcode does on delete |
|---|---|---|---|
| DerivedData | ~/Library/Developer/Xcode/DerivedData/ |
Per-project build cache, module cache, indexes | Rebuilds on next build, costs a clean compile |
| Archives | ~/Library/Developer/Xcode/Archives/ |
Shipped-build output, dSYMs, bundle metadata | Does not rebuild, the archive is gone |
DerivedData is the right thing to clear when builds are misbehaving. The cost is a recompile. The Xcode Archives folder is the wrong thing to clear without thinking, because the cost is losing the exact build that shipped. If you want the full DerivedData walkthrough, see How to safely delete Xcode DerivedData and Is deleting DerivedData safe?.
Is it safe to delete the Xcode Archives folder?
Yes, with three explicit consequences. You will lose, for every deleted archive:
- The ability to re-upload that build to App Store Connect from Organizer.
- The ability to re-export an ad hoc, enterprise, or Developer ID
.ipaof that exact build. - Local symbolication of crash reports for that build, unless the dSYMs are already uploaded to App Store Connect or your crash service.
For older archives you have already shipped and replaced, all three consequences are fine. For the current production build of an app you actively support, none of them are. The Xcode Archives folder is one of the rare developer caches where "delete everything" is the wrong default.
Per Apple's own Xcode Help on managing archives, the Organizer is the supported way to delete archives because it cleans up its internal bookkeeping at the same time. The manual Finder route works, but Xcode caches a list of known archives and can show ghost entries until you restart it.
How do you delete old Xcode archives the safe way?
The cleanest path is the Organizer. Three clicks per archive, fully reversible until you empty Trash.
- Open Xcode. Pick
Window > Organizerin the menu bar. - Click the
Archivestab. Pick an app in the left sidebar. - Right-click any obsolete archive. Pick
Delete. The underlying.xcarchivemoves to Trash.
If you prefer the terminal, the safer pattern is move-to-Trash rather than rm -rf. The trick is that the macOS Trash is per-volume, so use the actual path under your home folder:
# Move archives older than 180 days to Trash, leaving recent ones alone.
find ~/Library/Developer/Xcode/Archives -name "*.xcarchive" -mtime +180 \
-exec mv {} ~/.Trash/ \;
# Verify nothing recent went with them.
ls ~/Library/Developer/Xcode/Archives/ | tail
This pattern is the same review-first model documented in Move to Trash vs rm -rf for developer Mac cleanup. The seven-day Trash window is your recovery if you regret a delete.
What you should never do is rm -rf ~/Library/Developer/Xcode/Archives. The space goes back to the filesystem immediately, the Organizer still believes the archives exist for a session, and there is no recovery if you needed one of those builds for a hotfix re-export. This is the same anti-pattern that caused the Claude Code cascade-failure issue #24207, where unbounded growth led a user to nuke a folder and lose auth alongside the bloat.
When should you keep an Xcode archive instead of deleting it?
Keep an archive if any of the following is still true.
- The build is the current App Store production build for an app you support.
- The build is the current TestFlight beta and you might need to re-upload metadata.
- You have not yet uploaded the dSYMs for that build to App Store Connect or your crash service (Crashlytics, Sentry, Bugsnag).
- You ship enterprise or ad hoc and might re-export an
.ipafor the same build. - You are mid-incident on a crash investigation that needs local symbolication.
Drop everything else. A reasonable rule of thumb: keep the two most recent App Store builds per app and the most recent TestFlight build per app. Everything else in the Xcode Archives folder is reclaimable.
How much disk space does the Xcode Archives folder typically eat?
Real numbers from indie iOS dev Macs, gathered while researching the wider 16 month AI tools disk footprint audit and the 180 GB System Data breakdown:
| Profile | Archive cadence | Folder size |
|---|---|---|
| Indie, 1 app, monthly releases | 1 per month | 3 to 8 GB after 2 years |
| Indie, 3 apps, weekly TestFlight | 3 per week | 40 to 80 GB after 1 year |
| Agency, 8 client apps | Daily across team | 120 to 250 GB after 1 year |
The pattern is the same as the brtkwr writeup on freeing 200 GB on a full disk: individual folders rarely look catastrophic, but the cumulative footprint across years of normal use is where the gigabytes hide. The Xcode Archives folder is one of the most common offenders no consumer cleaner ever touches.
How do you cap Xcode Archives growth so this stops being a yearly chore?
Xcode has no built-in retention setting for the Archives folder. There is no equivalent of Claude's cleanupPeriodDays. You have three practical options.
- Calendar-based sweep. Once a quarter, open Organizer and delete archives older than 90 days for apps no longer under active maintenance.
- Scripted prune. A
find ... -mtime +180 -exec mv {} ~/.Trash/ \;cron run monthly keeps the folder under a ceiling. Skip this if you ship to App Store irregularly, because "old" is a moving target. - Tool-based audit. CleanMyDev groups archives by app and shows size per archive, last access date, and whether dSYMs were uploaded. Pick the obsolete ones, move to Trash, done in under a minute.
The right answer is whichever one you will actually do. The Xcode Archives folder is not dangerous to clean, it is just rarely cleaned because no part of macOS or Xcode reminds you.
Why CleanMyDev for Xcode archives cleanup?
You can run find and the Organizer all day. The reason the Xcode Archives folder fills anyway is that it never makes it onto a checklist. CleanMyDev keeps archives on the same scan as DerivedData, simulators, device support, and the rest of the Xcode footprint, grouped by app, sorted by date and size, with Move to Trash by default. No rm -rf, no scareware modal, no monthly subscription. The pitch is one paragraph: receipts before deletion, lifetime license, built for iOS devs who have lost a Saturday to disk space at least once. If that matches you, CleanMyDev is $9.99 once and ships with the Xcode Archives scanner preconfigured.