Nettoyer Xcode sans perdre les artefacts de release

Xcode répartit le stockage entre sorties de compilation, index, archives, prise en charge des appareils, appareils simulateur et runtimes de plateforme téléchargeables. Une partie est reproductible ; d’autres éléments sont la seule copie d’une archive de release ou de ses dSYMs. L’approche sûre consiste à mesurer chaque catégorie, à la retirer via Xcode lorsque c’est possible, et à conserver les artefacts liés aux builds livrés.

Où partent les gigaoctets d’Xcode

Commencez par les deux racines principales au niveau utilisateur :

du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h

Les postes les plus lourds sont en général :

• DerivedData : produits de compilation, index et caches de modules, en général un dossier par projet. C’est reconstruisible, mais un effacement complet rend les indexations et builds suivants coûteux. Ciblez d’abord le projet obsolète.
• DeviceSupport : symboles et artefacts de prise en charge capturés pour les appareils physiques et les builds d’OS. Les anciennes entrées peuvent encore servir à la symbolication des plantages.
• Archives : builds enregistrés à chaque export ou livraison d’une app. Apple recommande de conserver l’archive de chaque build que vous distribuez, car ses binaires et les fichiers dSYM correspondants peuvent être nécessaires pour diagnostiquer des rapports de plantage ultérieurs. Les archives de builds qui n’ont jamais quitté votre Mac sont les candidats de nettoyage les plus sûrs.
• Appareils simulateur et runtimes de plateforme : les appareils se trouvent sous CoreSimulator, tandis que les runtimes téléchargeables sont gérés comme composants Xcode. Ce n’est pas un seul cache.

Nettoyer chaque catégorie en toute sécurité

Avant de déplacer DerivedData, arrêtez aussi les compilations et tests en ligne de commande, puis quittez Xcode.

DerivedData se nettoie de préférence par projet. Utilisez Xcode › Settings › Locations pour repérer son dossier, puis vérifiez que le code source, la chaîne d'outils et les dépendances nécessaires à une nouvelle compilation sont disponibles. Arrêtez les compilations en cours et quittez Xcode avant de déplacer le dossier obsolète vers la Corbeille. N’effacez tout que si un problème global d’index ou de compilation justifie ce travail de reconstruction.

Les appareils simulateur indisponibles disposent d’une commande dédiée. Sauvegardez d'abord leurs données de test encore utiles :

Arrêtez d’abord le simulateur et les tests associés. Cette commande supprime les données des appareils sans passer par la Corbeille.

xcrun simctl delete unavailable

Cela supprime les appareils dont les runtimes ne sont plus disponibles ; cela ne désinstalle pas les images de runtime elles-mêmes. Utilisez Xcode › Settings › Components pour examiner les plateformes et runtimes simulateur installés avec l'espace récupérable, puis retirez les runtimes que vous pouvez retélécharger. Le guide des composants Xcode d’Apple documente cette méthode. Utilisez Window › Devices and Simulators pour gérer les appareils.

Passez en revue les Archives dans Window › Organizer. Conservez l’archive et le dSYM de chaque build distribué, y compris les anciennes versions de production encore en service. Le guide des informations de débogage d’Apple indique que binaires et dSYMs ne fonctionnent ensemble que lorsque leurs UUID de build correspondent. DeviceSupport mérite aussi une revue sélective plutôt qu’un effacement massif.

Quittez Xcode avant de déplacer DerivedData pour éviter d’interrompre l’écriture des index et bases de build. Attendez-vous à ce que la prochaine ouverture et le prochain build réindexent, résolvent les dépendances et recréent les sorties ; la durée dépend du projet et de ce qui reste disponible.

Sous le capot : données reproductibles et artefacts à conserver

DerivedData est une sortie de compilation et d’index reproductible. Pour chaque projet, Xcode crée un dossier nommé avec un hachage du chemin du projet et le remplit d’objets compilés, de caches de modules, d’index et de produits de build dérivés du code source, des réglages, des toolchains et des dépendances. Supprimez-le et Xcode reconstruit ce qui reste disponible, ce qui peut prendre du temps et nécessiter un accès réseau. DeviceSupport est d’une autre nature : lorsque vous déboguez un appareil physique, Xcode capture des données de prise en charge et de symboles pour ce build d’OS. Les appareils simulateur et les images de runtime sont aussi des objets gérés distincts, et non de simples dossiers de cache. Les Archives sont l’ensemble qu’il vaut la peine de conserver sélectivement, car elles contiennent les dSYMs nécessaires pour symboliquer les rapports de plantage des builds App Store. Savoir ce qui est un cache reconstruisible et ce qui est un artefact capturé, c’est toute la ligne entre « sûr à effacer » et « à garder ».

Où une carte disque aide

Une carte disque comme la vue Analyser de Mole peut montrer si DerivedData, CoreSimulator ou Archives occupe le plus de place.

Mole peut aussi lister les runtimes de simulateur inutilisés depuis 60 jours qui remplissent ses conditions, les données DeviceSupport, les copies d’apps d’appareils et les enregistrements temporaires d’Instruments. Examinez-les séparément des Archives et des dSYM nécessaires aux versions publiées. Les runtimes sont retirés avec simctl d’Apple. Les vues Components, Devices et Organizer d’Xcode restent disponibles pour la gestion manuelle.

Un ordre d’opérations sûr

Quittez les builds en cours, mesurez Xcode et CoreSimulator séparément, retirez le DerivedData obsolète par projet, supprimez les appareils simulateur indisponibles, et désinstallez les runtimes inutilisés depuis Components. Passez en revue les Archives par rapport aux versions livrées et aux besoins de symbolication avant toute suppression. Rouvrez un projet important et lancez un build avant de vider la Corbeille.