Peut-on supprimer DerivedData d'Xcode sans risque ?
Oui. Ce que tu perds en supprimant DerivedData, le temps qu'il faut pour le reconstruire, et le dossier voisin à ne pas toucher.
Mis à jour le 2026-08-13
La réponse courte
DerivedData contient les fichiers intermédiaires de build, l'index du code, les caches de modules et les journaux. Chaque octet se régénère à partir de tes sources. Le supprimer ne peut pas te faire perdre de travail : il t'en coûte un build lent et quelques minutes de réindexation.
$ du -sh ~/Library/Developer/Xcode/DerivedDataCombien il y a réellement, avant de toucher à quoi que ce soit.
$ rm -rf ~/Library/Developer/Xcode/DerivedData/*Supprime le contenu, garde le dossier. Xcode recrée ce dont il a besoin au build suivant.
Ce que tu perds vraiment
| Élément | Ce que coûte sa perte |
|---|---|
| Fichiers objets compilés | Un build complet. De quelques minutes à quelques dizaines de minutes. |
| L'index du code | Aller à la définition et l'autocomplétion fonctionnent moins bien jusqu'à la fin de la réindexation. |
| Cache de modules | Reconstruit à la demande, sans que tu t'en aperçoives. |
| Journaux de build | Perdus. Rarement regrettés, parfois gênants pendant une chasse au bug. |
| Ton code source | Rien. Les sources ne sont jamais dans DerivedData. |
Le vrai inconvénient, c'est le temps, pas le risque. Sur un gros projet avec plusieurs dépendances, un build à froid après avoir vidé DerivedData peut prendre 10–30 minutes. Ne le fais pas cinq minutes avant une démo.
Supprimer de façon sélective
Tu as rarement besoin de tout vider. DerivedData est organisé par projet, et ce sont les projets abandonnés l'an dernier qui prennent la place.
$ du -sh ~/Library/Developer/Xcode/DerivedData/* | sort -h | tail -20Les vingt plus gros dossiers de projet, du plus petit au plus gros.
$ find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mtime +90 -type dLes dossiers de projet inutilisés depuis plus de 90 jours. Lis la liste avant de la supprimer.
$ find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mtime +90 -type d -exec rm -rf {} +Supprime exactement ce que la commande précédente a listé. Lance celle-là d'abord.
Les dossiers voisins, et ceux à laisser tranquilles
| Chemin | Suppression sans risque ? | Ce que c'est |
|---|---|---|
| ~/Library/Developer/Xcode/DerivedData | Oui | Fichiers intermédiaires de build et index. Entièrement régénérables. |
| ~/Library/Developer/Xcode/Archives | Non, pas à l'aveugle | Tes builds publiés et leurs dSYM. Indispensables pour symboliser les rapports de plantage venus de l'App Store. |
| ~/Library/Developer/Xcode/iOS DeviceSupport | Oui, en grande partie | Les symboles de chaque version d'iOS sur laquelle tu as un jour branché un appareil. Souvent plus de 20 Go. Retéléchargés au besoin. |
| ~/Library/Developer/CoreSimulator/Devices | Au cas par cas | Images disque des simulateurs. Voir le guide sur les simulateurs. |
| ~/Library/Caches/com.apple.dt.Xcode | Oui | Le cache propre à Xcode. Se reconstruit tout seul. |
Les symboles de prise en charge des appareils sont en général le deuxième plus gros gain :
$ du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*Un dossier par version d'iOS sur laquelle tu as un jour débogué.
$ rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/1[0-6]*Supprime les symboles d'iOS 10 à 16. Xcode les retélécharge si tu branches à nouveau un tel appareil.
Faire en sorte que ça arrive moins souvent
- Xcode → Settings → Locations permet de placer DerivedData dans un dossier propre à chaque projet : les données périmées sautent aux yeux et partent facilement avec le projet.
- Les caches de Swift Package Manager se trouvent dans ~/Library/Caches/org.swift.swiftpm : ça vaut le coup d'œil, en général 1–5 Go.
- Si tu utilises CocoaPods, ~/Library/Caches/CocoaPods peut atteindre plusieurs gigaoctets et se régénère entièrement.
Supprimer DerivedData va-t-il casser mon projet ?
Non. Il ne contient ni sources, ni configuration, ni éléments de signature. Xcode régénère tout ce dont il a besoin au build suivant.
Product → Clean Build Folder, c'est la même chose ?
Pas tout à fait. Clean supprime les produits de build du scheme courant ; supprimer DerivedData efface les fichiers intermédiaires, l'index et les caches de modules de tous les projets. Clean est le petit marteau.
Combien de temps avant qu'il revienne ?
Tout de suite, et il reviendra. DerivedData n'est pas une fuite, c'est un cache de travail. Attends-toi à ce qu'il retrouve la même taille en quelques semaines de travail actif.
Peut-on le supprimer pendant qu'Xcode tourne ?
Ça fonctionne, mais Xcode sera perdu jusqu'à ce que tu le relances. Quitte-le d'abord et épargne-toi le bruit.
La version automatique
Tout ce qui précède marche, ne coûte rien et continuera de marcher. Loupe fait la même chose sur tous les projets du disque à la fois, et montre ce que chaque suppression coûtera à reconstruire avant que tu l'acceptes.
Guides voisins