How to free up disk space on a developer Mac: where the gigabytes actually hide
Ordinary Mac cleaners wipe a few browser caches and call it a day. On a developer's machine the real weight sits in tool directories that Finder never shows you: build folders, package caches, container images and model weights. This guide lists them by owner, with the path, the typical size, and the command that removes them the way the tool itself expects.
- The biggest wins on most developer Macs are Xcode DerivedData and simulators, Docker's disk image, AI model caches (Hugging Face, Ollama, LM Studio) and package manager caches (npm, pnpm, pip, Homebrew, Gradle, Cargo).
- Delete through the tool's own command where one exists (
brew cleanup,docker system prune,ollama rm). It updates the tool's index too, so nothing is left half-registered. - Anything that the tool can rebuild or re-download is safe. Anything that only exists on your disk (archives with dSYMs, unpushed repos, unsaved editor buffers) is not, no matter how big it is.
First, find out who owns the space
Finder's storage panel groups everything under "Developer" or "Other", which tells you nothing. Start from the home directory and ask which top-level folders are heavy:
du -sh ~/Library/Developer ~/Library/Caches ~/.cache ~/.npm ~/.ollama ~/.docker 2>/dev/null | sort -h
Then drill into the largest one with du -sh ~/Library/Developer/* | sort -h. Ten minutes of this usually locates 80% of the reclaimable space. The rest of this guide is the map for what you will find.
Xcode and Apple toolchains
| What | Path | Typical size | Safe to delete? |
|---|---|---|---|
| DerivedData (build products, indexes) | ~/Library/Developer/Xcode/DerivedData | 5 to 50 GB | R Rebuilt on next build |
| Simulator devices | ~/Library/Developer/CoreSimulator/Devices | 2 to 30 GB | R Unavailable runtimes are safe; active devices hold app data |
| iOS DeviceSupport (symbols per iOS version) | ~/Library/Developer/Xcode/iOS DeviceSupport | 2 to 15 GB | R Re-downloaded when that device connects |
| Archives (with dSYMs) | ~/Library/Developer/Xcode/Archives | 1 to 20 GB | I Needed to symbolicate crash logs of shipped builds |
| Swift Package caches | ~/Library/Caches/org.swift.swiftpm | 1 to 5 GB | R Re-fetched on resolve |
| CocoaPods cache | ~/Library/Caches/CocoaPods | 1 to 5 GB | R Re-fetched on pod install |
# DerivedData: quit Xcode first
rm -rf ~/Library/Developer/Xcode/DerivedData
# Simulators that no installed runtime can boot any more
xcrun simctl delete unavailable
# Old device support folders: keep the iOS versions you still debug on
ls ~/Library/Developer/Xcode/iOS\ DeviceSupport
JavaScript: node_modules and package caches
A single node_modules folder is often 200 MB to 1 GB, and a Mac with a year of side projects has dozens of them. They are all regenerable as long as the lockfile is committed.
# Find every node_modules under your projects, largest first
find ~/Projects -name node_modules -type d -prune -exec du -sh {} + | sort -h
# npm / pnpm / yarn caches
npm cache clean --force # ~/.npm/_cacache
pnpm store prune # ~/Library/pnpm/store
yarn cache clean # ~/Library/Caches/Yarn
Delete node_modules in projects you are not touching this month; npm ci or pnpm install brings them back from the lockfile in a minute or two.
Docker and containers
Docker Desktop keeps every image, container layer and volume inside one virtual disk file, and that file only grows. It lives at ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw and it is common to find it at 40 to 100 GB.
docker system df # what is inside
docker system prune -a # remove unused images, containers, networks
docker volume prune # unused volumes (check first: databases live here)
After pruning, Docker Desktop shrinks the file on its own in recent versions; older versions need the disk image size lowered in Settings. Never delete Docker.raw by hand while Docker is running.
AI models: the new heavyweight
Since 2023 the fastest-growing folder on many developer Macs is model weights. One 7B model is 4 to 5 GB; a few experiments add up to more than Xcode.
| Tool | Path | How to remove properly |
|---|---|---|
| Hugging Face (transformers, diffusers) | ~/.cache/huggingface/hub | huggingface-cli delete-cache (interactive, per revision) |
| Ollama | ~/.ollama/models | ollama list, then ollama rm <model> |
| LM Studio | ~/.lmstudio/models (older builds: ~/.cache/lm-studio/models) | Delete from the app's My Models view |
| PyTorch hub, torchvision weights | ~/.cache/torch | Delete the folder; re-downloaded on use |
| MLX, whisper.cpp, others | ~/.cache/<tool> or project folders | Check each tool's docs; most re-download |
Everything in this table is re-downloadable from a registry, which is what makes it safe to remove: the registry is the copy of record. The exception is a model you fine-tuned yourself and saved into one of these folders. That file exists nowhere else.
Python, Rust, Go, JVM and Android
# Python
pip cache purge # ~/Library/Caches/pip
conda clean --all # pkgs and tarballs
ls ~/.pyenv/versions # interpreters you no longer use
# Rust
cargo cache -a # needs cargo-cache; or rm -rf ~/.cargo/registry/cache
find ~/Projects -name target -type d -prune -exec du -sh {} + # per-project build dirs
# Go
go clean -modcache # ~/go/pkg/mod
# Gradle / Android
rm -rf ~/.gradle/caches # rebuilt on next sync
# Android Studio: SDK Manager removes old system images; AVDs live in ~/.android/avd
Rust target directories deserve a special mention. A single medium project can hold 10 GB of incremental build artifacts, and cargo clean inside the project removes it in seconds.
Homebrew and the rest of the caches
brew cleanup --prune=all # old versions + download cache (~/Library/Caches/Homebrew)
brew autoremove # dependencies nothing needs any more
Other regulars: ~/Library/Caches/com.apple.dt.Xcode, JetBrains caches under ~/Library/Caches/JetBrains, VS Code's extension and workspace caches, and the session logs that coding agents keep under their own dot-folders in your home directory. All of these are rebuilt or regrown; none of them hold your work.
The order that pays off
- Docker prune and AI model cleanup: largest single files, one command each.
- Xcode DerivedData, unavailable simulators, old DeviceSupport.
node_modulesand Rusttargetfolders in dormant projects.- Package manager caches (npm, pip, Homebrew, Gradle).
- Everything else, only if you still need space.
Doing this by hand once is educational. Doing it every month is tedious, and the mistake to avoid is the one that is easy to make at step 5: deleting a folder you did not recognise, that turns out to be the only copy of something.
Questions people ask
Is it safe to delete Xcode DerivedData?
Yes. DerivedData holds build products and indexes that Xcode regenerates on the next build. Quit Xcode first, then remove the folder. The first build afterwards takes longer.
Where do Ollama models live on a Mac and how do I delete them?
In ~/.ollama/models. Run ollama list to see what is installed and ollama rm followed by the model name to remove one. Deleting files by hand leaves Ollama's index out of sync.
Why is Docker.raw so large and can I delete it?
Docker Desktop stores all images, container layers and volumes inside that one file, and it only grows. Do not delete it by hand. Run docker system prune -a and docker volume prune, then let Docker shrink the file or lower the disk image size in its settings.
Can I delete node_modules?
Yes, whenever the project has a committed lockfile. npm ci, pnpm install or yarn install recreates it exactly. Delete it in projects you are not working on and reinstall when you come back.
Let Latent do the attribution
Latent scans a developer Mac, attributes every gigabyte to the tool that owns it, marks each folder R, I or P with the reason, and only offers what it can prove is safe. One-time license, three Macs.
Download for MacHow it works