Insuffisance de disque du simulateur iOS 27 : nettoyer ou étendre en 2026 ?

Au 21 août 2026, Apple présente Xcode 27 Beta 4 comme la dernière chaîne d’outils de test listée dans les sources utilisées pour cette vérification. Le simulateur iOS 27 reste donc un environnement de test. Les menus, les prérequis et les problèmes propres aux versions bêta peuvent encore changer ; ne traitez pas une procédure observée sur un forum comme une règle générale.

Le premier diagnostic doit répondre à une question simple : quel objet consomme réellement l’espace ?

Cette distinction évite une erreur fréquente : supprimer tout le contenu d’un dossier Developer parce que son nom semble lié au développement. Un Runtime n’est pas un cache ordinaire. Une archive n’est pas un fichier temporaire. Un profil de signature n’est pas un résultat de compilation à recréer à la demande.

Dans macOS, commencez par l’interface de stockage afin d’obtenir une vue globale. Poursuivez dans Xcode avec la section Components, qui permet d’examiner les composants installés et de retirer ceux qui ne sont plus nécessaires. Apple décrit cette gestion dans sa procédure officielle d’installation et de suppression des composants Xcode.

Vous pouvez ensuite inspecter des chemins ciblés dans le Terminal. Remplacez <UTILISATEUR> par votre nom de compte et <PROJET> par le nom du projet. Ces commandes listent la taille ; elles ne suppriment rien :

du -sh "$HOME/Library/Developer/CoreSimulator/Devices"
du -sh "$HOME/Library/Developer/Xcode/DerivedData/<PROJET>-*"
du -sh "$HOME/Library/Developer/Xcode/Archives"

Le dossier des appareils simulés indique la taille des instances et de leurs données. DerivedData révèle plutôt l’accumulation des compilations et de l’indexation. Les archives doivent être inspectées séparément, car elles peuvent être nécessaires pour une distribution ou une restauration. Si votre projet utilise un autre emplacement de dépendances, mesurez également ce chemin au lieu de supposer que tout se trouve sous ~/Library.

Le moment de l’échec affine le diagnostic :

• un manque d’espace pendant le téléchargement désigne d’abord le Runtime ou le volume de travail temporaire ;
• un échec pendant la compilation oriente vers DerivedData, les dépendances ou les produits générés ;
• un simulateur qui ne démarre plus après une compilation réussie peut signaler un Runtime manquant, une instance corrompue ou un problème de compatibilité ;
• une tâche distante qui échoue après plusieurs exécutions suggère une accumulation : archives, journaux, appareils simulés ou caches.

Si vous maintenez une seule application, ne conservez pas toutes les versions « au cas où ». Établissez une fiche simple avec la version minimale supportée par votre application, la version principale de vos utilisateurs et la version iOS 27 nécessaire à l’adaptation en cours.

Dans ce profil, la priorité est la récupération sans surprise :

• gardez le Runtime utilisé par les tests quotidiens ;
• conservez seulement les appareils simulés nécessaires aux scénarios réellement exécutés ;
• supprimez les appareils créés pour une expérimentation terminée ;
• nettoyez DerivedData si votre dépôt permet de reconstruire les produits ;
• archivez ou exportez les livrables indispensables avant de retirer des archives locales ;
• ne supprimez pas les certificats, les profils de provisioning ou les secrets de signature avec les caches.

La suppression de DerivedData est généralement moins risquée que celle d’un Runtime, mais elle n’est pas sans conséquence opérationnelle. La prochaine ouverture du projet peut réindexer les fichiers. La prochaine compilation peut recréer les produits intermédiaires. Pour une équipe qui travaille sur un petit Mac, effectuez ce nettoyage lorsque vous pouvez absorber cette reconstruction, et non juste avant une livraison urgente.

Vous pouvez utiliser l’interface Xcode pour les composants. Pour les appareils simulés, préférez les commandes ou les menus qui ciblent une instance identifiée. Ne supprimez pas un répertoire parent au hasard. Avant toute action destructive, copiez la sortie des commandes du et notez le nom exact du Runtime, du périphérique ou de l’archive concerné.

Un testeur de compatibilité ne doit pas appliquer la même règle qu’un développeur qui ne vérifie qu’une version récente. La bonne question n’est pas « quelle version puis-je supprimer ? », mais « quelle couverture disparaît si je la supprime ? ».

Construisez votre matrice avec trois colonnes :

1. la version minimale officiellement prise en charge ;
2. la version la plus représentative de votre base d’utilisateurs ;
3. iOS 27, si votre application doit être adaptée ou validée dans cet environnement de test.

Ajoutez les appareils réellement nécessaires : format compact, grand écran, tablette si elle est prise en charge, et tout modèle qui expose une régression connue. Ne multipliez pas les instances identiques. Pour une application audio, vidéo ou de design, les scénarios peuvent nécessiter des jeux de données locaux volumineux ; mesurez ces données avant de conclure que le Runtime est seul responsable.

Apple distingue l’ajout de simulateurs supplémentaires et la gestion des composants nécessaires à leur exécution dans sa documentation sur les Simulator Runtime et les appareils simulés. La conséquence pratique est importante : supprimer un appareil simulé ne revient pas à désinstaller le système simulé. Vous libérez l’état de cette instance, mais vous ne récupérez pas nécessairement l’espace associé au Runtime.

À l’inverse, retirer le Runtime supprime la base système utilisée par plusieurs appareils compatibles. Vous pouvez donc libérer davantage d’espace, mais au prix d’une interruption de tous les tests liés à cette version jusqu’à sa réinstallation. Avant de retirer iOS 27, vérifiez les scripts de CI, les fichiers de configuration et les instructions de contribution qui pourraient sélectionner cette version explicitement.

Les développeurs qui alternent entre une version stable et Xcode 27 doivent procéder avec davantage de méthode. Deux applications Xcode peuvent utiliser des composants différents, tandis que les données des appareils simulés sont gérées dans l’environnement de développement sélectionné.

Commencez par vérifier l’outil actif :

xcode-select -p
xcodebuild -version

Ces commandes affichent respectivement le chemin de l’environnement de développement sélectionné et la version de l’outil de compilation. Elles ne changent rien au système. La documentation Apple consacrée aux réglages des outils en ligne de commande explique le rôle de xcode-select.

Ne confondez pas trois opérations :

• changer l’environnement actif avec xcode-select ;
• supprimer l’ancienne application Xcode ;
• retirer un Runtime ou un appareil simulé.

La première modifie le chemin utilisé par certains outils. La deuxième retire une application complète et peut casser un script qui la référence encore. La troisième agit sur l’environnement de simulation. Elles n’ont ni le même périmètre ni le même plan de retour arrière.

Pour la production, conservez un chemin reproductible vers l’outil stable tant que votre chaîne de signature, d’archivage et de distribution n’a pas été validée avec Xcode 27. Utilisez la bêta pour les tests d’adaptation, mais appliquez une règle de rétention plus stricte : si un composant peut être téléchargé de nouveau, il n’a pas nécessairement besoin de rester installé sur le Mac de publication.

Les notes de version officielles de Xcode 27 restent la référence pour les changements et limites de la bêta. Les témoignages isolés de permissions anormales ou de Runtime impossible à retirer peuvent servir de piste, mais ne justifient pas la suppression de répertoires protégés. Ne désactivez pas SIP et ne forcez pas l’effacement de dossiers système comme méthode normale de maintenance.

Sur un Mac distant utilisé comme iOS build server, le disque n’est pas seulement un problème de confort. Un remplissage peut empêcher une compilation, interrompre l’export d’une archive ou rendre une tâche non récupérable après redémarrage.

Avant d’automatiser quoi que ce soit, vérifiez :

• la persistance des données après redémarrage ;
• le compte qui exécute les tâches et ses permissions ;
• la présence du Runtime requis après une reconnexion ;
• la méthode de réinstallation des composants ;
• l’emplacement des archives et des journaux ;
• la possibilité de récupérer les dépendances sans intervention manuelle.

Planifiez ensuite une routine non destructive. Elle peut mesurer les répertoires, signaler un seuil de remplissage, faire tourner les journaux et supprimer uniquement les caches identifiés comme recréables. Elle ne doit pas effacer automatiquement un Runtime simplement parce qu’il est volumineux. Le nettoyage doit aussi laisser une trace : date, chemin, taille avant action, taille après action et résultat du build suivant.

Pour les archives, définissez une durée de conservation liée à votre publication, pas à la date de création du fichier. Apple détaille les conditions à vérifier lorsqu’un problème d’archivage survient et décrit le flux de distribution d’une application depuis une archive. Une archive qui semble ancienne peut encore être utile pour reproduire une livraison ou comparer un binaire.

Si le Mac distant sert à la fois de serveur de compilation et de poste de test avec simulateur, séparez les responsabilités lorsque la charge augmente. Une machine peut produire les archives ; une autre peut conserver les Runtimes et les données nécessaires aux régressions. Cette séparation réduit le risque qu’un nettoyage destiné à la CI détruise l’environnement de test.

Utilisez cette séquence, puis validez avec un projet réel :

• [ ] mesurer la capacité libre depuis macOS ;
• [ ] relever séparément les Runtime, les appareils simulés, DerivedData, les archives et les dépendances ;
• [ ] noter la phase exacte où l’espace manque ;
• [ ] écrire la matrice de versions et d’appareils réellement nécessaire ;
• [ ] supprimer d’abord les instances et caches hors matrice ;
• [ ] utiliser Components pour les Runtime qui ne sont plus requis ;
• [ ] vérifier les chemins Xcode actifs si une version stable et une bêta coexistent ;
• [ ] contrôler la persistance et les permissions sur un Mac distant ;
• [ ] relancer la récupération des dépendances ;
• [ ] démarrer le simulateur ;
• [ ] compiler l’application ;
• [ ] créer une archive ;
• [ ] contrôler la distribution ou l’export prévu ;
• [ ] mesurer de nouveau l’espace après cette reconstruction.

Le test n’est pas réussi parce que le Finder affiche davantage d’espace libre. Il est réussi lorsque le dépôt se reconstruit, que le simulateur démarre, que l’archive est créée et que la prochaine exécution distante peut reprendre sans manipulation imprévue.

Votre choix final peut suivre cette règle :

• Nettoyer si l’occupation provient surtout d’instances, de DerivedData ou de dépendances récupérables qui ne sont pas nécessaires à la matrice ;
• Étendre si les Runtime, archives et données de test sont tous justifiés, mais ne cohabitent plus avec les constructions régulières ;
• Migrer si les tâches sont interrompues, si les composants ne persistent pas ou si la maintenance exige des interventions répétées.

Pour un environnement distant, vous pouvez comparer les options de Mac distant de CALMVPS après avoir mesuré votre charge réelle. Une formule courte sert à valider la persistance, la reconstruction et les besoins de test avant d’engager un usage plus long. Les modalités de commande en français sont à examiner seulement après cette validation technique.

Le Runtime iOS 27 peut-il être retiré ?

Oui, si la version ne figure plus dans vos tests actifs et si vous acceptez de la télécharger de nouveau lorsque le besoin reviendra. Utilisez Components plutôt qu’un effacement manuel. Vérifiez auparavant les scripts CI, les branches de maintenance et les scénarios de reproduction. Dans une campagne d’adaptation en cours, conserver le Runtime évite de détruire l’environnement avant la prochaine régression.

Appareil simulé et Runtime ne désignent pas la même chose

Un appareil simulé est une instance avec ses données, tandis que le Runtime fournit le système iOS partagé par les appareils correspondants. Supprimer l’instance efface son état de test et peut libérer une partie de l’espace. Supprimer le Runtime retire la base système entière. Cette seconde action peut rendre plusieurs appareils indisponibles jusqu’à la réinstallation du composant.

Que devient le projet après le nettoyage de DerivedData ?

Le code source, les fichiers suivis par votre gestionnaire de versions et les certificats ne devraient pas être concernés par un nettoyage ciblé de DerivedData. En revanche, Xcode devra recréer des index et des produits intermédiaires. La compilation suivante peut donc être plus longue. Ne traitez pas les archives, les profils de provisioning ou les secrets comme des données équivalentes à DerivedData.

Comment stabiliser un Mac distant fréquemment rempli ?

Mesurez les catégories séparément avant de programmer une suppression. Faites tourner les journaux, limitez les caches recréables et conservez les archives nécessaires à la publication. Testez ensuite un redémarrage, la récupération des dépendances, le lancement du simulateur et un archivage complet. Si les Runtime indispensables remplissent durablement le volume, augmentez la capacité ou séparez le serveur de compilation de l’hôte de test.

Après le diagnostic, comparez la fréquence de vos nettoyages avec le coût d’une interruption. Une machine locale reste adaptée si vous avez besoin d’interfaces physiques, d’une charge lourde stable ou d’un accès permanent sans dépendance réseau. En revanche, un Mac local sous-dimensionné oblige à supprimer des Runtime nécessaires, à déplacer des archives et à interrompre les tests. Un environnement distant mal dimensionné rencontre les mêmes limites, avec en plus les risques de persistance, de permission et de reconnexion. Si votre projet doit conserver iOS 27, plusieurs versions de test et une chaîne d’archivage continue, un Mac distant CALMVPS de capacité adaptée peut être plus cohérent qu’un cycle de suppressions répétées. Consultez les formules disponibles pour votre environnement de développement, puis validez d’abord le comportement de votre projet réel avant de prolonger la location.