Latent

How to free up disk space on a developer Mac: where the gigabytes actually hide

2026-09-07 · about 4 min · by the Latent team

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.

In short
  • 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

WhatPathTypical sizeSafe to delete?
DerivedData (build products, indexes)~/Library/Developer/Xcode/DerivedData5 to 50 GBR Rebuilt on next build
Simulator devices~/Library/Developer/CoreSimulator/Devices2 to 30 GBR Unavailable runtimes are safe; active devices hold app data
iOS DeviceSupport (symbols per iOS version)~/Library/Developer/Xcode/iOS DeviceSupport2 to 15 GBR Re-downloaded when that device connects
Archives (with dSYMs)~/Library/Developer/Xcode/Archives1 to 20 GBI Needed to symbolicate crash logs of shipped builds
Swift Package caches~/Library/Caches/org.swift.swiftpm1 to 5 GBR Re-fetched on resolve
CocoaPods cache~/Library/Caches/CocoaPods1 to 5 GBR 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
Archives are the one Xcode folder to treat with care. If you shipped a build to TestFlight or the App Store from this Mac and did not upload symbols, the dSYM inside that archive is the only copy that can turn a crash log into file and line numbers.

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.

ToolPathHow to remove properly
Hugging Face (transformers, diffusers)~/.cache/huggingface/hubhuggingface-cli delete-cache (interactive, per revision)
Ollama~/.ollama/modelsollama 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/torchDelete the folder; re-downloaded on use
MLX, whisper.cpp, others~/.cache/<tool> or project foldersCheck 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

  1. Docker prune and AI model cleanup: largest single files, one command each.
  2. Xcode DerivedData, unavailable simulators, old DeviceSupport.
  3. node_modules and Rust target folders in dormant projects.
  4. Package manager caches (npm, pip, Homebrew, Gradle).
  5. 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