Peut-on supprimer les archives Xcode sans perdre les dSYM ?

En quoi les archives Xcode diffèrent de DerivedData

Product > Archive crée un build distribuable conservé dans un paquet .xcarchive. Par défaut, Xcode range ces paquets dans ~/Library/Developer/Xcode/Archives, classés dans des dossiers datés, et les affiche dans l’Organizer. Une app maintenue longtemps peut en accumuler beaucoup : versions candidates, envois TestFlight et versions de production.

Contrairement à DerivedData, une archive n’est pas un simple cache de performance. Elle peut contenir le binaire exact de l’app, les métadonnées du build et les fichiers dSYM produits pour ce build. Apple précise qu’un dSYM est lié à un binaire par son UUID : recompiler plus tard le même code ne recrée pas un fichier de symboles interchangeable, car le nouveau binaire reçoit d’autres identifiants.

Le coût de suppression n’est donc pas le même. DerivedData se régénère au prix d’un premier build plus lent. Une archive supprimée peut être impossible à reconstruire à l’identique : si un rapport de plantage arrive pour ce binaire et que vous n’avez plus ses symboles, les piles d’appels restent des adresses mémoire au lieu de noms de fonctions et d’emplacements dans le code.

Établir la liste à conserver avant la liste à supprimer

Commencez dans Xcode plutôt que dans le Finder : ouvrez Window > Organizer, choisissez Archives, sélectionnez l’app concernée et vérifiez la version, le numéro de build, la date de création et l’état de distribution de chaque entrée. L’Organizer donne à une archive un contexte qu’un nom de dossier daté ne donne pas.

Gardez l’archive de chaque version encore proposée aux utilisateurs, de chaque build TestFlight actif, de tout build Enterprise ou Ad Hoc encore installé et de toute version dont vous pourriez encore analyser les plantages. Gardez aussi une version de référence si votre équipe s’appuie sur son binaire exporté, son historique de notarisation ou ses preuves de signature.

Un envoi réussi ne rend pas votre archive locale jetable. Selon la plateforme et les réglages d’envoi, Apple peut recevoir les symboles, mais sa documentation sur le débogage recommande toujours de conserver l’archive de chaque build distribué. Votre archive locale reste aussi le lien le plus clair entre binaire, dSYM, version, numéro de build et export.

1. Ouvrez Window > Organizer et sélectionnez Archives.
2. Choisissez l’app, puis notez la version et le numéro de build de chaque build de production, TestFlight, Enterprise ou Ad Hoc encore utilisé.
3. Vérifiez que les symboles nécessaires ont été envoyés lorsque c’est possible, et copiez les archives irremplaçables vers un stockage sauvegardé si votre politique de conservation l’exige.
4. Ne marquez comme candidats à la suppression que les versions candidates remplacées, les builds internes abandonnés et les versions retirées sorties de votre période d’analyse des plantages.
5. Supprimez les candidats un par un depuis l’Organizer, puis vérifiez que les entrées attendues sont toujours là avant de vider la Corbeille.

Une date ne suffit pas à fonder une politique de conservation : un ancien binaire de production peut rester installé sur les appareils des clients longtemps après la sortie d’une nouvelle version.

Mesurer le dossier des archives sans le modifier

Si votre objectif est de gagner de l’espace, mesurez d’abord. Dans le Finder, appuyez sur Commande + Maj + G et ouvrez ~/Library/Developer/Xcode/Archives. Passez en présentation par liste, activez « Calculer toutes les tailles » dans les options de présentation et triez par taille. Cette opération est en lecture seule et fait ressortir les archives anormalement volumineuses.

Dans le Terminal, du -sh ~/Library/Developer/Xcode/Archives donne le total. Pour examiner les dossiers datés, exécutez du -sh ~/Library/Developer/Xcode/Archives/* et triez vous-même le résultat. Ces commandes mesurent les fichiers ; elles ne suppriment rien.

Une archive est un paquet : le Finder la présente normalement comme un seul élément. Pour comprendre sa taille, vous pouvez faire un clic droit sur une copie et choisir Afficher le contenu du paquet, mais ne modifiez pas les fichiers du paquet d’origine. En retirer certains peut laisser une archive apparemment présente, mais qui ne s’exporte ou ne se symbolise plus correctement.

La méthode de suppression la plus sûre

L’Organizer est la voie à privilégier, car l’identité de l’app, la version et le numéro de build restent visibles au moment d’agir. Sélectionnez une archive dont le retrait est confirmé et utilisez Delete. Xcode supprime le paquet de l’archive ; selon les versions de macOS et de Xcode, une confirmation peut vous être demandée.

Le Finder est utile quand l’Organizer ne parvient pas à ouvrir un paquet ancien ou endommagé. Ouvrez le dossier Archives, identifiez le .xcarchive exact en comparant les métadonnées de son Info.plist à votre inventaire, et placez ce seul paquet dans la Corbeille. Ne supprimez pas tout un dossier daté simplement parce que son nom est ancien.

Ne videz pas la Corbeille tout de suite : rouvrez d’abord l’Organizer, exportez tout build dont votre flux de travail a encore besoin et, si les symboles sont critiques pour votre activité, symbolisez un plantage représentatif. Le passage par la Corbeille offre un court délai de récupération ; une suppression définitive dans le Terminal supprime cette marge de sécurité sans rendre le nettoyage plus juste.

Une conservation qui ne grossit pas indéfiniment

Une politique pratique repose sur l’état de publication, pas sur un âge arbitraire des fichiers. Gardez tous les builds actuellement distribués ; gardez les builds de production récemment remplacés tant que vous acceptez encore des rapports de plantage ; conservez les builds Enterprise jusqu’à l’expiration de leurs installations ; et gardez les versions jalons exigées par vos règles juridiques, de support ou de gestion des incidents.

En équipe, inscrivez la conservation dans la checklist de publication : où sont stockées les archives, si les dSYM ont été envoyés, qui peut les récupérer et à partir de quand un build peut être supprimé. Si les archives passent sur un stockage externe ou dans le cloud, testez réellement la restauration au lieu de supposer qu’une copie du paquet est utilisable.

Faites le point après chaque cycle de publication majeur : une revue trimestrielle de dix minutes est plus sûre qu’une suppression paniquée quand le disque de démarrage est plein. Pour récupérer vite de l’espace à faible risque, commencez par DerivedData et les données obsolètes du simulateur ; n’examinez les archives qu’une fois que le Mac dispose d’assez de marge pour décider sereinement.

Comment AskClean traite les archives

AskClean évite délibérément de ranger les archives Xcode parmi les caches régénérables ordinaires. Il analyse le dossier Archives, liste chaque paquet .xcarchive séparément et lui associe un avertissement de coût irréversible : vous examinez les anciens builds sans devoir supprimer tout le dossier d’un coup.

La décision vous appartient. AskClean montre quelle archive occupe de l’espace et, avec Pro, supprime définitivement l’élément que vous confirmez ; mais il ne connaît pas votre période de support en production et ne peut pas recréer un dSYM manquant. Cette limite est voulue : un outil de stockage doit révéler les artefacts de publication, pas décider en silence qu’ils ne comptent plus.

Régénérable ou irremplaçable : où s’arrête la suppression

Classez chaque artefact selon son coût de récupération avant de regarder son âge ou sa taille.

FAQ