Xcode DerivedData ocupando muito espaço no Mac? O que limpar primeiro

Se tu desenvolve apps no Mac todos os dias, DerivedData eventualmente se torna uma daquelas pastas que tu sabe que é importante, mas também que espera que alguém já tenha limpado.

Aí um dia a pasta está enorme, o disco está apertado, o Xcode parece mais pesado que o normal e a pergunta de limpeza se torna imediata: tu pode apagá-la com segurança, ou está prestes a transformar teu dia de trabalho em um caos de rebuild?

A resposta curta é que DerivedData geralmente é um dos alvos de limpeza do Xcode mais seguros. A resposta mais longa é que desenvolvedores frequentemente se concentram demais no DerivedData e deixam de ver o resto da pegada do ecossistema Apple ali perto.

Resposta rápida

O que geralmente é seguro limpar versus o que precisa de cautela

O que o DerivedData do Xcode realmente é

DerivedData é onde o Xcode guarda a saída gerada de build e dados de trabalho relacionados para fluxos de desenvolvimento. Em termos práticos, isso geralmente significa produtos de build, índices, arquivos intermediários, saída relacionada a previews e outros artefatos gerados que ajudam o Xcode a ser mais rápido na próxima vez que tu faz build ou abre o projeto.

É por isso que a pasta cresce tão facilmente. Cada projeto, target, combinação de branch, SDK e fluxo de simulador adiciona mais estado gerado ao longo do tempo.

Isso também explica por que desenvolvedores tratam DerivedData de forma diferente de arquivos comuns de projeto:

• não é a fonte de verdade para o código do teu app;
• existe para economizar tempo de build e indexação;
• deve ser regenerado quando necessário.

Esse comportamento de regeneração é o motivo pelo qual DerivedData geralmente é classificado como um alvo de limpeza mais seguro do que muitos caminhos controlados por apps ou pelo sistema.

Por que o DerivedData do Xcode fica tão grande

A resposta mais simples é acúmulo.

Um app ativo já pode gerar muita saída de build. Múltiplos apps, múltiplos branches, previews, execuções de simulador, builds de teste e histórico de resolução de pacotes podem empurrar a pasta muito além do que a maioria dos desenvolvedores espera.

Motivos comuns para DerivedData inchar:

• vários projetos ativos compartilham a mesma máquina;
• pastas antigas por projeto permanecem muito depois de o projeto ter deixado de importar;
• trabalho pesado em preview, indexação e simulador gera churn extra;
• ambientes de Xcode de longa vida mantêm saída de build antiga por mais tempo do que tu imagina;
• tu limpa outras coisas mas nunca toca em artefatos de dev Apple gerados.

O ponto importante é que DerivedData grande não é incomum em um Mac de desenvolvedor. Vira um problema apenas quando tu assume que a resposta certa é sempre “apagar tudo agora” sem verificar o que mais está grande e se o momento é bom.

O que mais perto do DerivedData costuma ficar grande

Desenvolvedores frequentemente culpam o DerivedData porque é familiar, mas é apenas um perfil na pegada do ecossistema Apple.

Os perfis atuais de dev Apple do StorageRadar separam essas áreas adjacentes ao Xcode porque não compartilham o mesmo modelo de risco:

É por isso que um scan completo de Developer Folder é mais útil do que visão em túnel em um diretório. Se DerivedData tem 12 GB mas CoreSimulator tem 35 GB e Archives tem 18 GB, o plano de limpeza muda completamente.

Pastas de desenvolvedor Apple que frequentemente crescem com o DerivedData

Archives

Archives não são apenas espaço temporário gerado. Podem representar entregáveis que tu pode realmente querer manter. É por isso que pertencem a uma categoria de limpeza diferente do DerivedData.

CoreSimulator

Dados de simulador podem silenciosamente ultrapassar o DerivedData, especialmente se tu testa em muitos runtimes ou mantém estado de simulador por muito tempo. Não é apenas uma pasta de cache descartável. Pode conter ambientes de simulador que tu ainda se importa.

Se o armazenamento de simulador é o problema real, o guia focado em Simulador do Xcode ocupando espaço no Mac? O que limpar primeiro vai mais fundo em runtimes, estado de dispositivo e contrapartidas de limpeza.

iOS DeviceSupport

Esta área cresce conforme diferentes versões de dispositivos físicos e assets de suporte se acumulam. É frequentemente negligenciada porque é menos famosa que o DerivedData, mas ainda grande o suficiente para importar.

Caches relacionados a pacotes

Estes podem ser alvos de limpeza mais seguros do que dados de simulador ou archive, mas ainda são separados do DerivedData. Se tu está buscando espaço recuperável a sério, trate cada perfil como seu próprio problema de limpeza.

Quando limpeza seletiva é melhor do que apagar tudo

O reflexo padrão do desenvolvedor é frequentemente limpeza total: apagar a pasta inteira, deixar o Xcode reconstruir, seguir em frente.

Isso pode ser fine, mas nem sempre é a melhor jogada.

Limpeza seletiva geralmente é melhor quando:

• apenas alguns projetos antigos são responsáveis pela maior parte do tamanho;
• tu precisa de builds rápidos e previsíveis para os teus apps ativos atuais;
• tu não quer forçar uma reindexação completa em tudo hoje;
• tu suspeita que branches antigos ou workspaces aposentados são o problema real, não projetos atuais.

Uma limpeza total é mais razoável quando:

• a pasta inteira está inchada através de muitos projetos antigos;
• tu quer um reset limpo da saída gerada;
• a lentidão atual vale a pena trocar por uma janela controlada de rebuild;
• tu suspeita que o estado gerado global é parte do problema.

Isso é realmente uma decisão de timing disfarçada de decisão de armazenamento. A economia de espaço pode ser similar, mas o custo de fluxo de trabalho é diferente.

Como limpar o DerivedData do Xcode sem criar um caos de rebuild

O objetivo seguro não é apenas “liberar espaço”. O objetivo seguro é “liberar o espaço certo enquanto mantém as próximas horas de desenvolvimento previsíveis”.

1. Revise o panorama completo de desenvolvedor primeiro

Comece pela Developer Folder se tu a tiver, não pelo DerivedData isoladamente. O ponto é ver se a saída do Xcode é realmente o problema dominante ou se outros perfis de dev Apple são maiores.

Se a pegada de desenvolvedor mais ampla é o problema, limpar apenas DerivedData pode recuperar menos do que tu espera.

2. Separe saída gerada segura de perfis de cautela

Essa distinção importa:

• DerivedData e caches geralmente são alvos de limpeza do tipo seguro porque são gerados;
• Archives, CoreSimulator e iOS DeviceSupport merecem mais cautela porque podem preservar artefatos, runtimes ou estado que tu ainda precisa.

Quando tu mistura esses dois grupos, “limpeza de desenvolvedor” se torna apenas mais uma purga perigosa de pastas.

3. Decida entre limpeza seletiva e total deliberadamente

Antes de remover qualquer coisa, responda estas perguntas:

1. Os maiores diretórios de DerivedData estão ligados a projetos antigos ou ativos?
2. Tu precisa de builds e indexação rápidos hoje?
3. Os perfis vizinhos são realmente maiores que o DerivedData?
4. Uma janela de rebuild completo vai prejudicar teu sprint, demo ou trabalho de release atual?

Essa revisão rápida previne a maioria das limpezas totais desnecessárias.

4. Espere custo de rebuild, não perda de dados

Para DerivedData, o custo normal de limpeza geralmente é:

• próximo build mais lento;
• reconstruções de índice;
• previews ou inicialização de simulador mais pesados;
• atrito temporário enquanto a saída gerada retorna.

Isso é muito diferente de apagar dados de suporte do app, archives que tu ainda precisa ou estado de simulador que te importava. Limpeza de desenvolvedor só permanece segura quando tu mantém essas categorias separadas.

5. Use um fluxo de limpeza de desenvolvedor, não exclusão genérica de arquivos

Um navegador de arquivos comum pode dizer que algo é grande. Não pode dizer se o caminho é um perfil de dev conhecido, se está em uma categoria Safe ou Caution, quais são as consequências prováveis ou se um preflight guiado é necessário antes da limpeza.

Esse contexto ausente é o motivo pelo qual limpeza de dev não deve se transformar em limpeza comum de “maiores arquivos” quando os riscos aumentam.

Por que a limpeza do Xcode é diferente da limpeza de arquivos comum

Limpeza de arquivos comum faz uma pergunta simples: o que é grande?

Se tu quer o guia mais amplo cobrindo Xcode, Docker, setups pesados de SDK e perfis de risco de desenvolvedor, leia Como limpar caches de desenvolvedor no Mac com segurança.

Limpeza de desenvolvedor precisa fazer perguntas mais difíceis:

• isso é gerado ou autoral do usuário;
• este perfil é Safe, Caution ou Dangerous;
• preciso de Dry Run antes de confiar no tamanho recuperável;
• preciso de Guided Preflight porque o perfil tem risco de fluxo de trabalho;
• quais bloqueios, avisos ou consequências devo revisar primeiro?

Essa diferença está incorporada no modelo Dev Cleanup do StorageRadar. Ele não opera como exclusão arbitrária. Trabalha a partir de perfis de desenvolvedor conhecidos e uma política de risco.

Por exemplo, os perfis atuais de dev Apple se dividem em:

• Xcode DerivedData como Safe;
• Xcode Archives como Caution;
• CoreSimulator Data como Caution;
• iOS DeviceSupport como Caution;
• SwiftPM Cache como Safe.

Isso é o oposto de caos de limpeza. É um fluxo de trabalho consciente do ecossistema que trata caches gerados de forma diferente de artefatos retidos e estado de simulador.

Onde o StorageRadar se encaixa

Isso muda o fluxo de trabalho prático:

• use Developer Folder quando toda a área de desenvolvedor Apple pode estar inchada;
• use Dev Cleanup quando tu quer limpeza consciente de perfis em vez de exclusão comum de arquivos;
• mantenha perfis Safe como DerivedData separados de perfis Caution como Archives e armazenamento relacionado a simuladores.

Essa distinção é todo o valor para uma máquina de desenvolvedor. O produto não está apenas dizendo que uma pasta é grande. Está dizendo que tipo de armazenamento de desenvolvedor é e que tipo de processo de limpeza merece.

O que não fazer

Evite esses erros comuns:

• não assuma que DerivedData é a única pasta do Xcode que vale a pena verificar;
• não apague Archives, CoreSimulator e iOS DeviceSupport como se tivessem o mesmo perfil de risco;
• não faça um reset completo logo antes de um prazo se o tempo de rebuild importa;
• não use lógica de maiores arquivos sozinha para artefatos de desenvolvedor que precisam de contexto de ecossistema;
• não confunda saída de build gerada com dados de projeto, entregáveis ou estado de simulador retido.

Se artefatos de dev Apple também estão fazendo o System Data parecer suspeitosamente grande, o guia complementar sobre System Data do Mac muito grande é a próxima leitura certa.

Conclusão

Se DerivedData está ocupando muito espaço no teu Mac, a parte tranquilizadora é que geralmente é um dos alvos de limpeza do Xcode mais seguros porque é saída gerada. A parte menos óbvia é que DerivedData raramente é toda a história.

A melhor decisão de limpeza vem de revisar a pegada de desenvolvedor mais ampla, separar perfis seguros de perfis de cautela e escolher limpeza seletiva ou total com base no teu fluxo de trabalho atual em vez de pânico.