# Nettoyer Xcode sans perdre les artefacts de release > Séparez DerivedData, appareils simulateur, runtimes, DeviceSupport et archives de release avant de libérer l’espace Xcode. Published: 2026-07-12 | Updated: 2026-08-08 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](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) 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](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) 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 ».
Le dossier développeur Xcode divisé en caches reconstruisibles, DerivedData et cache de modules, et artefacts capturés, DeviceSupport, Archives et simulateurs
L’empreinte d’Xcode se partage entre sorties reproductibles et artefacts capturés. Les Archives et dSYMs peuvent rester opérationnellement importants longtemps après la livraison d’un build.
## Où une carte disque aide Une carte disque comme la vue Analyze de [Mole](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/fr/blog/how-to-clean-up-xcode-mac Blog index for agents: https://mole.fit/fr/blog/llms.txt Site index for agents: https://mole.fit/llms.txt