Désinstaller complètement Xcode sur Mac sans perdre les projets ni les dSYM
Équipe AskClean · Mis à jour 2026-09-01
Avant de désinstaller complètement Xcode, sauvegardez les projets source et conservez les Archives et dSYM encore nécessaires aux builds distribués. Placez ensuite l’app dans la Corbeille et examinez séparément DerivedData, les simulateurs, DeviceSupport et les outils en ligne de commande.
Protéger les données non reproductibles avant la désinstallation
Les dossiers de projet ne sont pas des résidus Xcode. Sauvegardez les dépôts, fichiers non validés, paquets locaux et ressources. Conservez les Archives/dSYM des versions encore présentes sur l’App Store, TestFlight ou chez des clients, ainsi que les états Simulator utiles.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
Supprimer l’app selon son mode d’installation initial
Quittez Xcode et Simulator, puis placez la bonne Xcode.app dans la Corbeille depuis le Finder. Ne supprimez pas automatiquement /Library/Developer/CommandLineTools : Git, Homebrew, clang et les scripts de build peuvent encore en dépendre.
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.
Vérifier avant de vider la Corbeille
Contrôlez de nouveau Applications, les processus et xcode-select -p. Vérifiez que les projets, Archives/dSYM requis et données Simulator sont présents avant de vider la Corbeille. L’affichage des Données système peut se mettre à jour plus tard.
Carte de sécurité de la désinstallation complète
Supprimez Xcode en séparant les caches régénérables des Archives, de DeviceSupport, des données Simulator et des Command Line Tools.
| Décision | Où vérifier ou agir | Conséquence et vérification |
|---|---|---|
| Protéger les données non reproductibles avant la désinstallation | Projects / Xcode Organizer / Archives | Les dossiers de projet ne sont pas des résidus Xcode. Sauvegardez les dépôts, fichiers non validés, paquets locaux et ressources. Conservez les Archives/dSYM des versions encore présentes sur l’App Store, TestFlight ou chez des clients, ainsi que les états Simulator utiles. |
| Supprimer l’app selon son mode d’installation initial | /Applications/Xcode.app / Finder | Quittez Xcode et Simulator, puis placez la bonne Xcode.app dans la Corbeille depuis le Finder. Ne supprimez pas automatiquement /Library/Developer/CommandLineTools : Git, Homebrew, clang et les scripts de build peuvent encore en dépendre. |
| Vérifier avant de vider la Corbeille | xcode-select -p / Activity Monitor | Contrôlez de nouveau Applications, les processus et xcode-select -p. Vérifiez que les projets, Archives/dSYM requis et données Simulator sont présents avant de vider la Corbeille. L’affichage des Données système peut se mettre à jour plus tard. |
FAQ
Puis-je supprimer entièrement ~/Library/Developer ?
Non. Ce dossier mélange DerivedData régénérable avec Archives/dSYM, DeviceSupport, runtimes et états Simulator. Chaque catégorie doit être examinée séparément.
Est-il sûr de supprimer DerivedData ?
Oui — c'est l'une des grosses suppressions les plus sûres sur un Mac. DerivedData ne contient que des fichiers que Xcode génère à partir de votre source : produits de build, caches de modules, index et journaux. Votre code, vos fichiers de projet et votre historique git vivent ailleurs et ne sont jamais affectés. La seule conséquence : le build suivant de chaque projet est une reconstruction complète, et l'indexation tourne à nouveau.
À quelle fréquence dois-je vider DerivedData ?
Il n'y a pas de calendrier obligatoire — videz-le quand il devient assez gros pour compter, ce qui pour la plupart des développeurs actifs signifie tous les mois ou tous les deux mois. Deux moments le justifient toujours : quand vous avez besoin d'espace disque rapidement, et quand un projet présente des erreurs de build inexplicables ou une complétion de code périmée, où un effacement de DerivedData est le premier remède standard.
Sources