Exclua o DerivedData do Xcode e os caches de desenvolvimento com segurança
Equipe AskClean · Atualizado 2026-11-02
O DerivedData é a pasta de trabalho do Xcode para produtos de build e índices, e pode chegar, sem você perceber, a dezenas de gigabytes. É seguro excluí-lo: encerre o Xcode, remova o conteúdo de ~/Library/Developer/Xcode/DerivedData e o Xcode recria tudo no próximo build. Este guia mostra como fazer isso e também trata de simuladores, archives e caches de pacotes.
O que é o DerivedData e por que ele cresce tanto
O DerivedData é onde o Xcode guarda tudo o que deriva do seu código-fonte: objetos intermediários de build, produtos compilados, caches de módulos, índices de símbolos usados pelo autocompletar e pelo recurso de ir para a definição, e logs de build. Por padrão, ele fica em ~/Library/Developer/Xcode/DerivedData, com uma subpasta para cada projeto ou workspace que você já abriu.
Ele cresce por um motivo estrutural: o Xcode cria uma pasta no DerivedData para cada projeto que você abre — inclusive clones avulsos que você compilou uma vez e nunca mais abriu — e não as remove por conta própria. Cada pasta guarda produtos de build separados por configuração e destino (Debug e Release, simulador e dispositivo); por isso, meça as subpastas dos projetos em vez de supor quanto espaço o seu Mac vai recuperar.
Tudo o que está ali pode ser recriado, por definição — é exatamente o que “derived” (derivado) quer dizer. Excluir o DerivedData nunca toca no seu código-fonte, nas configurações do projeto nem em nada que esteja sob controle de versão. O único custo é tempo: o próximo build de cada projeto será completo, do zero, e a indexação vai rodar de novo em segundo plano por alguns minutos.
Como excluir o DerivedData
O comando Clean Build Folder do Xcode (Product > Clean Build Folder, ou Shift-Command-K) limpa apenas os produtos de build do projeto aberto — é útil para consertar um build com comportamento estranho, mas quase não faz diferença no espaço em disco. Para recuperar espaço de verdade, exclua as próprias pastas do DerivedData: abra-as a partir de Settings > Locations no Xcode ou vá até elas no Finder, ou então remova-as pelo Terminal. Os três caminhos chegam ao mesmo resultado.
Excluir por projeto é a opção cirúrgica: mantenha o DerivedData dos dois ou três projetos que você compila todo dia e remova as pastas de todo o resto. Excluir tudo é a opção rápida e também funciona — você só paga de uma vez o custo de recompilar todos os projetos.
- Encerre o Xcode primeiro. Excluir o DerivedData com o Xcode aberto pode confundir o indexador, e os arquivos que o Xcode mantém abertos podem não ser excluídos de forma limpa.
- Encontre a pasta: no Xcode, abra Settings > Locations e clique na setinha ao lado do caminho do DerivedData para mostrar a pasta no Finder. Ou, no Finder, pressione Command-Shift-G (Ir para a Pasta) e digite ~/Library/Developer/Xcode/DerivedData.
- Ordene as subpastas dos projetos por tamanho, selecione as que quer remover (ou Command-A para todas) e mova-as para o Lixo. Passar primeiro pelo Lixo é o hábito mais seguro — dá para restaurar na hora se você mudar de ideia.
- Se preferir o Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData exclui tudo de uma só vez. É mais rápido que o Finder para pastas muito grandes, mas leia a nota abaixo antes de usar.
- Reabra o Xcode e compile. O primeiro build de cada projeto vai demorar bem mais, e “Indexing” vai aparecer na barra de atividade por um tempo — os dois custos só acontecem uma vez.
Cuidado com o rm -rf: ele não passa pelo Lixo e exclui permanentemente, sem possibilidade de desfazer. Digite o caminho exato, nunca use sudo nesta tarefa e, se você não se sente à vontade no Terminal, use o Finder, que faz o mesmo trabalho de forma reversível.
Limpe runtimes antigos de simulador
Os simuladores costumam ser outra grande categoria no armazenamento de desenvolvimento. Cada runtime de iOS, watchOS ou tvOS baixado ocupa seu próprio espaço, e cada dispositivo simulado guarda dados em ~/Library/Developer/CoreSimulator/Devices. Se você já passou por algumas atualizações do Xcode, revise os runtimes de versões do sistema que saíram da sua matriz de testes.
O ganho mais rápido vem do comando de limpeza integrado: execute xcrun simctl delete unavailable no Terminal. Ele exclui todos os dispositivos de simulador marcados como indisponíveis (unavailable) — em geral, órfãos deixados por runtimes removidos e por versões antigas do Xcode —, junto com os apps e os dados que estão neles. Revise antes a lista com xcrun simctl list devices, principalmente se você mantém mais de um Xcode instalado.
Para os runtimes em si, abra Settings > Components no Xcode (Platforms no Xcode 14–15). Ali aparece cada runtime de simulador instalado, com o tamanho; selecione um antigo e exclua. Mantenha só o runtime mais recente de cada plataforma, a menos que você ainda teste em versões mais antigas do sistema.
Também dá para remover dispositivos simulados um a um em Window > Devices and Simulators: abra a aba Simulators, clique com o botão direito em qualquer dispositivo que você não usa — como aqueles seis modelos de iPhone duplicados, cheios de dados de testes antigos — e escolha Delete. Os dados e apps salvos em cada dispositivo são apagados junto.
Archives, DeviceSupport e caches do Xcode
Os archives se acumulam em ~/Library/Developer/Xcode/Archives toda vez que você usa Product > Archive para distribuir um build. Cada archive contém um build completo do app e seus símbolos de depuração (dSYM), muitas vezes de 100 MB a 1 GB cada um. Antes de excluir, pese o que está em jogo: são esses dSYMs que permitem simbolizar os relatórios de falhas daquele build exato. Mantenha os archives das versões ainda ativas na App Store ou no TestFlight (ou confirme que o App Store Connect tem os dSYMs) e exclua o resto — o caminho mais seguro é o Organizer do Xcode (Window > Organizer > Archives), onde você revisa e exclui cada um sabendo do que se trata.
O iOS DeviceSupport, em ~/Library/Developer/Xcode/iOS DeviceSupport, guarda símbolos de depuração que o Xcode copia de cada iPhone ou iPad físico que você já conectou — uma pasta por versão do iOS, normalmente com 2 a 5 GB cada. As pastas de versões do iOS que nenhum dos seus dispositivos usa mais são puro peso morto: exclua-as e, se um dia você conectar de novo um dispositivo com aquela versão, o Xcode simplesmente copia os símbolos outra vez (você verá “Preparing debugger support” uma vez). Há pastas equivalentes para dispositivos watchOS e tvOS.
O Xcode também mantém caches próprios em ~/Library/Caches/com.apple.dt.Xcode, e os simuladores mantêm os deles em ~/Library/Developer/CoreSimulator/Caches. Os dois são recriados quando necessário, mas limpe-os só com o Xcode e o app Simulator encerrados, e não mexa em arquivos de cache do CoreSimulator que você não reconhece.
Caches de gerenciadores de pacotes (SwiftPM, CocoaPods, npm, Homebrew)
Os gerenciadores de pacotes guardam as dependências baixadas para que as próximas instalações sejam rápidas. Isso é útil, mas pode virar uma categoria grande de uso do disco numa máquina com anos de projetos. Esses caches de download podem ser recriados, mas a próxima instalação terá de baixar os pacotes de novo.
O Swift Package Manager guarda os pacotes baixados em ~/Library/Caches/org.swift.swiftpm, e os checkouts resolvidos de cada projeto ficam dentro da pasta dele no DerivedData — então limpar o DerivedData já remove esses checkouts. O cache compartilhado pode ser excluído pelo Finder ou com rm -rf nesse caminho.
O CocoaPods mantém os pods baixados em ~/Library/Caches/CocoaPods. O jeito certo de esvaziá-lo é o comando próprio: pod cache clean --all. As pastas Pods dos seus projetos não são tocadas; só o cache de downloads é removido.
O cache do npm fica em ~/.npm e pode chegar a vários gigabytes numa máquina com muito JavaScript. Execute npm cache clean --force para esvaziá-lo (o npm exige a flag porque o cache se corrige sozinho e normalmente não precisa ser limpo; excluí-lo é seguro — os pacotes simplesmente são baixados de novo na próxima instalação). Quem usa pnpm pode executar pnpm store prune.
O Homebrew acumula downloads antigos e versões desatualizadas de pacotes. brew cleanup remove versões obsoletas e downloads antigos e, quando executado sem indicar pacotes, também desinstala dependências de que nada mais precisa (a menos que a variável HOMEBREW_NO_AUTOREMOVE esteja definida); brew cleanup --prune=all também esvazia todo o cache de downloads. Execute antes brew cleanup -n se quiser ver, sem apagar nada, a lista do que seria removido.
Automatize a limpeza
Tudo o que está acima funciona, mas limpar o acúmulo de desenvolvimento é enxugar gelo: o DerivedData volta em uma semana de trabalho normal, os caches voltam a encher e cada atualização do Xcode deixa mais um runtime para trás. Se você prefere não repetir seis procedimentos manuais todo mês, esta é a parte que vale automatizar — com uma ferramenta que mostra o próprio raciocínio, em vez de excluir em massa sem dizer nada.
O AskClean trata os arquivos de desenvolvimento como categorias próprias: uma varredura detalha o DerivedData do Xcode por projeto, os runtimes antigos de simulador (lidos via simctl, mantendo o mais recente de cada plataforma), os arquivos de DeviceSupport e os caches de gerenciadores de pacotes de npm, SwiftPM, cargo, uv e outros. Ele também encontra os devoradores de espaço mais recentes — os modelos de IA locais —, listando os modelos do Hugging Face um a um e a biblioteca de modelos do Ollama como um único item, todos desmarcados por padrão.
Cada item vem com uma explicação — o que é, se dá para recriar, o que a exclusão custa — e nada é executado até você confirmar. Os itens confirmados são excluídos permanentemente, sem passar pelo Lixo; por isso, revise cada seleção antes de confirmar. Seu código-fonte e sua biblioteca de fotos nunca são tocados. É a mesma lista de tarefas deste guia, sem a hora de trabalho no Terminal.
O que pode ser recriado — e o que não pode
Esta tabela mostra os limites de cada exclusão; não é uma promessa de economia. Meça o seu Mac antes e depois de qualquer ação — o script de diagnóstico somente leitura do guia de armazenamento do simulador do Xcode mostra essas pastas sem alterar nada.
| Categoria | Local padrão | Consequência da exclusão |
|---|---|---|
| DerivedData | ~/Library/Developer/Xcode/DerivedData | É recompilado e reindexado; o código-fonte e o histórico do Git não são tocados. |
| Dispositivos do simulador | ~/Library/Developer/CoreSimulator/Devices | Os apps e dados de teste dos dispositivos virtuais escolhidos são perdidos; exclua pelo simctl ou pelo Xcode. |
| Archives | ~/Library/Developer/Xcode/Archives | Pode remover dSYMs necessários para simbolizar falhas; revise antes no Organizer. |
| DeviceSupport | ~/Library/Developer/Xcode/iOS DeviceSupport | Os símbolos de depuração são copiados de novo se um dispositivo com essa versão do sistema for reconectado. |
Perguntas frequentes
É seguro excluir o DerivedData?
Sim — é uma das exclusões grandes mais seguras num Mac. O DerivedData contém apenas arquivos que o Xcode gera a partir do seu código: produtos de build, caches de módulos, índices e logs. Seu código, os arquivos do projeto e o histórico do Git ficam em outro lugar e nunca são afetados. A única consequência é que o próximo build de cada projeto será completo e a indexação vai rodar de novo.
Com que frequência devo limpar o DerivedData?
Não há uma frequência obrigatória — limpe quando ele estiver grande o bastante para fazer diferença, o que, para a maioria dos desenvolvedores ativos, significa a cada um ou dois meses. Dois momentos sempre justificam a limpeza: quando você precisa liberar espaço em disco com urgência e quando um projeto apresenta erros de build inexplicáveis ou um autocompletar desatualizado — nesse caso, limpar o DerivedData é a primeira correção padrão.
O Xcode vai ficar mais lento depois que eu excluir o DerivedData?
Temporariamente, sim. O primeiro build de cada projeto será completo, o que pode levar várias vezes mais que um build incremental, e a indexação em segundo plano precisa de alguns minutos até o autocompletar e a busca voltarem a funcionar plenamente. Depois desse primeiro ciclo, o desempenho volta a ser exatamente o que era — o DerivedData guarda caches, não otimizações que você perde para sempre.
E a pasta ~/Library/Developer/CoreSimulator — posso excluir?
Não às cegas — ela guarda os simuladores instalados e os dados deles, e excluí-la inteira deixa os simuladores inutilizáveis até você reinstalar os runtimes. Faça a limpeza do jeito certo: execute xcrun simctl delete unavailable para os dispositivos órfãos (os apps e dados deles são apagados junto), remova runtimes antigos em Settings > Components no Xcode, exclua os dispositivos sem uso em Devices and Simulators e limpe manualmente apenas a subpasta Caches, com o Xcode e o Simulator encerrados.
O Clean Build Folder faz a mesma coisa?
Não. Product > Clean Build Folder (Shift-Command-K) limpa apenas os produtos de build do projeto atual e mantém os índices, os caches de módulos e as pastas de todos os outros projetos. É uma ferramenta para resolver problemas de build, não para liberar espaço — recuperar espaço de verdade significa excluir as próprias pastas do DerivedData.
Fontes