Supprimer DerivedData de Xcode et les caches de développement en toute sécurité

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 un jour 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 il n'en supprime jamais aucun. Chaque dossier contient des produits de build distincts par configuration et par destination (Debug et Release, simulateur et appareil), si bien qu'un seul projet de taille moyenne peut occuper plusieurs gigaoctets, et le dossier dans son ensemble atteint couramment 20 à 50 Go sur une machine de développement en activité.

Tout ce qu'il contient est régénérable par définition — c'est le sens même de « derived ». 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 est un build complet à partir de zéro, et l'indexation tourne à nouveau en arrière-plan pendant quelques minutes.

Supprimer DerivedData

Il existe trois façons de procéder, et elles aboutissent au même résultat. La commande Clean Build Folder de Xcode (Product > Clean Build Folder, ou Commande + Maj + K) n'efface que les produits de build du projet actuellement ouvert — utile pour corriger un build capricieux, mais l'effet sur l'espace disque est marginal. Pour récupérer un espace conséquent, supprimez les dossiers DerivedData eux-mêmes.

La suppression projet par projet est l'option chirurgicale : conservez DerivedData pour les deux ou trois projets que vous compilez quotidiennement, et supprimez les dossiers de tout le reste. Tout supprimer d'un coup est l'option rapide, et elle est tout aussi valable — vous payez simplement le coût de la reconstruction complète sur tous les projets en même temps.

1. Quittez d'abord Xcode. Supprimer DerivedData pendant que Xcode tourne peut laisser son indexeur dans un état incohérent, et les fichiers ouverts par Xcode 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 le révéler 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 dont vous voulez vous débarrasser (ou Commande + A pour tous), et placez-les dans la Corbeille. Passer d'abord par la Corbeille est la bonne habitude — vous pouvez restaurer instantanément si vous changez d'avis.
4. Depuis le Terminal, à la place : 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 prenne nettement plus de temps, et à voir « Indexing » tourner 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. Tapez le chemin exactement, ne l'exécutez jamais avec sudo pour cette tâche, et si le Terminal ne vous met pas à l'aise, la voie du Finder fait le même travail de manière réversible.

Supprimez les anciens runtimes de simulateur

Les simulateurs sont généralement le deuxième plus gros consommateur d'espace de développement après DerivedData. Chaque runtime iOS, watchOS ou tvOS que vous avez téléchargé occupe 5 à 8 Go, et chaque appareil simulé conserve son propre dossier de données sous ~/Library/Developer/CoreSimulator/Devices. Si vous avez traversé quelques mises à niveau de Xcode, vous avez probablement des runtimes pour des versions d'iOS que vous ne ciblez plus depuis des années.

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é dont le runtime n'est plus installé — les orphelins laissés par les anciennes versions de Xcode — et ne touche à rien de ce que vous pouvez encore utiliser.

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

Vous pouvez aussi élaguer les appareils simulés un par un dans Window > Devices and Simulators : passez à l'onglet Simulators, faites un clic droit sur tout appareil que vous n'utilisez jamais — les six modèles d'iPhone en double avec des données de vieilles séries de tests — et choisissez Delete. Les données et apps enregistrées de chaque appareil partent avec lui.

Archives, fichiers de prise en charge d'appareils et caches

Les archives s'accumulent dans ~/Library/Developer/Xcode/Archives chaque fois que vous exécutez Product > Archive pour distribuer un build. Chaque archive contient un build complet de l'app plus ses symboles de débogage dSYM, soit souvent 100 Mo à 1 Go pièce. Avant de supprimer, connaissez le compromis : les dSYM qu'elles contiennent sont ce qui permet 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 détient les dSYM), et supprimez le reste — la voie la plus sûre est l'Organizer de Xcode (Window > Organizer > Archives), où vous pouvez les passer en revue et les supprimer en contexte.

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 un jour branché — un dossier par version d'iOS, typiquement 2 à 5 Go chacun. Les dossiers des versions d'iOS qu'aucun de vos appareils n'exécute plus sont du poids mort pur : supprimez-les, et si vous reconnectez un jour un appareil sous cette version, Xcode recopie simplement les symboles (vous verrez « Preparing debugger support » une fois). Des dossiers équivalents existent aussi pour les appareils watchOS et tvOS.

Xcode conserve également ses propres caches sous ~/Library/Caches/com.apple.dt.Xcode, et les simulateurs gardent les leurs dans ~/Library/Developer/CoreSimulator/Caches — les deux peuvent être vidés sans risque quand Xcode et l'app Simulator ne tournent pas, et les deux se reconstruisent à la demande.

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

Les gestionnaires de paquets conservent chaque dépendance qu'ils ont téléchargée pour accélérer les installations futures. C'est de la bonne ingénierie et une mauvaise hygiène de disque : les caches ne font que grossir, et sur une machine qui a vu défiler quelques années de projets, ils totalisent discrètement 10 à 20 Go. Tous peuvent être vidés sans risque — au pire, votre prochaine installation retélécharge 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 vivent aussi dans son dossier DerivedData — vider DerivedData les efface donc déjà. Le cache partagé, lui, se supprime depuis le Finder, ou avec rm -rf sur ce chemin.

CocoaPods garde ses pods téléchargés dans ~/Library/Caches/CocoaPods. La façon propre de le vider est 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 de nombreux gigaoctets sur une machine très orientée JavaScript. Exécutez npm cache clean --force pour le vider (npm exige ce drapeau parce que le cache est autoréparant et n'a normalement jamais besoin d'être nettoyé — le supprimer reste néanmoins parfaitement sûr). Les utilisateurs de pnpm peuvent exécuter pnpm store prune à la place.

Homebrew accumule vieux téléchargements et versions de paquets obsolètes. brew cleanup supprime les versions dépassées et les téléchargements périmés ; brew cleanup --prune=all vide en plus tout le cache de téléchargement. Lancez d'abord brew cleanup -n si vous voulez voir la liste de ce qui serait supprimé, sans rien effacer.

Automatisez tout cela

Tout ce qui précède fonctionne, mais les résidus de développement sont un tapis roulant : DerivedData revient au bout d'une semaine de travail normal, les caches se remplissent à nouveau, et chaque mise à jour de Xcode abandonne un runtime de plus. Si vous préférez ne pas rejouer six procédures manuelles chaque mois, c'est la partie qui mérite d'être automatisée — avec un outil qui montre son raisonnement au lieu de supprimer en masse en silence.

AskClean traite les fichiers de développement comme des catégories de premier plan : une seule analyse détaille Xcode DerivedData projet par projet, les anciens runtimes de simulateur (lus via simctl, en gardant le plus récent par plateforme), les fichiers de prise en charge d'appareils, et les caches de gestionnaires de paquets pour npm, SwiftPM, cargo, uv et plus encore. Il attrape aussi les nouveaux gouffres à espace — les caches de modèles Hugging Face et Ollama — qu'il liste modèle par modèle et laisse décochés par défaut.

Chaque élément arrive avec son explication — ce que c'est, s'il peut être reconstruit, ce que coûte sa suppression — et rien ne s'exécute tant que vous ne l'avez pas confirmé. Les suppressions partent à la Corbeille, si bien qu'un clic malheureux s'annule d'un simple glisser-déposer, et votre code source, vos documents et vos photos ne sont jamais touchés. C'est la même liste de contrôle que ce guide, moins l'heure passée dans le Terminal.

FAQ