Le simulateur Xcode prend trop de place sur ton Mac ? Par quoi commencer

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éponse rapide

Qu’est-ce que CoreSimulator sur Mac ?

CoreSimulator est le dossier géré par Apple dans lequel Xcode conserve les runtimes de simulateur et les appareils simulés qu’il utilise pour compiler et tester des applications iOS, iPadOS, watchOS et tvOS. Sur la plupart des Mac il se trouve dans ~/Library/Developer/CoreSimulator, et il grossit à mesure que tu ajoutes des runtimes, crées des appareils et accumules des données d’application à l’intérieur.

Ce n’est pas un cache ordinaire. Le dossier mélange deux choses : des images de runtime dont tu dépends peut-être encore, et un état d’appareil que tu peux souvent réinitialiser ou supprimer. C’est pour ça que « CoreSimulator prend des dizaines de gigaoctets » a plus d’une réponse.

Puis-je supprimer le dossier CoreSimulator ?

Pas à l’aveugle en un bloc. Tu récupères l’essentiel de l’espace en vidant la bonne couche plutôt qu’en effaçant le chemin entier.

Supprimer ~/Library/Developer/CoreSimulator à la main oblige Xcode à reconstruire l’état des simulateurs et fait disparaître des runtimes dont tu as encore besoin. L’équivalent sûr consiste à laisser l’outil simctl d’Apple retirer ce qui est vraiment jetable :

• supprimer les appareils que le SDK courant ne prend plus en charge avec xcrun simctl delete unavailable ;
• réinitialiser le contenu et les réglages d’un appareil avec xcrun simctl erase <device> quand le problème vient d’un état d’application gonflé ;
• supprimer un runtime avec xcrun simctl runtime delete seulement quand tu ne testes plus cette version d’OS.

L’espace de CoreSimulator se récupère couche par couche, pas en effaçant le dossier en espérant que Xcode s’en remette.

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.

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 runtimes

Si 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 CoreSimulator qui ne correspond pas à tes besoins de test actuels.

C’est le moment où le nettoyage commence à devenir rationnel au lieu de réactif.

Comment supprimer des simulateurs dans Xcode, étape par étape

Quand tu veux supprimer des simulateurs et pas seulement les inspecter, tu as deux chemins sûrs : l’interface de Xcode et la ligne de commande simctl. Les deux retirent les vieux simulateurs sans toucher aux runtimes qui te servent encore.

Depuis l’application Xcode :

1. Ouvre Xcode et va dans Window → Devices and Simulators.
2. Sélectionne l’onglet Simulators.
3. Fais un clic droit sur un simulateur devenu inutile et choisis Delete, ou utilise Delete Unavailable Simulators pour les appareils que le SDK courant ne prend plus en charge.

Depuis la ligne de commande :

# lister d'abord
xcrun simctl list devices

# supprimer tous les appareils marqués unavailable par le SDK courant
xcrun simctl delete unavailable

# supprimer un appareil précis par son UDID
xcrun simctl delete <device-UDID>

Supprimer les simulateurs indisponibles reste la première passe la plus propre, parce qu’elle ne retire que des appareils déjà signalés comme non pris en charge par Apple. Supprimer un appareil précis retire cette instance de simulateur mais laisse son image de runtime en place, donc tu peux le recréer si un projet en a besoin.

Si le but est de récupérer de l’espace, commence ici avant de penser aux runtimes : un appareil supprimé se recrée vite, un runtime supprimé engage davantage.

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 unavailable

Ce 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.

Où CoreSimulator se trouve sur le disque

Deux chemins comptent quand tu audites le stockage des simulateurs.

~/Library/Developer/CoreSimulator/Devices contient les appareils simulés que tu as créés. Chaque appareil est un dossier nommé d’après son UDID, et le data/ à l’intérieur porte les applications installées, leurs données et les réglages. C’est cette couche que simctl erase réinitialise et que simctl delete retire.

Le dossier /Library/Developer/CoreSimulator au niveau système porte le côté runtime. Selon ta version de Xcode, les images de runtime se trouvent sous Profiles/Runtimes en bundles .simruntime, ou Xcode les gère comme des runtimes téléchargeables que xcrun simctl runtime list affiche. Ce que tu retires là touche tous les comptes utilisateur du Mac, donc traite-le comme la décision la plus lourde.

du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime list

Si Devices domine, ton problème vient de l’état accumulé des appareils et de ceux que le SDK courant ne prend plus en charge. Si le dossier système domine, il vient des images de runtime.

Peut-on déplacer CoreSimulator sur un disque externe ?

La question arrive quand le disque interne est petit et que le dossier des simulateurs dépasse 40 Go. Apple ne fournit aucun réglage pris en charge pour le déplacer, alors les développeurs passent par un lien symbolique : copier ~/Library/Developer/CoreSimulator sur le volume externe, vérifier la copie, retirer l’original, puis relier l’ancien chemin au nouveau.

Ce que tu acceptes en échange :

• Xcode ne peut pas démarrer de simulateur quand le disque n’est pas monté, parce que le chemin disparaît ;
• sur un disque USB alimenté par le bus, les simulateurs démarrent plus lentement que sur le SSD interne ;
• une mise à jour de Xcode ou du SDK peut recréer une partie de la structure au chemin d’origine ;
• la sauvegarde et les permissions se comportent différemment sur un volume externe.

Mesure l’espace récupérable avant de déplacer tout le dossier. Supprimer les appareils indisponibles et les runtimes que tu ne testes plus libère souvent plus que le déplacement ne rapporte, et la configuration reste celle qu’Apple prend en charge.

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 :

1. Liste les appareils et runtimes après des changements majeurs de Xcode ou SDK.
2. Supprime les appareils indisponibles quand ils apparaissent.
3. Réinitialise les appareils simulateur obsolètes quand le problème est l’état des appareils, pas l’inventaire des runtimes.
4. Révis l’utilisation des runtimes avant de retirer une version d’OS entièrement.
5. Compare CoreSimulator, DerivedData et Archives ensemble 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

• DerivedData est surtout de l’output de build généré.
• Archives préservent les livrables et l’historique de build.
• CoreSimulator mé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.