Most Xcode archives are safe to delete, and a few are worth more than their size suggests. Each archive is a build you exported or uploaded, and its dSYMs hold the symbols for that exact binary. Delete the archives of builds nobody runs. Keep the ones behind every version that is still installed somewhere, unless your crash reporter or App Store Connect already holds their symbols.
Main rule: keep the archive of every build people still run, and delete the rest from Xcode's Organizer instead of the terminal.
Quick answer
- Measure the folder with
du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail. - Open Xcode, then Window, Organizer, Archives.
- Keep the latest shipped build of each app and any older build your users still run.
- Check that your crash reporter or App Store Connect has the symbols of the builds you plan to delete.
- Delete test exports, superseded uploads and expired TestFlight builds.
- Move archives you are unsure about to an external drive instead of deleting them.
What is inside an Xcode archive
Xcode writes an archive every time you run Product, Archive, or xcodebuild archive. It files them in ~/Library/Developer/Xcode/Archives, one folder per day, and names each bundle after the scheme and the time, for example MyApp 21.09.2026, 14.13.xcarchive.
| Item inside the .xcarchive | What it holds |
|---|---|
dSYMs | debug symbols for the app and its embedded frameworks |
Products | the built app |
Info.plist | version, build number and creation date |
Signatures | signing metadata |
I measured the folder on my Mac on 25 October 2026, with macOS 27.0.1 and Xcode 27.1. It held 3.9 GB: 35 archives of 11 apps, all made between 16 August and 24 October. A typical archive took about 165 MB and the largest 407 MB. In one StorageRadar archive the dSYMs folder took 84 MB and the app itself 39 MB, so the symbols outweighed the product.
Why the dSYMs matter
A crash report from a release build lists memory addresses, not function names. Xcode and crash reporting services translate those addresses with the dSYM whose UUID matches the crashed binary. You can check which build a dSYM belongs to:
dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYMArchiving the same commit again gives you a new binary, and in most setups a new UUID. That is why a deleted archive cannot be recreated for crash reporting purposes: the reports of the old build need the old dSYM.
Two places can hold a second copy:
- App Store Connect. When you distribute with the option to upload your app’s symbols, Apple symbolicates the crash reports you see in Xcode’s Organizer.
- Your crash reporter. Services such as Sentry and Firebase Crashlytics upload dSYMs during the build when the project is set up for it, and keep them on their side.
If neither applies to a build, its archive is the only copy of its symbols.
Which archives you can delete
Delete without much thought:
- archives of local or Ad Hoc exports you made to test something;
- builds you uploaded and then replaced with a newer build of the same version;
- TestFlight builds older than 90 days, since TestFlight expires builds after that.
Keep:
- the archive of the build that is live on the App Store, and of the previous one or two if your users update slowly;
- archives of builds you distribute outside the App Store, because you may need to export or notarize that exact build again;
- anything without a second copy of its symbols, while crash reports for it still arrive.
How to delete archives
In Xcode. Open Window, Organizer, and choose Archives. Pick an app on the left, select one or more archives, and delete them from the context menu. Organizer reads the archives folder, so this removes the bundles from disk.
In Finder. Run open ~/Library/Developer/Xcode/Archives and move whole date folders to the Trash. Organizer stops listing what you moved.
To an external drive. Copy old date folders to an external disk, then delete them from the Mac. Xcode does not need archives on the internal disk to keep working, and you can copy one back if a crash report for an old build ever shows up.
You can also point Xcode at a different archives folder in Xcode Settings, Locations.
Archives versus DerivedData
These two folders sit side by side in ~/Library/Developer/Xcode and behave in opposite ways. DerivedData is build output that Xcode recreates on the next build, so deleting it costs you one slower build. Archives are records of builds you shipped, and nothing recreates them. Clean DerivedData freely and review Archives one by one.
Bottom line
Deleting Xcode archives is safe for builds nobody runs and costly for builds people still use. Measure the folder, open Organizer, keep the archive behind each live version, and check where the symbols of older builds live before you delete them. When in doubt, an external drive costs less than a crash report you cannot read.
Frequently asked questions
Is it safe to delete Xcode archives?
Yes for archives of builds that nobody runs anymore: test exports, superseded uploads, expired TestFlight builds. Keep the archive of every build that is still installed somewhere, because its dSYMs turn that build's crash reports into readable stack traces.
Will deleting an Xcode archive remove my app from the App Store?
No. App Store Connect keeps the build you uploaded. The archive is your local copy of that build and its debug symbols.
Can I rebuild a deleted archive?
You can archive the same commit again, but in most setups the new binary gets a new UUID. The old crash reports need the dSYM with the old UUID, so they stay unsymbolicated unless that dSYM exists somewhere else, such as App Store Connect or your crash reporter.
Where does Xcode store archives on Mac?
In ~/Library/Developer/Xcode/Archives, in one folder per day named like 2026-10-24. Xcode Settings, Locations, shows the path. Each archive is an .xcarchive bundle with the app, its dSYMs and an Info.plist.
How much space do Xcode archives take?
It depends on the app. On my Mac a typical archive took about 165 MB and the largest 407 MB. Thirty-five of them added up to 3.9 GB in ten weeks, because every upload leaves one behind.