Supprimer DerivedData de Xcode et les caches de développement sans risque

Ce qu’est DerivedData et pourquoi il devient énorme

DerivedData est l’endroit où Xcode conserve tout ce qu’il dérive de votre code source : objets de build intermédiaires, produits compilés, caches de modules, index de symboles pour la complétion de code et le saut vers la définition, et journaux de build. Il se trouve par défaut dans ~/Library/Developer/Xcode/DerivedData, avec un sous-dossier par projet ou espace de travail que vous avez déjà ouvert.

Il grossit pour une raison structurelle : Xcode crée un dossier DerivedData pour chaque projet que vous ouvrez — y compris les clones ponctuels compilés une fois et jamais retouchés — et ne les supprime pas de lui-même. Chaque dossier contient des produits de build distincts par configuration et par destination (Debug et Release, simulateur et appareil) : mesurez donc les sous-dossiers de projet plutôt que de présumer de l’espace que votre Mac récupérera.

Tout ce qu’il contient est régénérable par définition — c’est le sens même de « derived » (dérivé). Supprimer DerivedData ne touche jamais à votre code source, à vos réglages de projet ni à quoi que ce soit sous contrôle de version. Le seul coût est le temps : le build suivant de chaque projet repart de zéro, et l’indexation tourne de nouveau en arrière-plan pendant quelques minutes.

Supprimer DerivedData

La commande Clean Build Folder de Xcode (Product > Clean Build Folder, ou Commande + Maj + K) n’efface que les produits de build du projet ouvert — utile pour corriger un build capricieux, mais quasi sans effet sur l’espace disque. Pour récupérer un espace conséquent, supprimez les dossiers DerivedData eux-mêmes : affichez-les depuis les réglages Locations de Xcode ou ouvrez le dossier dans le Finder, ou bien supprimez-les depuis le Terminal. Les trois méthodes aboutissent au même résultat.

La suppression projet par projet est l’option chirurgicale : conservez DerivedData pour les deux ou trois projets que vous compilez tous les jours, et supprimez les dossiers de tous les autres. Tout supprimer d’un coup est l’option rapide, et elle convient aussi : vous payez simplement le coût d’une reconstruction complète sur tous les projets à la fois.

1. Quittez d’abord Xcode. Supprimer DerivedData pendant que Xcode tourne peut dérouter son indexeur, et les fichiers que Xcode garde ouverts risquent de ne pas se supprimer proprement.
2. Localisez le dossier : dans Xcode, ouvrez Settings > Locations et cliquez sur la petite flèche à côté du chemin DerivedData pour l’afficher dans le Finder. Ou, dans le Finder, appuyez sur Commande + Maj + G et saisissez directement ~/Library/Developer/Xcode/DerivedData.
3. Triez les sous-dossiers de projet par taille, sélectionnez ceux à supprimer (ou Commande + A pour tous), puis placez-les dans la Corbeille. Passer d’abord par la Corbeille est la bonne habitude : vous pouvez tout restaurer instantanément si vous changez d’avis.
4. Ou, depuis le Terminal : rm -rf ~/Library/Developer/Xcode/DerivedData supprime tout d’un seul coup. C’est plus rapide que le Finder pour les très gros dossiers, mais lisez la note ci-dessous avant de l’utiliser.
5. Rouvrez Xcode et compilez. Attendez-vous à ce que le premier build de chaque projet soit nettement plus long et à voir « Indexing » s’afficher un moment dans la barre d’activité : deux coûts ponctuels.

Prudence avec rm -rf : la commande contourne la Corbeille et supprime définitivement, sans annulation possible. Saisissez le chemin exactement, ne l’exécutez jamais avec sudo pour cette tâche et, si vous n’êtes pas à l’aise avec le Terminal, passez par le Finder, qui fait le même travail de façon réversible.

Supprimer les anciens runtimes de simulateur

Les simulateurs constituent souvent une autre grosse catégorie du stockage de développement. Chaque runtime iOS, watchOS ou tvOS téléchargé occupe sa propre place, et chaque appareil simulé conserve ses données sous ~/Library/Developer/CoreSimulator/Devices. Si vous avez traversé plusieurs mises à jour de Xcode, passez en revue les runtimes des versions d’OS qui ne font plus partie de vos tests.

Le gain le plus rapide est la commande de nettoyage intégrée : exécutez xcrun simctl delete unavailable dans le Terminal. Elle supprime chaque appareil simulé marqué comme indisponible — surtout des orphelins laissés par des runtimes supprimés et d’anciennes versions de Xcode —, avec les apps et les données qu’il contient. Passez d’abord la liste en revue avec xcrun simctl list devices, surtout si plusieurs versions de Xcode sont installées sur votre Mac.

Pour les runtimes eux-mêmes, ouvrez Settings > Components dans Xcode (appelé Platforms dans Xcode 14 et 15). Chaque runtime de simulateur installé y apparaît avec sa taille ; sélectionnez un ancien runtime et supprimez-le. Ne gardez que le runtime le plus récent de chaque plateforme, sauf si vous testez activement sur des versions d’OS plus anciennes.

Vous pouvez aussi supprimer des appareils simulés un par un dans Window > Devices and Simulators : ouvrez l’onglet Simulators, faites un clic droit sur un appareil que vous n’utilisez jamais — les six modèles d’iPhone en double remplis de données de vieux tests — et choisissez Delete. Les apps et données enregistrées de l’appareil disparaissent avec lui.

Archives, fichiers de prise en charge des appareils et caches

Les archives s’accumulent dans ~/Library/Developer/Xcode/Archives chaque fois que vous lancez Product > Archive pour distribuer un build. Chaque archive contient un build complet de l’app et ses symboles de débogage dSYM, souvent 100 Mo à 1 Go chacune. Avant de supprimer, pesez le compromis : les dSYM qu’elles contiennent permettent de symboliser les rapports de plantage de ce build précis. Conservez les archives des versions encore en ligne sur l’App Store ou TestFlight (ou vérifiez qu’App Store Connect dispose des dSYM) et supprimez le reste ; le plus sûr est de passer par l’Organizer de Xcode (Window > Organizer > Archives), où vous pouvez les examiner et les supprimer en connaissance de cause.

iOS DeviceSupport, dans ~/Library/Developer/Xcode/iOS DeviceSupport, contient les symboles de débogage que Xcode copie depuis chaque iPhone ou iPad physique que vous avez branché — un dossier par version d’iOS, généralement 2 à 5 Go chacun. Les dossiers des versions d’iOS qu’aucun de vos appareils n’exécute plus sont du poids mort : supprimez-les. Si vous reconnectez un jour un appareil sous cette version, Xcode recopiera simplement les symboles (le message « Preparing debugger support » s’affichera une fois). Des dossiers équivalents existent pour les appareils watchOS et tvOS.

Xcode conserve aussi ses propres caches sous ~/Library/Caches/com.apple.dt.Xcode, et les simulateurs les leurs dans ~/Library/Developer/CoreSimulator/Caches. Les deux se reconstruisent à la demande, mais ne les videz que lorsque Xcode et l’app Simulator sont fermés, et laissez de côté les fichiers de cache de CoreSimulator que vous ne reconnaissez pas.

Caches des gestionnaires de paquets (SwiftPM, CocoaPods, npm, Homebrew)

Les gestionnaires de paquets conservent les dépendances téléchargées pour accélérer les installations suivantes. C’est utile, mais cela peut aussi devenir une grosse catégorie de stockage sur une machine qui a vu passer des années de projets. Ces caches de téléchargement sont reconstructibles, mais la prochaine installation devra retélécharger les paquets.

Swift Package Manager met en cache les paquets téléchargés dans ~/Library/Caches/org.swift.swiftpm, et les checkouts résolus de chaque projet se trouvent aussi dans son dossier DerivedData : vider DerivedData les efface donc déjà. Le cache partagé peut être supprimé depuis le Finder, ou avec rm -rf sur ce chemin.

CocoaPods conserve ses pods téléchargés dans ~/Library/Caches/CocoaPods. Pour le vider proprement, utilisez la commande intégrée : pod cache clean --all. Les dossiers Pods de vos projets restent intacts ; seul le cache de téléchargement disparaît.

Le cache de npm se trouve dans ~/.npm et peut atteindre plusieurs gigaoctets sur une machine très orientée JavaScript. Exécutez npm cache clean --force pour le vider (npm exige cette option parce que son cache s’autorépare et n’a normalement jamais besoin d’être nettoyé ; le supprimer est sans danger : les paquets sont simplement retéléchargés à la prochaine installation). Avec pnpm, exécutez plutôt pnpm store prune.

Homebrew accumule les anciens téléchargements et les versions de paquets obsolètes. brew cleanup supprime les versions dépassées et les téléchargements périmés et, exécuté sans nom de formule, désinstalle aussi les dépendances dont plus rien n’a besoin (sauf si HOMEBREW_NO_AUTOREMOVE est défini) ; brew cleanup --prune=all vide en plus tout le cache de téléchargement. Lancez d’abord brew cleanup -n pour obtenir, sans rien effacer, la liste de ce qui serait supprimé.

Automatiser ce nettoyage

Tout ce qui précède fonctionne, mais le ménage de développement est un éternel recommencement : DerivedData se reconstitue en une semaine de travail normal, les caches se remplissent de nouveau et chaque mise à jour de Xcode laisse un runtime de plus derrière elle. Si vous préférez ne pas répéter six procédures manuelles chaque mois, c’est cette partie qui mérite d’être automatisée — avec un outil qui explique son raisonnement au lieu de supprimer en masse sans rien dire.

AskClean traite les fichiers de développement comme des catégories à part entière : une seule analyse détaille DerivedData de Xcode projet par projet, les anciens runtimes de simulateur (lus via simctl, en gardant le plus récent de chaque plateforme), les fichiers de prise en charge des appareils et les caches de gestionnaires de paquets pour npm, SwiftPM, cargo, uv et d’autres. Il repère aussi les nouveaux gouffres à espace — les modèles d’IA locaux —, en listant les modèles Hugging Face un par un et la bibliothèque de modèles Ollama comme un seul élément, tous décochés par défaut.

Chaque élément s’accompagne d’une explication — ce que c’est, s’il peut être reconstruit, ce que coûte sa suppression — et rien n’est supprimé sans votre confirmation. Les éléments confirmés sont supprimés définitivement, sans passer par la Corbeille : vérifiez donc chaque sélection. Votre code source et votre photothèque ne sont jamais touchés. C’est la même liste de contrôle que ce guide, sans l’heure passée dans le Terminal.

Ce qui se régénère, et ce qui ne se régénère pas

Ce tableau délimite ce qui peut être supprimé ; il ne promet aucun gain d’espace. Mesurez votre Mac avant et après chaque action : le script d’inventaire en lecture seule du guide sur le stockage des simulateurs Xcode mesure ces dossiers sans rien modifier.

FAQ