Every time you archive an app in Xcode — for TestFlight, the App Store, or ad-hoc distribution — Xcode keeps a permanent copy. Forever, by default. If you've shipped a few dozen builds over a couple of years, that "forever" adds up to a folder full of old releases you will almost certainly never open again, sitting quietly and taking up real space.

What an archive actually is

Each archive is a .xcarchive bundle, and Xcode stores them at ~/Library/Developer/Xcode/Archives/, organised into subfolders by date. Inside a single .xcarchive, you'll find:

  • Products/ — the actual compiled application or app bundle for that specific archived build, ready for export or upload.
  • dSYMs/ — debug symbol files, which map crash addresses in a compiled binary back to human-readable file names and line numbers. Every archive you upload to App Store Connect needs its matching dSYM if you ever want to symbolicate a crash report that came in against that specific build.
  • Metadata — an Info.plist recording the archive's date, associated scheme, and build settings context, which is what lets Xcode Organizer show you a readable list rather than a folder of opaque hashes.

The Products portion — the actual compiled binary — is usually the larger of the two, especially for apps with substantial asset catalogs or embedded frameworks, though both scale with the size of your app.

Why the folder grows the way it does

Xcode does not offer any automatic expiry for archives. Every archive you create through Product → Archive stays in this folder indefinitely unless you delete it yourself. A team that ships a build to TestFlight for internal testing several times a week can accumulate hundreds of archives over a year or two, each one a full snapshot of a compiled app plus its debug symbols.

For a moderately complex app — anything with more than a trivial number of screens, assets, and third-party frameworks — individual archives commonly run from a few hundred megabytes to a couple of gigabytes each. Multiply that by months of frequent releases and the Archives folder becomes one of the larger, less obvious consumers of space on a mobile developer's Mac.

Using Xcode Organizer instead of Finder

The safest way to manage archives is through Xcode itself: Window → Organizer, then the Archives tab. This gives you the same list Finder would show, but with useful context — the app name, version, build number, and the date it was archived — making it much easier to tell which ones you actually still need.

From here you can select one or more old archives and delete them directly, which removes the corresponding .xcarchive bundle from ~/Library/Developer/Xcode/Archives/. This is preferable to deleting the folders manually in Finder mainly because it's harder to accidentally delete an archive you're currently working with, since Organizer clearly shows what's selected before you confirm.

What you can safely delete, and what you should think twice about

A reasonable rule most iOS teams settle on: keep the archive for every version currently live or recently live in the App Store or an active TestFlight track, and for any version you might still need to investigate a crash report against. Everything older than that — internal test builds from six months ago that were superseded days later, or archives for versions no user is running any more — is safe to delete.

The one thing worth pausing on before bulk-deleting is the dSYM. If a crash report ever comes in for an old build — which does happen, since some users delay updates for a long time — you need that build's dSYM to make the crash log readable. If your CI pipeline or a service like a crash-reporting tool already has a copy of the dSYM uploaded and indexed independently of Xcode's local archive, deleting the local .xcarchive is low-risk. If dSYMs only exist inside these local archives and nowhere else, consider extracting and archiving the dSYMs/ folder separately (a much smaller amount of data than the full archive) before deleting the rest.

Exporting just the dSYM before deleting the rest

If you want to keep crash symbolication ability without keeping the full multi-gigabyte archive, you can copy just the debug symbols out first:

cp -R ~/Library/Developer/Xcode/Archives/2026-03-15/MyApp\ 2026-03-15\ 10.30.xcarchive/dSYMs ~/Archived-dSYMs/MyApp-1.4.2/

Adjust the path for your archive's actual name and date. This gives you a much smaller, dedicated store of debug symbols you can keep indefinitely, separate from the full product bundles you're deleting.

Archives created by CI or fastlane land in the same place

If your team uses fastlane, xcodebuild archive directly, or another CI pipeline to produce builds, be aware that those archives typically get written to a custom output path specified in the build script, not automatically into ~/Library/Developer/Xcode/Archives the way a manual Archive from within Xcode does — unless the script explicitly targets that default location. This means a Mac used as a CI build agent can have a very different archive accumulation pattern from a developer's personal machine: potentially far more archives, generated far more frequently, sitting in whatever directory the pipeline was configured to use, easily overlooked because it isn't the folder Xcode's own Organizer shows by default.

If you're auditing disk usage on a CI Mac specifically, check the build script's configured output directory in addition to the default Archives path — both can independently accumulate to a meaningful size, and Organizer will only ever show you the ones written to its default location.

A practical routine

  1. Open Xcode → Organizer → Archives and sort by date.
  2. Identify which app versions are still live, in active testing, or otherwise still relevant.
  3. For everything clearly obsolete, extract the dSYMs folder first if you don't have symbols stored elsewhere.
  4. Delete the obsolete archives directly from Organizer.
  5. Check du -sh ~/Library/Developer/Xcode/Archives afterward to confirm the recovered space.

Doing this every few months, rather than letting years accumulate before the first cleanup, keeps the decision simple — recent archives are obviously still relevant, and the ambiguous middle ground never has time to build up.

Where VolumeLens fits in

Old Xcode archives are a particularly easy category to forget about, because Organizer is the only place that presents them meaningfully — Finder just shows a folder of dated subfolders with cryptic bundle contents. VolumeLens surfaces the whole Archives folder sized honestly in a normal scan, so you know it's worth a trip to Organizer before you go looking. Explore what else Insights catches across a typical iOS developer's Mac.