Xcode DerivedData prend trop de place sur ton Mac ? Que nettoyer en premier

Si tu construis des apps sur Mac tous les jours, DerivedData finit par devenir un de ces dossiers que tu sais importants, mais dont tu espères que quelqu’un d’autre a déjà fait le ménage.

Puis un jour le dossier est énorme, le disque est serré, Xcode semble plus lourd que d’habitude, et la question de nettoyage devient immédiate : peux-tu le supprimer en toute sécurité, ou est-ce que tu vas transformer ta journée de travail en chaos de reconstruction ?

La réponse courte, c’est que DerivedData est généralement l’une des cibles de nettoyage Xcode les plus sûres. La réponse longue, c’est que les développeurs se focalisent souvent trop sur DerivedData et ratent le reste de l’empreinte de l’écosystème Apple qui se trouve juste à côté.

Réponse rapide

Ce qui est généralement sûr à nettoyer vs ce qui nécessite de la prudence

Ce qu’est réellement Xcode DerivedData

DerivedData est l’endroit où Xcode garde la sortie de build générée et les données de travail associées pour les workflows de développement. En pratique, ça veut généralement dire des produits de build, des index, des fichiers intermédiaires, des sorties liées aux aperçus et d’autres artefacts générés qui aident Xcode à aller plus vite la prochaine fois que tu builds ou ouvres le projet.

C’est pourquoi le dossier grossit si facilement. Chaque projet, cible, combinaison de branche/SDK et workflow de simulateur ajoute plus d’état généré au fil du temps.

Ça explique aussi pourquoi les développeurs traitent DerivedData différemment des fichiers de projet ordinaires :

• ce n’est pas la source de vérité pour le code de ton app ;
• il existe pour gagner du temps de build et d’indexation ;
• il est censé se régénérer quand nécessaire.

Ce comportement de régénération est la raison pour laquelle DerivedData est généralement classé comme une cible de nettoyage plus sûre que beaucoup de chemins app-owned ou system-owned.

Pourquoi Xcode DerivedData devient si gros

La réponse la plus simple, c’est l’accumulation.

Une seule app active peut déjà générer beaucoup de sortie de build. Plusieurs apps, plusieurs branches, des aperçus, des sessions de simulateur, des builds de test et un historique de résolution de packages peuvent pousser le dossier bien plus haut que la plupart des développeurs ne s’y attendent.

Raisons courantes pour lesquelles DerivedData gonfle :

• plusieurs projets actifs partagent la même machine ;
• des dossiers par projet obsolètes restent bien après que le projet a cessé d’être pertinent ;
• les aperçus, l’indexation et les workflows intensifs sur les simulateurs génèrent un churn supplémentaire ;
• les environnements Xcode de longue durée conservent d’anciennes sorties de build plus longtemps que tu ne le penses ;
• tu nettoies d’autres choses mais ne touches jamais aux artefacts de dev Apple générés.

Le point important, c’est qu’un DerivedData volumineux n’est pas inhabituel sur un Mac de développement. Ça devient un problème seulement quand tu supposes que la bonne réponse est toujours « tout supprimer maintenant » sans vérifier ce qui d’autre est gros et si le timing est bon.

Quoi d’autre près de DerivedData devient généralement gros

Les développeurs blâment souvent DerivedData parce qu’il est familier, mais ce n’est qu’un profil dans l’empreinte de l’écosystème Apple.

Les profils Apple actuels de StorageRadar séparent ces zones adjacentes à Xcode parce qu’elles ne partagent pas le même modèle de risque :

C’est la vraie raison pour laquelle un scan complet du Developer Folder est plus utile que la vision tunnel sur un seul répertoire. Si DerivedData fait 12 Go mais que CoreSimulator en fait 35 et Archives 18, le plan de nettoyage change complètement.

Les dossiers développeur Apple qui grossissent souvent avec DerivedData

Archives

Les Archives ne sont pas juste de l’espace de travail jetable. Ils peuvent représenter des livrables que tu peux réellement vouloir conserver. C’est pourquoi ils appartiennent à une catégorie de nettoyage différente de DerivedData.

CoreSimulator

Les données du simulateur peuvent discrètement dépasser DerivedData, surtout si tu testes sur plusieurs runtimes ou gardes l’état du simulateur pendant longtemps. Ce n’est pas juste un dossier de cache jetable. Il peut contenir des environnements de simulateur dont tu te soucies encore.

Si le stockage des simulateurs est le vrai problème, le guide dédié sur Le simulateur Xcode prend trop de place sur ton Mac ? Que nettoyer en premier va plus loin sur les runtimes, l’état des appareils et les compromis de nettoyage.

iOS DeviceSupport

Cette zone grossit au fur et à mesure que différentes versions d’appareils physiques et assets de support s’accumulent. Elle est souvent négligée parce qu’elle est moins connue que DerivedData, mais quand même assez volumineuse pour compter.

Caches liés aux packages

Ceux-ci peuvent être des cibles de nettoyage plus sûres que les données de simulateur ou d’archives, mais ils restent séparés de DerivedData. Si tu cherches sérieusement de l’espace récupérable, traite chaque profil comme son propre problème de nettoyage.

Quand le nettoyage sélectif est meilleur que tout supprimer

Le réflexe développeur par défaut est souvent le nettoyage total : effacer tout le dossier, laisser Xcode reconstruire, passer à autre chose.

Ça peut être ok, mais ce n’est pas toujours le meilleur choix.

Le nettoyage sélectif est généralement meilleur quand :

• seuls quelques vieux projets sont responsables de la majeure partie de la taille ;
• tu as besoin de builds rapides et prévisibles pour tes apps actives actuelles ;
• tu ne veux pas forcer une réindexation complète de tout aujourd’hui ;
• tu suspects que des branches obsolètes ou des workspaces retirés sont le vrai problème, pas les projets actuels.

Un effacement complet est plus raisonnable quand :

• tout le dossier est gonflé à travers beaucoup de vieux projets ;
• tu veux une réinitialisation propre de la sortie générée ;
• le ralentissement actuel vaut le compromis d’une fenêtre de reconstruction contrôlée ;
• tu suspects que l’état généré global fait partie du problème.

C’est vraiment une décision de timing déguisée en décision de stockage. Les économies d’espace peuvent être similaires, mais le coût en workflow est différent.

Comment nettoyer Xcode DerivedData sans créer de chaos de reconstruction

L’objectif sûr n’est pas juste « libérer de l’espace ». L’objectif sûr est « libérer le bon espace tout en gardant les quelques prochaines heures de développement prévisibles ».

1. Examiner d’abord l’ensemble du paysage développeur

Commence par Developer Folder si tu l’as, pas par DerivedData isolément. L’idée est de voir si la sortie Xcode est vraiment le problème dominant ou si d’autres profils Apple dev sont plus gros.

Si l’empreinte développeur plus large est le problème, nettoyer seulement DerivedData peut récupérer moins que ce que tu attends.

2. Séparer la sortie générée sûre des profils Caution

Cette distinction compte :

• DerivedData et les caches sont généralement des cibles de nettoyage de type Safe parce qu’ils sont générés ;
• Archives, CoreSimulator et iOS DeviceSupport méritent plus de prudence parce qu’ils peuvent préserver des artefacts, des runtimes ou un état dont tu as encore besoin.

Une fois que tu les confonds, le « nettoyage développeur » devient juste une autre purge de dossiers dangereuse.

3. Décider entre nettoyage sélectif et total délibérément

Avant de supprimer quoi que ce soit, réponds à ces questions :

1. Les plus gros répertoires DerivedData sont-ils liés à des projets obsolètes ou actifs ?
2. As-tu besoin de builds et d’indexation rapides aujourd’hui ?
3. Les profils voisins sont-ils réellement plus gros que DerivedData ?
4. Une fenêtre de reconstruction complète va-t-elle nuire à ton sprint actuel, ta démo ou ton travail de release ?

Ce court examen empêche la plupart des effacements complets inutiles.

4. S’attendre à un coût de reconstruction, pas à une perte de données

Pour DerivedData, le coût normal du nettoyage est généralement :

• un prochain build plus lent ;
• des reconstructions d’index ;
• des aperçus ou démarrages de simulateur plus lourds ;
• une friction temporaire pendant que la sortie générée revient.

C’est très différent de supprimer des données de support d’app, des archives dont tu as encore besoin ou un état de simulateur auquel tu tenais. Le nettoyage de développement reste sûr seulement quand tu gardes ces catégories séparées.

5. Utiliser un workflow de nettoyage de développement, pas une suppression de fichiers générique

Un navigateur de fichiers ordinaire peut te dire que quelque chose est gros. Il ne peut pas te dire si le chemin est un profil dev connu, s’il est dans un bucket Safe ou Caution, quelles sont les conséquences probables, ou si un guided preflight est nécessaire avant le nettoyage.

Ce contexte manquant est la raison pour laquelle le nettoyage de développement ne devrait pas se réduire au nettoyage « plus gros fichiers » classique une fois que les enjeux augmentent.

Pourquoi le nettoyage Xcode est différent du nettoyage de fichiers ordinaire

Le nettoyage de fichiers ordinaire pose une question simple : qu’est-ce qui est gros ?

Si tu veux le guide plus large couvrant Xcode, Docker, les environnements lourds en SDK et les profils de risque développeur, lis Comment nettoyer les caches de développement en toute sécurité sur Mac.

Le nettoyage de développement doit poser des questions plus difficiles :

• est-ce généré ou écrit par l’utilisateur ;
• ce profil est-il Safe, Caution ou Dangerous ;
• ai-je besoin de Dry Run avant de faire confiance à la taille récupérable ;
• ai-je besoin de Guided Preflight parce que le profil a un risque de workflow ;
• quels bloqueurs, avertissements ou conséquences dois-je vérifier d’abord ?

Cette différence est intégrée dans le modèle Dev Cleanup de StorageRadar. Il ne fonctionne pas comme une suppression arbitraire. Il part de profils développeur connus et d’une politique de risque.

Par exemple, les profils Apple dev actuels se divisent ainsi :

• Xcode DerivedData comme Safe ;
• Xcode Archives comme Caution ;
• CoreSimulator Data comme Caution ;
• iOS DeviceSupport comme Caution ;
• SwiftPM Cache comme Safe.

C’est l’inverse du chaos de nettoyage. C’est un workflow conscient de l’écosystème qui traite les caches générés différemment des artefacts conservés et de l’état des simulateurs.

Où StorageRadar intervient

Ça change le workflow pratique :

• utilise Developer Folder quand toute la zone développeur Apple peut être gonflée ;
• utilise Dev Cleanup quand tu veux un nettoyage conscient des profils plutôt qu’une suppression de fichiers ordinaire ;
• garde les profils Safe comme DerivedData séparés des profils Caution comme Archives et le stockage lié aux simulateurs.

Cette distinction est toute la valeur pour une machine de développement. Le produit ne te dit pas seulement qu’un dossier est gros. Il te dit de quel type de stockage développeur il s’agit et quel genre de processus de nettoyage il mérite.

Ce qu’il ne faut pas faire

Évite ces erreurs courantes :

• ne suppose pas que DerivedData est le seul dossier Xcode qui vaut la peine d’être vérifié ;
• n’efface pas Archives, CoreSimulator et iOS DeviceSupport comme s’ils avaient le même profil de risque ;
• ne fais pas une réinitialisation complète juste avant une deadline si le temps de reconstruction compte ;
• n’utilise pas la logique du plus gros fichier seule pour des artefacts de développement qui nécessitent un contexte d’écosystème ;
• ne confonds pas la sortie de build générée avec les données de projet, les livrables ou l’état de simulateur conservé.

Si les artefacts de dev Apple rendent aussi System Data suspicieusement élevé, le guide compagnon sur System Data Mac trop élevé est la bonne prochaine lecture.

Conclusion

Si DerivedData prend trop de place sur ton Mac, la partie rassurante, c’est que c’est généralement l’une des cibles de nettoyage Xcode les plus sûres parce que c’est une sortie générée. La partie moins évidente, c’est que DerivedData est rarement toute l’histoire.

La meilleure décision de nettoyage vient de l’examen de l’empreinte développeur plus large, de la séparation des profils Safe des profils Caution, et du choix entre nettoyage sélectif ou total basé sur ton workflow actuel au lieu de la panique.