Dentro de um simulador do Xcode de 9,8 GB: os apps ocupavam 350 MB

Meu simulador de QA ocupava 9,8 GB, e o motivo não era o meu app. Os contêineres de apps dele ocupavam 0,34 GB. O iOS preenchia o resto: um cache de snapshots dos pôsteres da Tela Bloqueada, o log do sistema, assets baixados da Siri e de idiomas e um cache de símbolos. Medi dez simuladores no meu Mac, e a parte dos apps ficou pequena em todos eles.

Resposta rápida

Para onde foram 9,8 GB em um simulador

Na minha primeira medição, um simulador de QA ocupava metade da pasta Devices. Um leitor perguntou o que havia dentro dele, então abri a pasta data. O dispositivo é um simulador de iPhone 18 Pro com iOS 27.0, e estava inicializado durante a medição.

Containers guarda os apps instalados, os contêineres de dados deles, os app groups e os dados de extensões. Tudo o que meu app e os testes dele gravaram cabe nesses 0,34 GB.

Dez simuladores lado a lado

Meu Mac tem 53 simuladores. Quarenta e três deles ocupam cerca de 20 MB cada, o tamanho de um dispositivo que nunca rodou um app. Os outros dez são os que eu uso. Os tamanhos estão em GB.

Três padrões se destacam:

• Containers nunca passou de 0,34 GB. Os apps que eu testo são um erro de arredondamento perto dos dados do sistema.
• O MobileAsset aparece em todos os simuladores. Ele variou de 0,17 a 2,03 GB.
• O repositório de pôsteres só ficou grande nos dois dispositivos com iOS 27.0 inicializados. No iOS 18.6 e no 26.5, ficou abaixo de 0,05 GB. Dois dispositivos não bastam para culpar o iOS 27.0, mas a diferença é grande.

O que cada pasta guarda

PRBPosterExtensionDataStore: snapshots dos pôsteres da Tela Bloqueada

O nome da pasta, junto com GalleryCache e SnapshotCache.cachedb, é uma string no PosterBoard.framework privado do runtime do simulador do iOS 27.0. O runtime também traz um app do sistema, PosterBoard.app, com o identificador com.apple.PosterBoard. Dentro da pasta, as subpastas levam os IDs das extensões de pôster da Apple: WeatherPoster, EmojiPoster, PhotosPosterProvider, KaleidoscopePoster e outras. O guia da Apple para criar uma Tela Bloqueada personalizada lista Tempo, Astronomia e fotos entre os papéis de parede da Tela Bloqueada.

No meu dispositivo de QA, a pasta tinha 6.776 arquivos. Desses, 2.911 eram arquivos de snapshot .atx de cerca de 1 MB cada, com os nomes Composite.atx, Background.atx, Foreground.atx e Floating.atx, e somavam 2,9 GB. No iPad, todos os 939 arquivos de snapshot tinham como data de modificação o dia da medição, então o dispositivo grava esse cache enquanto roda. Não sei o que o faz crescer, e a Apple não documenta isso.

var/db/diagnostics e var/db/uuidtext: o log do sistema

Essas pastas guardam os dados do sistema de log unificado. O man log descreve um repositório de logs como um banco de dados de log do sistema igual ao de /var/db/diagnostics, com um diretório uuidtext igual a /var/db/uuidtext ao lado. Cada simulador mantém a própria cópia dentro da pasta de dados. Nos meus dispositivos, ela variou de 0,01 a 2,07 GB, mais 0,49 GB de uuidtext no dispositivo de QA.

private/var/MobileAsset: assets que o iOS baixa

No dispositivo de QA, AssetsV2 tinha conjuntos de assets com nomes de recursos da Siri e de idioma:

O simulador baixa esses assets por conta própria. Um desenvolvedor nos Apple Developer Forums relatou a mesma pasta crescendo dezenas de gigabytes no iOS 26.5, baixados pelo nsurlsessiond. A thread não tem resposta.

com.apple.coresymbolicationd: cache de símbolos

A man page do coresymbolicationd o descreve como um “daemon para gerenciar o cache de símbolos de depuração” das bibliotecas do sistema operacional. O cache ocupava 1,13 GB no dispositivo de QA e quase nada nos outros.

O que eu faço com um simulador pesado

Não abro essas pastas para apagar arquivos. A Apple não as documenta, e não sei dizer o que um repositório de pôsteres ou de logs apagado pela metade faz com um simulador. As ferramentas suportadas trabalham com o dispositivo inteiro:

• xcrun simctl erase <UDID> limpa o conteúdo e os ajustes e mantém o dispositivo. Desligue o dispositivo antes.
• xcrun simctl delete <UDID> remove o dispositivo.
• xcrun simctl delete unavailable remove os dispositivos que o SDK atual do Xcode não suporta mais.

Um erase leva embora os apps instalados, os dados deles e todas as pastas do sistema acima, então você reinstala o app e faz login de novo. Guarde os dispositivos cujo estado você ainda precisa para um bug ou um teste. O repositório de pôsteres, o log e os assets podem voltar a crescer quando o dispositivo rodar de novo, então um erase libera espaço, mas não corrige o crescimento.

Como medi

Medi em 26 de outubro de 2026, em um Mac mini com M4, macOS 27.0.1 e Xcode 27.1. Todos os comandos só leem dados:

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

Os tamanhos vêm do du, divididos por 1024 duas vezes, nas mesmas unidades binárias que o du -h mostra. As pastas de cada linha não se sobrepõem, exceto que Containers inclui as próprias subpastas. Simuladores inicializados continuam gravando, então os números deles mudam de hora em hora.

Conclusão

Um simulador grande costuma guardar dados do iOS, não do seu app. No meu Mac, os contêineres de apps ocupavam de 0,07 a 0,34 GB por dispositivo, enquanto snapshots de pôsteres, logs, assets baixados e caches de símbolos chegavam a 9,5 GB. Meça a pasta de dados, guarde os dispositivos cujo estado você precisa e redefina ou remova o resto com simctl.