Resposta rápida: os grandes caches de desenvolvedor no Mac são o Xcode DerivedData (
~/Library/Developer/Xcode/DerivedData— apague inteiro, é recompilado), simuladores iOS antigos (xcrun simctl delete unavailable), cache do npm (npm cache clean --force) e versões antigas do Homebrew (brew cleanup). Juntos, é comum recuperar 15–40 GB.
Máquina de desenvolvedor tem um padrão: o disco de 512 GB que "ia sobrar" está cheio em um ano, e nenhum arquivo pessoal explica. A explicação são os caches de ferramentas — cada build, cada npm install, cada brew upgrade deixa camadas para trás.
Este guia cobre os cinco maiores, com o comando de limpeza e o que esperar de cada um. (Docker, o maior de todos, tem guia próprio.)
1. Xcode DerivedData (5–30 GB)
O campeão. O Xcode guarda em ~/Library/Developer/Xcode/DerivedData todos os artefatos intermediários de build: índices, produtos compilados, logs. Cada projeto gera centenas de MB a alguns GB — e projetos antigos nunca são removidos.
rm -rf ~/Library/Developer/Xcode/DerivedData
É seguro: o Xcode recompila tudo na próxima build. O único custo é a primeira build de cada projeto ficar mais lenta (recompilação completa + reindexação).
Bônus no mesmo diretório: ~/Library/Developer/Xcode/Archives (builds arquivadas para distribuição — revise antes, você pode querer manter os símbolos de versões publicadas) e ~/Library/Developer/Xcode/iOS DeviceSupport (símbolos de dispositivos antigos que você não conecta mais).
2. Simuladores iOS (2–20 GB)
Cada versão de iOS/watchOS/tvOS que você já testou tem um simulador completo no disco. Para remover os que não são mais suportados pelo seu Xcode:
xcrun simctl delete unavailable
E para apagar dados de simuladores que você não usa (mantendo os simuladores):
xcrun simctl erase all
Runtimes antigos podem ser gerenciados em Xcode → Settings → Platforms.
3. Cache do npm / yarn / pnpm (1–10 GB)
O npm guarda uma cópia de cada pacote que você já baixou em ~/.npm:
npm cache clean --force
O yarn (~/Library/Caches/Yarn) e o pnpm (pnpm store prune) têm equivalentes. O pnpm merece nota: o store compartilhado é feature, não lixo — o prune remove só pacotes órfãos.
E os node_modules? Projetos antigos que você não toca há meses carregam cada um 200 MB–1 GB em dependências. Para encontrá-los:
find ~ -name "node_modules" -type d -prune -exec du -sh {} + 2>/dev/null | sort -rh | head
Apagar node_modules de projeto morto é grátis — um npm install reconstrói se precisar.
4. Homebrew (1–5 GB)
O Homebrew mantém versões antigas das fórmulas instaladas e o cache de downloads. Dois comandos:
brew cleanup --prune=all # remove versões antigas e cache
brew autoremove # remove dependências órfãs
Para ver quanto está acumulado antes: brew cleanup --dry-run.
5. Caches de outras ferramentas
Vale conferir conforme sua stack:
- CocoaPods:
~/Library/Caches/CocoaPods—pod cache clean --all - Gradle:
~/.gradle/caches— cresce sem limite em projetos Android - Cargo (Rust):
~/.cargo/registry—cargo cache -a(com a ferramenta cargo-cache) - pip:
pip cache purge - Go:
go clean -modcache
Rotina sugerida
Mensalmente, num terminal:
rm -rf ~/Library/Developer/Xcode/DerivedData
xcrun simctl delete unavailable
npm cache clean --force
brew cleanup --prune=all
docker system prune
Ou automatize: o CatMac detecta quais dessas ferramentas existem no seu Mac e escaneia os caches de Xcode, npm, Homebrew e Docker junto com os caches de apps e logs — uma varredura, o total recuperável na tela, e limpeza com confirmação (dupla, no caso de Docker e Homebrew). Os comandos rodam via API nativa com argumentos fixos, sem shell — sem surpresas. Primeira limpeza grátis.
Perguntas frequentes
Apagar o DerivedData pode quebrar meus projetos?
Não — é um cache de build por definição. O Xcode recria tudo na próxima compilação. Se um projeto estiver com erros estranhos de build, apagar o DerivedData é inclusive o primeiro passo clássico de troubleshooting.
Com que frequência limpar os caches de desenvolvedor?
Mensalmente para quem trabalha diariamente com essas ferramentas, ou quando o disco passar de 85%. DerivedData e Docker são os que mais rápido voltam a crescer.
npm cache clean precisa mesmo do --force?
Sim — desde o npm 5, o comando exige a flag porque o cache é considerado autocurativo. Limpar é seguro; o npm rebaixa os pacotes na próxima instalação.
Vale a pena apagar node_modules de projetos ativos?
Não — você só vai reinstalar em seguida. O ganho real está em projetos que você não abre há meses: os node_modules deles são peso morto que um npm install futuro reconstrói em minutos.