Dans un simulateur Xcode de 9,8 Go, les apps prenaient 350 Mo

Mon simulateur de QA prenait 9,8 Go, et ce n’était pas à cause de mon app. Ses conteneurs d’apps prenaient 0,34 Go. iOS remplissait le reste : un cache d’instantanés des posters de l’écran verrouillé, le journal système, des ressources Siri et linguistiques téléchargées, et un cache de symboles. J’ai mesuré dix simulateurs sur mon Mac, et la part des apps restait faible sur chacun d’eux.

Réponse rapide

Où sont passés les 9,8 Go d’un simulateur

Lors de ma première mesure, un simulateur de QA occupait la moitié du dossier Devices. Un lecteur m’a demandé ce qu’il contenait, alors j’ai ouvert son dossier data. L’appareil est un simulateur iPhone 18 Pro sous iOS 27.0, et il était démarré pendant la mesure.

Containers contient les apps installées, leurs conteneurs de données, les groupes d’apps et les données des extensions. Tout ce que mon app et ses tests ont écrit tient dans ces 0,34 Go.

Dix simulateurs côte à côte

Mon Mac compte 53 simulateurs. Quarante-trois d’entre eux occupent environ 20 Mo chacun, la taille d’un appareil qui n’a jamais fait tourner d’app. Les dix autres sont ceux que j’utilise. Les tailles sont en Go.

Trois tendances ressortent :

• Containers n’a jamais dépassé 0,34 Go. Les apps que je teste ne sont qu’une erreur d’arrondi à côté des données système.
• MobileAsset apparaît sur chaque simulateur. Il allait de 0,17 à 2,03 Go.
• Le stockage des posters n’a grossi que sur les deux appareils iOS 27.0 démarrés. Sous iOS 18.6 et 26.5, il restait sous 0,05 Go. Deux appareils ne suffisent pas pour accuser iOS 27.0, mais l’écart est grand.

Ce que contient chaque dossier

PRBPosterExtensionDataStore : instantanés des posters de l’écran verrouillé

Le nom du dossier, tout comme GalleryCache et SnapshotCache.cachedb, est une chaîne du framework privé PosterBoard.framework du runtime de simulateur iOS 27.0. Le runtime fournit aussi une app système, PosterBoard.app, avec l’identifiant com.apple.PosterBoard. Dans le dossier, des sous-dossiers portent les identifiants des extensions de posters d’Apple : WeatherPoster, EmojiPoster, PhotosPosterProvider, KaleidoscopePoster et d’autres. Le guide d’Apple pour créer un écran verrouillé personnalisé cite Météo, Astronomie et les photos parmi les fonds d’écran de l’écran verrouillé.

Sur mon appareil de QA, le dossier contenait 6 776 fichiers. Parmi eux, 2 911 étaient des fichiers d’instantanés .atx d’environ 1 Mo chacun, nommés Composite.atx, Background.atx, Foreground.atx et Floating.atx, et ils totalisaient 2,9 Go. Sur l’iPad, les 939 fichiers d’instantanés avaient tous pour date de modification le jour de la mesure, donc l’appareil écrit ce cache pendant qu’il tourne. Je ne sais pas ce qui le fait grossir, et Apple ne le documente pas.

var/db/diagnostics et var/db/uuidtext : le journal système

Ces dossiers contiennent les données du système de journalisation unifiée. man log décrit un stockage de journaux comme une base de données de journalisation système semblable à celle de /var/db/diagnostics, avec à côté un répertoire uuidtext semblable à /var/db/uuidtext. Chaque simulateur garde sa propre copie dans son dossier de données. Sur mes appareils, elle allait de 0,01 à 2,07 Go, plus 0,49 Go de uuidtext sur l’appareil de QA.

private/var/MobileAsset : les ressources que télécharge iOS

Sur l’appareil de QA, AssetsV2 contenait des ensembles de ressources nommés d’après des fonctions de Siri et de langue :

Le simulateur les télécharge lui-même. Un développeur a signalé sur les Apple Developer Forums le même dossier qui grossissait de plusieurs dizaines de gigaoctets sous iOS 26.5, téléchargés par nsurlsessiond. Le fil n’a reçu aucune réponse.

com.apple.coresymbolicationd : cache de symboles

La page de manuel de coresymbolicationd le décrit comme un « démon qui gère le cache des symboles de débogage » des bibliothèques de l’OS. Il prenait 1,13 Go sur l’appareil de QA et presque rien sur les autres.

Ce que je fais d’un simulateur lourd

Je n’ouvre pas ces dossiers pour y supprimer des fichiers. Apple ne les documente pas, et je ne peux pas te dire ce que provoque sur un simulateur un stockage des posters ou un stockage de journaux à moitié supprimé. Les outils pris en charge agissent sur l’appareil entier :

• xcrun simctl erase <UDID> efface le contenu et les réglages et garde l’appareil. Éteins d’abord l’appareil.
• xcrun simctl delete <UDID> supprime l’appareil.
• xcrun simctl delete unavailable supprime les appareils que le SDK Xcode actuel ne prend plus en charge.

Effacer un appareil retire les apps installées, leurs données et tous les dossiers système ci-dessus, donc tu réinstalles l’app et tu te reconnectes. Garde les appareils dont l’état te sert encore pour un bug ou un test. Le stockage des posters, le journal et les ressources peuvent regrossir dès que l’appareil tourne à nouveau, donc un effacement fait gagner de la place mais ne règle pas la croissance.

Comment j’ai mesuré

J’ai mesuré le 26 octobre 2026 sur un Mac mini M4, sous macOS 27.0.1 avec Xcode 27.1. Toutes les commandes se contentent de lire des données :

xcrun simctl list devices --json
du -sk ~/Library/Developer/CoreSimulator/Devices/<UDID>/data
du -k -d 4 ~/Library/Developer/CoreSimulator/Devices/<UDID>/data | sort -rn | head -20
find ~/Library/Developer/CoreSimulator/Devices/<UDID>/data/Library/Application\ Support/PRBPosterExtensionDataStore -name '*.atx' | wc -l

Les tailles viennent de du, divisées deux fois par 1024, soit les mêmes unités binaires que celles qu’affiche du -h. Les dossiers de chaque ligne ne se recoupent pas, sauf Containers, qui inclut ses sous-dossiers. Les simulateurs démarrés continuent d’écrire, donc leurs chiffres bougent d’heure en heure.

En résumé

Un gros simulateur contient en général des données d’iOS, pas ton app. Sur mon Mac, les conteneurs d’apps prenaient de 0,07 à 0,34 Go par appareil, alors que les instantanés des posters, les journaux, les ressources téléchargées et les caches de symboles prenaient jusqu’à 9,5 Go. Mesure le dossier de données, garde les appareils dont l’état te sert, et efface ou supprime le reste avec simctl.