La plupart des archives Xcode se suppriment sans risque, et quelques-unes valent plus que leur taille ne le laisse penser. Chaque archive correspond à un build que tu as exporté ou envoyé, et ses dSYM contiennent les symboles de ce binaire précis. Supprime les archives des builds que plus personne ne fait tourner. Garde celles de chaque version encore installée quelque part, sauf si ton service de rapports de plantage ou App Store Connect possède déjà leurs symboles.
Règle principale : garde l'archive de chaque build que des gens utilisent encore, et supprime le reste depuis l'Organizer de Xcode plutôt que depuis le terminal.
Réponse rapide
- Mesure le dossier avec
du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail. - Ouvre Xcode, puis Window, Organizer, Archives.
- Garde le dernier build publié de chaque app et tout build plus ancien que tes utilisateurs font encore tourner.
- Vérifie que ton service de rapports de plantage ou App Store Connect possède les symboles des builds que tu comptes supprimer.
- Supprime les exports de test, les envois remplacés et les builds TestFlight expirés.
- Déplace sur un disque externe les archives dont tu n'es pas sûr, au lieu de les supprimer.
Ce que contient une archive Xcode
Xcode écrit une archive chaque fois que tu lances Product, Archive ou xcodebuild archive. Il les range dans ~/Library/Developer/Xcode/Archives, un dossier par jour, et nomme chaque bundle d’après le schéma et l’heure, par exemple MyApp 21.09.2026, 14.13.xcarchive.
| Élément dans le .xcarchive | Ce qu’il contient |
|---|---|
dSYMs | les symboles de débogage de l’app et de ses frameworks intégrés |
Products | l’app compilée |
Info.plist | la version, le numéro de build et la date de création |
Signatures | les métadonnées de signature |
J’ai mesuré le dossier sur mon Mac le 25 octobre 2026, sous macOS 27.0.1 avec Xcode 27.1. Il pesait 3,9 Go : 35 archives de 11 apps, toutes créées entre le 16 août et le 24 octobre. Une archive typique prenait environ 165 Mo et la plus grosse 407 Mo. Dans une archive de StorageRadar, le dossier dSYMs prenait 84 Mo et l’app elle-même 39 Mo : les symboles pesaient plus lourd que le produit.
Pourquoi les dSYM comptent
Un rapport de plantage issu d’un build de release liste des adresses mémoire, pas des noms de fonctions. Xcode et les services de rapports de plantage traduisent ces adresses avec le dSYM dont l’UUID correspond au binaire qui a planté. Tu peux vérifier à quel build appartient un dSYM :
dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYMArchiver à nouveau le même commit te donne un nouveau binaire et, dans la plupart des configurations, un nouvel UUID. C’est pour cela qu’une archive supprimée ne peut pas être recréée pour les rapports de plantage : les rapports de l’ancien build ont besoin de l’ancien dSYM.
Deux endroits peuvent en garder une seconde copie :
- App Store Connect. Quand tu distribues avec l’option d’envoi des symboles de ton app, Apple résout les symboles des rapports de plantage que tu vois dans l’Organizer de Xcode.
- Ton service de rapports de plantage. Des services comme Sentry et Firebase Crashlytics envoient les dSYM pendant le build quand le projet est configuré pour cela, et les conservent de leur côté.
Si aucun des deux ne s’applique à un build, son archive est la seule copie de ses symboles.
Quelles archives supprimer
Supprime sans trop réfléchir :
- les archives d’exports locaux ou Ad Hoc faits pour tester quelque chose ;
- les builds envoyés puis remplacés par un build plus récent de la même version ;
- les builds TestFlight de plus de 90 jours, puisque TestFlight fait expirer les builds après ce délai.
Garde :
- l’archive du build en ligne sur l’App Store, et celles du ou des deux précédents si tes utilisateurs mettent à jour lentement ;
- les archives des builds que tu distribues hors de l’App Store, car tu pourrais avoir besoin d’exporter ou de notariser à nouveau ce build précis ;
- tout ce qui n’a pas de seconde copie de ses symboles, tant que des rapports de plantage arrivent encore pour lui.
Comment supprimer des archives
Dans Xcode. Ouvre Window, Organizer, puis choisis Archives. Sélectionne une app à gauche, choisis une ou plusieurs archives et supprime-les depuis le menu contextuel. L’Organizer lit le dossier des archives, donc cette action retire les bundles du disque.
Dans le Finder. Lance open ~/Library/Developer/Xcode/Archives et mets des dossiers de date entiers à la Corbeille. L’Organizer cesse d’afficher ce que tu as déplacé.
Vers un disque externe. Copie les anciens dossiers de date sur un disque externe, puis supprime-les du Mac. Xcode n’a pas besoin des archives sur le disque interne pour continuer à fonctionner, et tu peux en recopier une si un rapport de plantage arrive un jour pour un ancien build.
Tu peux aussi indiquer à Xcode un autre dossier d’archives, dans Xcode, Settings, Locations.
Archives et DerivedData
Ces deux dossiers sont voisins dans ~/Library/Developer/Xcode et se comportent de façon opposée. DerivedData est une sortie de build que Xcode recrée au build suivant : le supprimer te coûte un build plus lent. Les archives sont la trace des builds que tu as livrés, et rien ne les recrée. Nettoie DerivedData librement et passe les archives en revue une par une.
En résumé
Supprimer des archives Xcode ne pose aucun problème pour les builds que personne ne fait tourner, et coûte cher pour ceux que des gens utilisent encore. Mesure le dossier, ouvre l’Organizer, garde l’archive de chaque version en ligne, et vérifie où se trouvent les symboles des anciens builds avant de les supprimer. Dans le doute, un disque externe coûte moins cher qu’un rapport de plantage illisible.
Questions fréquemment posées
Peut-on supprimer les archives Xcode sans risque ?
Oui pour les archives de builds que plus personne ne fait tourner : exports de test, envois remplacés, builds TestFlight expirés. Garde l'archive de chaque build encore installé quelque part, car ses dSYM transforment les rapports de plantage de ce build en piles d'appels lisibles.
Supprimer une archive Xcode retire-t-il mon app de l'App Store ?
Non. App Store Connect garde le build que tu as envoyé. L'archive est ta copie locale de ce build et de ses symboles de débogage.
Puis-je reconstruire une archive supprimée ?
Tu peux archiver à nouveau le même commit, mais dans la plupart des configurations le nouveau binaire reçoit un nouvel UUID. Les anciens rapports de plantage ont besoin du dSYM à l'ancien UUID, donc leurs symboles restent non résolus, sauf si ce dSYM existe ailleurs, par exemple dans App Store Connect ou chez ton service de rapports de plantage.
Où Xcode stocke-t-il les archives sur Mac ?
Dans ~/Library/Developer/Xcode/Archives, avec un dossier par jour nommé comme 2026-10-24. Le chemin apparaît dans Xcode, Settings, Locations. Chaque archive est un bundle .xcarchive qui contient l'app, ses dSYM et un Info.plist.
Combien d'espace prennent les archives Xcode ?
Cela dépend de l'app. Sur mon Mac, une archive typique prenait environ 165 Mo et la plus grosse 407 Mo. Trente-cinq archives atteignaient 3,9 Go en dix semaines, parce que chaque envoi en laisse une derrière lui.