Is It Safe to Delete Xcode Archives? Yes, but Keep the Ones That Matter

Yes, but read this firstDiskmack safety tier: Caution

~/Library/Developer/Xcode/Archives

Yes, you can delete old Xcode archives, and for most people that reclaims real space with no downside. The catch: each archive contains the debug symbols (dSYMs) you need to make sense of crash reports from that exact build. Keep the archives for app versions your users are still running, and clear the rest without guilt.

What it is

Every time you run Product > Archive in Xcode, it writes a .xcarchive bundle to ~/Library/Developer/Xcode/Archives, sorted into folders by date. Each archive holds the compiled app exactly as you built it, plus its dSYM files. A dSYM is the map that turns the raw memory addresses in a crash report back into readable function names and line numbers. Without it, a crash log from that build is a wall of hex.

The folder grows because Xcode never cleans it. Archives from test flights you abandoned, builds that were rejected, and versions you shipped three years ago all sit there forever. A single archive for a mid-sized app often runs from tens to hundreds of megabytes, and if you have been shipping for a few years the folder can quietly reach several gigabytes, sometimes tens of gigabytes on apps with large assets or frequent releases.

Is it safe to delete?

Deleting an archive never breaks Xcode, your project, or your ability to build and submit new versions. Xcode recreates nothing here; the folder just holds historical output. The only thing you lose is the ability to symbolicate crash reports for that specific build. If a version is still live on the App Store or installed on testers' devices, and you have not uploaded its dSYMs to App Store Connect or a crash reporting service like Sentry or Crashlytics, deleting its archive means future crash reports from it stay unreadable. Archives do not come back once deleted.

So the rule is simple: keep the archive for every version still in the wild, plus the last build you submitted, and delete everything older. If your app uploads dSYMs at submission time (the default when you distribute through App Store Connect with symbols included), even the shipped versions are covered server-side and the local copies are redundant. Hobby projects you never shipped anywhere can be cleared completely. Diskmack identifies this folder automatically and helps you clean it the safe way.

How to check its size

In Finder: In Finder, choose Go > Go to Folder (or press Cmd+Shift+G), paste ~/Library/Developer/Xcode and press Return. Select the Archives folder, then press Cmd+I to see its total size. Open it and archives are grouped into dated folders, so sorting by name shows you the oldest at a glance.

In Terminal:

du -sh ~/Library/Developer/Xcode/Archives

The ~ expands to your home folder automatically. Add a trailing /* to see the size of each dated subfolder: du -sh ~/Library/Developer/Xcode/Archives/*.

How to clean it

Open Xcode, then choose Window > Organizer and click the Archives tab. This shows every archive with its app name, version, and date, which is much clearer than raw folder names.
Note which versions of your app are still live on the App Store or in TestFlight. Those archives stay.
For anything you plan to delete but might want symbols from later, confirm the dSYMs were uploaded to App Store Connect or your crash reporter, or right-click the archive, choose Show in Finder, and copy the dSYMs folder from inside the .xcarchive to a backup drive first.
In Organizer, select the archives you no longer need and press Delete, or do it in Finder: Go > Go to Folder, paste ~/Library/Developer/Xcode/Archives, and drag individual .xcarchive files (or whole dated folders, if nothing in them is worth keeping) to the Trash.
Empty the Trash when you are sure.

There is no built-in Xcode command that prunes old archives for you. One difference between the two routes: Organizer's Delete removes the archive immediately and cannot be undone, while Finder puts it in the Trash so you can change your mind until you empty it.

Will it come back?

Only if you create it. Nothing regenerates on its own: deleted archives are gone for good, and Xcode adds a new one only when you run Product > Archive again. You get one new archive every time you run Product > Archive, and most releases take a few tries (rejected builds, TestFlight rounds), so the folder grows faster than your version history suggests. A light cleanup once or twice a year keeps it from creeping back into multi-gigabyte territory.

Common questions

Do I need old archives to submit an update to the App Store?

No. Each submission uses a fresh archive you create at release time. Old archives play no part in building, signing, or uploading new versions.

What exactly is a dSYM and when would I miss it?

A dSYM maps the memory addresses in a crash report back to your function names and line numbers. You miss it the day a user reports a crash on an old version and the log is unreadable. If your dSYMs were uploaded to App Store Connect or a crash reporting service, the local copy in the archive is a backup, not the only copy.

Can I move archives to an external drive instead of deleting them?

Yes. Each .xcarchive is a self-contained bundle, so you can copy the dated folders anywhere and delete the originals. Xcode's Organizer only lists archives in the default folder, but a moved archive still works: double-click it or put it back and Organizer picks it up again.

I deleted the whole Archives folder. Did I break anything?

No. Xcode recreates the folder the next time you archive a build. The only loss is the historical builds and their debug symbols, which cannot be regenerated for those exact binaries.