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é

DerivedData se traite au mieux par projet. Quittez Xcode, utilisez Xcode > Settings > Locations pour afficher Derived Data, identifiez le dossier du projet obsolète, puis déplacez-le vers la Corbeille. N’effacez tout que si un problème global d’index ou de build justifie le coût de reconstruction.

Les appareils simulateur indisponibles disposent d’une commande dédiée :

xcrun simctl delete unavailable

Cela supprime les enregistrements d’appareils dont les runtimes ne sont plus disponibles ; cela n’installe pas les images de runtime elles-mêmes. Utilisez Xcode > Settings > Components pour inspecter les plateformes et runtimes simulateur installés avec les tailles récupérables, puis retirez les runtimes que vous pouvez retélécharger. Le guide des composants Xcode d’Apple documente le même chemin de suppression gérée. Utilisez Window > Devices and Simulators pour les enregistrements d’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 : pourquoi DerivedData est sûr et DeviceSupport n’est pas la même chose

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 Analyze de Mole peut indiquer si DerivedData, CoreSimulator ou Archives est la réelle source de pression. Les vues Components, Devices et Organizer d’Xcode doivent effectuer la suppression, car elles comprennent les runtimes, les appareils et les artefacts de release.

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.