A 512 GB MacBook running out of space is almost never your files. It's build caches. Here is every one of them, what it costs you, and the exact command to reclaim it.

Non-developers fill a Mac with photos and video. You did not. If you are a developer staring at “Your disk is almost full,” the overwhelming likelihood is that you never chose to store any of it. Your tools wrote it, silently, over months, and none of them ever clean up after themselves.

On a working developer machine we typically see 120–250 GB of pure build cruft. That is not an exaggeration for effect — it is what a two-year-old Mac with Xcode, Docker and a few dozen JavaScript projects looks like.

This guide covers every source of it, largest first, with the command to check and the command to fix. Nothing here needs an app.

First, find out what you are actually dealing with

macOS lies to you about free space, on purpose. Because APFS counts purgeable space (Time Machine local snapshots, caches macOS believes it can evict under pressure) as available, Finder’s number and reality diverge — sometimes by 50 GB or more.

Get the honest number:

df -h /System/Volumes/Data

Then find the top-level offenders in your home directory:

du -sh -- ~/* ~/Library/* 2>/dev/null | sort -hr | head -25

That takes a minute or two on a full disk. sort -hr sorts by human-readable size descending, so the worst thing on your Mac is the first line.

Why so many of these paths start with ~/Library. Since Catalina, ~/Library is hidden in Finder and protected by TCC. That is the single reason developers cannot find their missing hundred gigabytes: the whole problem lives in a folder Apple decided you should not look at.

1. Xcode — usually the single biggest item

If you build for Apple platforms, Xcode is almost certainly your number one. It has four separate hoards.

DerivedData

Intermediate build products and code indexes, one directory per project, kept forever. Xcode never deletes them, including for projects you deleted two years ago.

du -sh ~/Library/Developer/Xcode/DerivedData
rm -rf ~/Library/Developer/Xcode/DerivedData/*

Completely safe. It contains zero source code. Your next build is a clean build, so it takes longer once, and your index rebuilds. That is the whole cost. See the DerivedData deep dive for how to delete selectively.

iOS DeviceSupport

Every time you plug in a physical device running an OS version Xcode has not seen, it copies that version’s debug symbols — 2–6 GB each. Attach four devices over two years and you are carrying symbols for iOS versions nobody runs any more.

du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

Delete the old ones. They re-download automatically when you next connect a device on that OS.

Old simulator runtimes

Covered in its own article, because it is worth 30–60 GB by itself and the safe commands are non-obvious.

2. Docker — the one that lies to you

Run this:

docker system df

Then compare it to the size of the VM disk image on disk. The path moves between Docker Desktop versions, so find it rather than guessing:

find ~/Library/Containers/com.docker.docker -name "*.raw" -exec du -sh {} \; 2>/dev/null

You will very often see Docker reporting a few gigabytes in use while the image file is 60 GB or more. The reason: deleting images inside Docker frees space inside the VM’s filesystem, but does not shrink the file that holds it. The image only grows.

docker system prune -a --volumes

That reclaims space inside the VM — note it removes all unused images and, because of --volumes, all unused named volumes. Check nothing you care about (a local database, for example) lives in one first. To actually get the gigabytes back on your Mac’s disk, you generally have to let Docker Desktop compact the image or reset it. Full walkthrough here.

3. node_modules, everywhere

Not the one in the project you are working on. All the others.

find ~ -type d -name node_modules -prune -print0 2>/dev/null \
  | xargs -0 -n1 du -sh 2>/dev/null | sort -hr | head -30

The -prune matters: without it find descends into nested node_modules and the numbers become nonsense.

Expect somewhere between 30 and 80 results, most of them from projects you have not opened since last year. Each one is 200 MB to 1.5 GB, fully reproducible from a lockfile in seconds.

# Delete one, when you are sure
rm -rf ~/old-project/node_modules

4. Package manager global caches

These are pure duplication — every one of them is a local copy of something still on a registry.

# npm
du -sh ~/.npm/_cacache && npm cache clean --force

# pnpm (ask pnpm where its store is; it varies)
du -sh "$(pnpm store path)" && pnpm store prune

# Yarn
yarn cache clean

# Homebrew — this one is frequently 5 GB+
du -sh "$(brew --cache)" && brew cleanup -s --prune=all

# Go modules
du -sh ~/go/pkg/mod && go clean -modcache

# Python
du -sh ~/Library/Caches/pip && pip cache purge

# CocoaPods
du -sh ~/Library/Caches/CocoaPods

# Swift Package Manager
du -sh ~/Library/Caches/org.swift.swiftpm

Every one of these refills on demand. The only cost of clearing them is bandwidth the next time you install something.

5. Android Studio, if you have ever touched it

The worst offender per unit of use, because most people install it for one project and forget it.

du -sh ~/.gradle/caches
du -sh ~/Library/Android/sdk/system-images
du -sh ~/.android/avd

Each Android Virtual Device is an 8–12 GB disk image. Each SDK system image is 1–3 GB, and Android Studio downloads a fresh one per API level. Somebody who wrote one React Native app in 2024 is routinely carrying 60 GB here.

6. Rust and other target directories

cargo puts build artifacts in a target/ directory inside each project, and they are enormous — a mid-sized project’s target/ can be 5 GB on its own.

find ~ -type d -name target -prune 2>/dev/null \
  | while read -r d; do [ -f "$(dirname "$d")/Cargo.toml" ] && du -sh "$d"; done | sort -hr

The Cargo.toml check matters: plenty of non-Rust projects have a folder called target that you do not want to touch. Clean the real ones with cargo clean in the project directory, and clear the shared registry with:

du -sh ~/.cargo/registry

7. Time Machine local snapshots

This is the one that makes people think their Mac is broken. macOS keeps local Time Machine snapshots on your internal drive, and they can hold tens of gigabytes of files you already deleted. They count as “purgeable,” which is why Finder shows free space that you cannot actually use.

tmutil listlocalsnapshots /

macOS thins these automatically when space runs low, so most of the time the right move is to do nothing. If you need the space now:

# Free approximately 50 GB, urgency level 4
sudo tmutil thinlocalsnapshots / 50000000000 4

Understand what you are giving up: those snapshots are your ability to recover a file you deleted an hour ago. Delete them when you need space, not as routine hygiene.

What this adds up to

A realistic tally for a two-year-old developer Mac:

Source	Typical
Xcode DerivedData	20–90 GB
Docker VM image	15–120 GB
iOS simulators & runtimes	10–60 GB
Android AVDs & SDK images	20–100 GB
Stale `node_modules`	5–50 GB
Package manager caches	5–25 GB
Rust `target/` directories	3–40 GB
Xcode archives & DeviceSupport	5–30 GB

Not everyone has all of these. Almost everyone has more than they expect from at least three.

The part nobody tells you

All of it comes back. Clear DerivedData today and it is 12 GB again in a fortnight. This is not a one-time cleanup, it is a recurring tax, and the reason it keeps catching you by surprise is that none of it is visible. There is no notification, no dashboard, nothing in About This Mac that distinguishes 60 GB of build cache from 60 GB of family photos.

That is the whole reason DevCruft exists: it draws your disk to scale so the 62 GB folder is literally the biggest thing on the screen, and it already knows which folders regenerate and which ones do not. But the commands above are free, they work, and if you are happy running them every few weeks you genuinely do not need us.

Bookmark this page and come back when the warning appears again. It will.

Your Mac Is Full and You're a Developer: The Complete 2026 Guide