Si le simulateur Xcode prend trop de place sur ton Mac, sépare les runtimes de simulateur des données d’appareil simulateur avant de supprimer quoi que ce soit. Commence par examiner ce qui est indisponible, ce qui est inactif et ce dont tu as encore besoin pour les tests, parce que le nettoyage de simulateur devient risqué quand tu traites chaque dossier Apple-side comme du cache jetable.
C’est l’erreur que font les développeurs après avoir appris une règle de nettoyage et l’avoir appliquée partout. DerivedData, c’est une chose. Les runtimes de simulateur et l’état des appareils simulateur en sont une autre.
Le stockage peut être récupérable. Les conséquences sont juste moins uniformes.
Règle de base : nettoie le stockage simulateur par couche. Supprime les appareils indisponibles en premier, efface les données d'appareil uniquement quand tu veux les réinitialiser, et supprime les runtimes uniquement quand tu n'as plus besoin de cette version d'OS.
Réponse rapide
- Vérifie si la vraie empreinte est les runtimes de simulateur, les données d'appareil simulateur, ou les deux.
- Utilise
xcrun simctl list devicesetxcrun simctl list runtimesavant de supprimer quoi que ce soit. - Supprime les appareils indisponibles en premier avec
xcrun simctl delete unavailablequand ils apparaissent dans la section unavailable. - Utilise
eraseuniquement quand tu veux réinitialiser les contenus et réglages d'un appareil simulateur. - Supprime les runtimes uniquement quand tu es sûr de ne plus avoir besoin de cette version de plateforme pour les builds, previews ou tests.
- Si le stockage Apple-side est plus large que les seuls simulateurs, examine
DerivedData,ArchivesetCoreSimulatorensemble au lieu de deviner depuis un seul dossier.
Ce que stockent les simulateurs Xcode et pourquoi ça s’accumule
Le stockage simulateur n’est pas une seule chose. C’est plusieurs couches qui s’accumulent ensemble.
À un niveau élevé, le stockage simulateur Xcode inclut généralement :
- les images de runtime pour différentes versions de plateforme iOS ;
- les appareils simulateur créés pour différents modèles d’iPhone et iPad ;
- les données d’appli, réglages et état par appareil dans ces simulateurs ;
- l’activité de développement Apple-side qui grossit quand tu changes de SDK, de types d’appareils et de versions Xcode.
C’est pourquoi les développeurs se sentent souvent confus par CoreSimulator. C’est facile de regarder la taille du dossier et de supposer que tout est du cache. En pratique, une partie ressemble plutôt à de l’état de test jetable, et une partie est du support de runtime dont tu dépends encore.
Le schéma de croissance est normal :
- tu installes un nouveau Xcode ou SDK ;
- de nouveaux runtimes apparaissent ;
- de nouveaux appareils simulateur sont créés ;
- des applis, données de test et réglages s’accumulent dedans ;
- les vieux appareils deviennent indisponibles après des changements de SDK ou des mises à jour Xcode ;
- rien n’est révisé pendant des mois parce que la machine a encore assez d’espace libre.
Puis un jour le stockage simulateur devient le sujet, pas juste un détail.
Runtimes de simulateur vs données de simulateur : quelle est la différence ?
C’est la distinction qui compte le plus.
L’outillage simctl d’Apple traite les opérations de runtime séparément des opérations d’appareil. Ça seul te dit que le modèle de nettoyage est en couches : les appareils ne sont pas la même chose que les runtimes, et effacer un appareil n’est pas la même chose que supprimer une image de runtime.
| Couche | Ce que ça représente | Action de nettoyage typique | Principal compromis |
|---|---|---|---|
| Runtimes de simulateur | Les images de runtime OS utilisées pour démarrer des versions de plateforme spécifiques | simctl runtime delete pour un runtime dont tu n’as vraiment plus besoin | Tu perds ce runtime pour une utilisation future du simulateur jusqu’à ce que tu le rajoutes |
| Appareils simulateur | Les instances de simulateur créées pour des modèles d’appareils spécifiques | simctl delete <device> ou delete unavailable | L’instance d’appareil disparaît |
| Contenus et réglages d’appareil simulateur | Applis installées, données d’appli, réglages et état dans un appareil | simctl erase <device> | L’appareil reste, mais ses contenus et réglages sont réinitialisés |
C’est pourquoi les affirmations globales comme « vide juste CoreSimulator » sont de mauvais conseils. Elles compressent différentes conséquences de nettoyage en une seule action émotionnelle.
Où DerivedData entre en jeu
DerivedData est adjacent, mais ce n’est pas le même problème.
DerivedData est généralement de l’output de build généré. Le stockage simulateur est plus mixte. Il peut inclure des runtimes dont tu as encore besoin, des appareils créés dont tu n’as plus besoin, et de l’état dans les appareils dont tu te soucies plus ou moins.
Si la pression vient surtout de l’output de build généré, le bon guide est Les DerivedData Xcode prennent trop de place sur Mac ? Par quoi commencer. Si la pression vient surtout des images de runtime et de l’état du simulateur, reste avec le workflow simulateur.
Comment vérifier combien d’espace utilisent les simulateurs
Le premier mouvement, c’est l’inspection, pas la suppression.
Utilise l’outillage d’Apple pour voir quels appareils et runtimes existent réellement :
xcrun simctl list devices
xcrun simctl list runtimesSi tu veux inspecter l’empreinte de stockage Apple-side globale sur le disque, tu peux aussi comparer les dossiers principaux directement :
du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/ArchivesÇa compte parce que le plus gros dossier Apple-side n’est pas toujours celui que tu croyais. Parfois DerivedData est le problème dominant. Parfois CoreSimulator le dépasse discrètement.
Ce qu’il faut chercher en premier
- des appareils listés sous
Unavailable; - des runtimes pour des versions d’OS que tu ne testes plus ;
- de nombreux appareils créés across plusieurs générations de runtime ;
- un état lourd en simulateur sur une machine qui n’a pas été nettoyée depuis plusieurs mises à jour Xcode ;
- un gros dossier
CoreSimulatorqui ne correspond pas à tes besoins de test actuels.
C’est le moment où le nettoyage commence à devenir rationnel au lieu de réactif.
Est-il sûr de supprimer les runtimes de simulateur sur Mac ?
Parfois, mais ce n’est pas le premier mouvement le plus sûr.
L’aide simctl runtime d’Apple indique clairement que les images de runtime sont leurs propres objets gérés. Supprimer un runtime est différent d’effacer les contenus d’un simulateur. C’est aussi différent de supprimer un appareil indisponible.
Ça veut dire que la suppression de runtime est meilleure quand :
- tu n’as plus besoin de cette version iOS pour les tests ;
- tu as dépassé une génération Xcode ou SDK plus ancienne ;
- le runtime est suffisamment inutilisé pour que l’espace vaille plus que le confort ;
- tu as vérifié la liste des runtimes d’abord et sais exactement ce que tu supprimes.
C’est une moins bonne idée quand :
- un projet actif cible encore cette famille de runtime ;
- les previews SwiftUI, les étapes de reproduction QA ou les tests de régression en dépendent encore ;
- tu es sur le point de faire une démo ou déboguer un problème sur une cible plus ancienne ;
- tu supprimes juste en fonction de la taille plutôt que des besoins réels de test.
Meilleur premier mouvement : retire le poids mort évident
Le nettoyage de simulateur le plus sûr commence souvent par les appareils indisponibles.
Apple le documente directement dans simctl delete : l’alias unavailable supprime les appareils qui ne sont pas supportés par le SDK Xcode actuel.
xcrun simctl delete unavailableCe n’est pas une réponse universelle, mais c’est l’une des premières passes les plus propres parce qu’elle cible des appareils déjà marqués comme non supportés par ton contexte SDK actuel.
Nettoyer les données de simulateur sans perdre ton environnement de dev
C’est là que les développeurs utilisent souvent le mauvais outil pour le travail.
Si ton problème est des données d’appli obsolètes ou un état d’appareil gonflé dans les simulateurs, tu n’as peut-être pas besoin de supprimer les runtimes du tout. Tu as peut-être seulement besoin de réinitialiser les appareils simulateur.
L’aide simctl erase d’Apple définit erase comme effaçant les contenus et réglages d’un appareil :
xcrun simctl erase <device>C’est une opération de réinitialisation, pas une opération de suppression de runtime.
Ce pour quoi erase est fait
- effacer l’état d’appli dans un simulateur ;
- réinitialiser les environnements de test ;
- supprimer les contenus au niveau appareil gonflés sans supprimer l’image de runtime elle-même ;
- garder le workflow d’appareil tout en abandonnant son état accumulé.
Ce que erase n’est pas
- pas une commande de nettoyage de runtime ;
- pas une commande de nettoyage de
DerivedData; - pas un bon remplacement pour réviser quels appareils et runtimes tu as réellement encore besoin.
Cette distinction, c’est toute l’histoire du nettoyage de simulateur : effacer un appareil, supprimer un appareil et supprimer un runtime sont trois décisions différentes.
Comment gérer le stockage simulateur pour l’avenir
L’objectif pratique n’est pas « ne jamais laisser les simulateurs grossir ». L’objectif pratique est « empêcher le stockage simulateur de devenir invisible ».
Utilise un rythme de révision comme celui-ci :
- Liste les appareils et runtimes après des changements majeurs de Xcode ou SDK.
- Supprime les appareils indisponibles quand ils apparaissent.
- Réinitialise les appareils simulateur obsolètes quand le problème est l’état des appareils, pas l’inventaire des runtimes.
- Révis l’utilisation des runtimes avant de retirer une version d’OS entièrement.
- Compare
CoreSimulator,DerivedDataetArchivesensemble quand le stockage Apple-side commence à grimper.
Ça garde la décision de nettoyage alignée sur la couche qui est réellement coûteuse.
Un meilleur modèle mental pour le stockage Apple-side
DerivedDataest surtout de l’output de build généré.Archivespréservent les livrables et l’historique de build.CoreSimulatormélange le support de runtime avec l’état des appareils simulateur.- le nettoyage le plus sûr dépend de quelle couche est volumineuse, pas juste de quel dossier est visible.
Une fois que tu penses en couches, le nettoyage de simulateur devient beaucoup moins chaotique.
Pourquoi le nettoyage développeur fonctionne mieux quand il reste conscient de l’écosystème
Si tu utilises seulement Finder, un dossier Apple-side de 20 ou 30 Go ressemble à une cible de nettoyage évidente. Ça n’en est pas une.
Un navigateur de fichiers peut te montrer que CoreSimulator est volumineux. Il ne peut pas te dire si le vrai espace récupérable est :
- des appareils non supportés ;
- des contenus de simulateur réinitialisables ;
- des runtimes dont tu n’as plus besoin ;
- ou un profil Xcode voisin qui se trouve juste à côté.
C’est pourquoi le nettoyage de simulateur appartient au nettoyage développeur, pas au nettoyage de fichiers générique.
Si ton vrai problème est « simulateurs plus DerivedData plus autre stockage Apple dev », ce workflow plus large conscient des profils est bien plus utile que de chasser un chemin de dossier à la fois.
En résumé
Si le simulateur Xcode prend trop de place sur ton Mac, ne traite pas CoreSimulator comme un seau de cache jetable.
Révis les appareils et runtimes d’abord. Supprime les appareils indisponibles comme première passe propre, utilise erase uniquement quand tu veux réinitialiser les contenus et réglages du simulateur, et retire les runtimes uniquement quand tu n’as vraiment plus besoin de cette version d’OS.
C’est le chemin de nettoyage le plus sûr : sépare les images de runtime de l’état des appareils, sépare le stockage simulateur de DerivedData, et garde le nettoyage Apple-side lié aux besoins réels de test au lieu d’une suppression aveugle de dossiers.
Questions fréquemment posées
Pourquoi le simulateur Xcode prend-il autant d'espace disque sur Mac ?
Le stockage du simulateur grossit parce qu'Xcode conserve les images de runtime, les appareils simulateur créés, les données d'appli dans ces simulateurs et d'autres états de développement Apple au fil du temps. Tester sur plusieurs versions d'iOS et types d'appareils fait rapidement gonfler l'empreinte.
Quelle est la différence entre les runtimes de simulateur et les données de simulateur ?
Les runtimes de simulateur sont les images de runtime OS qu'Xcode utilise pour démarrer les simulateurs pour des versions de plateforme spécifiques. Les données de simulateur sont l'état au niveau appareil dans les simulateurs créés, comme les applis installées, les données d'appli et les réglages.
Est-il sûr de supprimer les appareils simulateur indisponibles ?
En général oui. L'outil simctl d'Apple supporte explicitement la suppression des appareils indisponibles, qui sont des appareils non supportés par le SDK Xcode actuel. C'est souvent l'une des étapes de nettoyage de simulateur les plus sûres.
Est-il sûr de supprimer les runtimes de simulateur sur Mac ?
Parfois, mais seulement quand tu sais que tu n'as plus besoin de ce runtime pour les tests, les previews ou les cibles de projet plus anciennes. Supprimer un runtime est une décision plus importante qu'effacer le contenu du simulateur parce que ça supprime l'image de runtime elle-même.
Est-ce qu'effacer un simulateur supprime le runtime ?
Non. L'aide simctl d'Apple décrit erase comme effaçant les contenus et réglages d'un appareil. Ça réinitialise l'appareil simulateur, mais c'est différent de supprimer l'image de runtime derrière lui.