Xcode : Clean Build Folder ou suppression de DerivedData ?

La différence tient à la portée, pas à la profondeur

Product > Clean Build Folder (Commande + Maj + K) agit dans le projet et le schéma actuellement ouverts. La commande supprime les produits compilés et les fichiers intermédiaires de ce contexte, pour que le build suivant reparte des sources. Sa portée se limite à un projet, et elle conserve délibérément ce qui coûte cher à reconstruire.

DerivedData est le dossier de premier niveau partagé par tous les projets qui utilisent l’emplacement par défaut — ~/Library/Developer/Xcode/DerivedData, avec un sous-dossier par projet ou espace de travail que vous avez déjà ouvert. Supprimer un sous-dossier réinitialise exactement ce projet. Supprimer tout le dossier oblige chacun de vos projets à être recompilé et réindexé à sa prochaine ouverture.

Il serait donc trompeur d’opposer un « nettoyage léger » à un « nettoyage en profondeur ». Clean Build Folder est ciblé et peu coûteux ; supprimer DerivedData a une portée large et vous coûte l’index. Le bon choix dépend uniquement de l’endroit où se situe la panne : dans les produits de build ou en dehors.

Quand un build échoue, commencez par le plus ciblé

Si l’échec est apparu juste après un changement de branche, de configuration de build ou de fichiers de ressources, arrêtez l’app en cours d’exécution et lancez d’abord Clean Build Folder. C’est la réinitialisation la moins coûteuse : elle préserve l’index et vous remet au travail en un seul build, au lieu d’un build suivi de plusieurs minutes d’indexation.

Passez à la suppression du dossier DerivedData de ce projet quand les symptômes ne relèvent pas vraiment des produits de build : Xcode signale des erreurs dans du code déjà corrigé, Jump to Definition mène au mauvais endroit, la complétion de code ne reconnaît plus vos propres types. Ce sont des symptômes d’index, et Clean Build Folder ne touche pas à l’index.

Un cas précis mérite d’être connu, car c’est généralement lui qui transforme « j’ai nettoyé et rien n’a changé » en « j’ai supprimé DerivedData et tout est rentré dans l’ordre » : le cache des modules précompilés (ModuleCache.noindex) se trouve à la racine de DerivedData, et non dans le sous-dossier d’un projet. Clean Build Folder ne l’atteint jamais. Quand ce cache devient obsolète après un changement de SDK ou de chaîne d’outils, seule sa suppression fait disparaître l’erreur.

Aucune des deux commandes ne corrige un vrai bug dans votre code ou vos dépendances. Si exactement la même erreur survit à un build propre, arrêtez de nettoyer et lisez le message du compilateur : la cause se trouve dans les réglages du projet, dans Package.resolved, dans le SDK sélectionné ou dans le code lui-même.

Ni l’une ni l’autre ne sert à nettoyer le disque

Clean Build Folder est un outil de diagnostic qui, accessoirement, libère quelques octets. Il peut rendre de l’espace pour le projet en cours, mais les produits de build de tous les autres projets, tous les index et le cache des modules restent exactement en place. L’exécuter pour récupérer de l’espace disque, c’est viser la mauvaise cible.

Si l’espace est le véritable objectif, procédez dans l’autre sens : mesurez d’abord les sous-dossiers de DerivedData, puis supprimez ceux des projets que vous n’avez pas ouverts depuis des mois. C’est généralement là que se trouvent les dizaines de gigaoctets : des clones ponctuels, compilés une fois puis jamais rouverts.

Ne commencez pas par rm -rf. Le Finder vous permet de placer les dossiers sélectionnés dans la Corbeille, où ils restent récupérables tant que vous ne la videz pas — une différence qui compte la première fois que vous supprimez le dossier d’un projet justement en cours de compilation. Le Terminal se justifie pour l’automatisation, mais seulement après avoir vérifié le chemin exact.

Vérifiez le résultat au lieu de vous fier à un chiffre

Notez la taille de DerivedData avant toute action, appliquez une seule des deux options, puis mesurez de nouveau. Après Clean Build Folder, compilez le schéma en cours. Après la suppression d’un dossier DerivedData, ouvrez Xcode et attendez la fin du premier build et de l’indexation.

Procéder dans cet ordre distingue l’espace récupéré du prix payé pour le récupérer. Il n’existe pas de chiffre universel : le résultat dépend du nombre de projets, de configurations et d’architectures compilés sur ce Mac précis.

Quelle option choisir

Ce tableau décrit une portée, pas un nombre de gigaoctets promis. Mesurez votre propre Mac avant et après.

FAQ