·
macos disk-space developer-tools xcode docker node-modules python rust homebrew

Your Dev Tools Are Why Your Mac is Full — Here's How to Reclaim 50-100GB

Developer tools silently cache tens of gigabytes — Xcode, Docker, node_modules, Python venvs, Rust targets, and more. Here's how to reclaim it all.

Last year I got a new MacBook Pro. 512GB SSD. I figured that was plenty — I’m not storing raw video footage or anything. I write code.

Four months later, macOS told me I was running low on disk space.

I opened System Settings > Storage and stared at the breakdown. “Developer” was the single largest category, bigger than my music library, photos, and documents combined. But macOS doesn’t tell you what in that category is eating the space. It just shows you a gray bar and shrugs.

So I started digging. I opened Terminal and started checking folder sizes manually. What I found was staggering: over 200GB of cached build artifacts, old container images, orphaned virtual environments, and dependency folders for projects I hadn’t touched in months.

That investigation — and the frustration of repeating it every few months — is why I eventually built MegaCleaner. But before I talk about that, let me show you exactly where your disk space is going. Because once you see the numbers, you’ll understand why a 512GB Mac fills up in months, not years.

The Core Problem: Dev Tools Cache Everything, Clean Up Nothing

Here’s the pattern every developer tool follows:

  1. Download dependencies, SDKs, container images, or runtimes
  2. Cache compiled artifacts, build products, and intermediate files
  3. Never delete any of it

There’s no malice here. Build caches make your second compile faster. Docker keeps old images around in case you need them. npm doesn’t delete node_modules from abandoned projects. Each tool is individually rational.

But collectively? You’re running 8-12 development tools, each maintaining its own cache, and none of them coordinate with each other or with the OS. Nobody’s watching the total. Nobody’s cleaning up.

The result: your 512GB SSD fills up with data that’s 80% regenerable and 100% invisible.

The Full Breakdown: Where Developer Disk Space Actually Goes

I’ve spent months cataloging this. Here’s what eats your disk, roughly ordered by how much damage each tool typically does.

1. Xcode — 30-100GB

Xcode is the undisputed champion of disk waste on macOS. If you do any iOS, macOS, watchOS, or visionOS development, Xcode alone can consume more storage than everything else on this list combined.

The main offenders:

  • DerivedData (~/Library/Developer/Xcode/DerivedData/) — 10-50GB. Every project gets its own build cache folder, and Xcode never removes them. Projects you archived six months ago? Still cached.
  • Simulator Runtimes (~/Library/Developer/CoreSimulator/) — 20-150GB. Each iOS version you’ve ever tested against downloads a 5-8GB simulator runtime. Have you tested on iOS 17, 18, and 26? That’s potentially 20-30GB in runtimes alone, before counting device data.
  • Archives (~/Library/Developer/Xcode/Archives/) — 5-30GB. Every time you build for distribution, Xcode saves a complete archive with debug symbols.
  • Device Support (~/Library/Developer/Xcode/iOS DeviceSupport/) — 10-40GB. Debug symbols for every physical device you’ve ever plugged in, organized by iOS version.

I wrote a detailed Xcode cleanup guide if you want the full breakdown with exact paths and safety levels.

Quick win:

rm -rf ~/Library/Developer/Xcode/DerivedData/*
xcrun simctl delete unavailable

These two commands alone can reclaim 15-40GB with zero risk.

2. Docker — 10-100GB

Docker on macOS runs inside a Linux VM, which stores everything in a single disk image file. This file only grows — it never shrinks on its own, even when you delete containers and images.

  • Docker.raw / Docker.qcow2 (~/Library/Containers/com.docker.docker/Data/vms/) — the VM disk image. Starts at a few GB, grows to 20-60GB or more. Even after pruning images, the file doesn’t reclaim the space without a manual reclaim operation.
  • Build cache — Docker’s layer cache for builds can silently grow to 10-50GB.
  • Dangling images — images with no tag, left behind after rebuilds. Usually 2-10GB.
  • Stopped containers — containers you ran once and forgot about, along with their writable layers.

Quick win:

docker system prune -a --volumes

This removes all stopped containers, unused images, build cache, and orphaned volumes. On a Mac that’s been running Docker for 6+ months, this routinely frees 10-30GB. But remember — the .raw file won’t shrink immediately. Docker Desktop has a “Reclaim disk space” button in Settings > Resources that triggers a filesystem trim.

3. node_modules — 5-50GB

The node_modules folder is a running joke in the developer community for a reason. A single React project can have a node_modules folder exceeding 500MB. If you have 20 projects on your machine — even ones you haven’t touched in a year — that’s 10GB+ of duplicated dependencies sitting in forgotten directories.

The problem compounds because:

  • Every project gets its own complete copy of every dependency
  • npm and yarn also maintain global caches (~/.npm, ~/.yarn/cache) — another 1-5GB
  • Projects you cloned once to review a PR and never deleted still have their node_modules intact

Quick win:

# Find all node_modules folders and their sizes
find ~ -name "node_modules" -type d -maxdepth 5 -prune -exec du -sh {} \; 2>/dev/null

Then delete the ones in projects you haven’t touched recently. Or use npkill for an interactive cleanup.

4. Python — 5-30GB

Python’s storage footprint sneaks up on you through multiple independent channels:

  • Virtual environments — every project with a venv/ or .venv/ folder has its own copy of the Python interpreter plus all installed packages. Each venv is typically 200MB-2GB. Across 10-15 projects, that’s 5-20GB.
  • Conda environments — if you use conda, each environment can be 1-5GB. Conda also maintains a package cache (~/miniconda3/pkgs/ or ~/anaconda3/pkgs/) that grows indefinitely.
  • pip cache (~/Library/Caches/pip/) — downloaded wheel files for every package you’ve ever installed. Usually 1-3GB.

Quick win:

# Clean pip cache
pip cache purge

# List conda environments and their sizes
conda info --envs
du -sh ~/miniconda3/envs/*/

# Remove conda cache
conda clean --all

5. Rust — 5-50GB

Rust’s compile times are famously long, and its build artifacts are famously large. Each project’s target/ directory contains compiled binaries, intermediate artifacts, and debug symbols. A single Rust project’s target/ folder can easily reach 5-15GB.

Then there’s the Cargo registry and cache:

  • ~/.cargo/registry/ — source code of every crate you’ve ever depended on
  • ~/.cargo/git/ — git checkouts of dependencies that reference git repos
  • Per-project target/ folders — the real space killers

If you work on 3-5 Rust projects, you can easily have 20-40GB in target/ directories alone.

Quick win:

# Clean a specific project
cargo clean

# Find all target/ directories
find ~ -name "target" -type d -maxdepth 4 -exec test -f "{}/CACHEDIR.TAG" \; -print -prune 2>/dev/null | xargs du -sh

6. Homebrew — 2-10GB

Homebrew keeps old versions of installed packages around as a courtesy (so you can roll back). It also caches downloaded bottles in ~/Library/Caches/Homebrew/. Over time, this adds up.

Quick win:

# Remove old versions and cache
brew cleanup --prune=all

# See how much space Homebrew is using
du -sh $(brew --cache)
du -sh $(brew --cellar)

7. IDE Caches — 1-5GB per IDE

Your IDE has its own set of caches, separate from the build system:

  • VS Code — extensions, cached data, logs. Lives in ~/Library/Application Support/Code/ and ~/.vscode/extensions/. Usually 1-3GB.
  • JetBrains IDEs (IntelliJ, PyCharm, WebStorm, etc.) — indexes, local history, caches. Stored in ~/Library/Caches/JetBrains/ and ~/Library/Application Support/JetBrains/. Each IDE version creates its own folder, and old versions are never cleaned up. 2-5GB per IDE is normal.

Quick win: Delete cache folders for IDE versions you’ve already upgraded past (e.g., IntelliJIdea2024.3 when you’re running 2025.1).

8. Java/Gradle/Maven — 5-20GB

The JVM ecosystem’s dependency management creates two major cache locations:

  • Maven local repository (~/.m2/repository/) — every JAR you’ve ever depended on. Grows to 2-10GB over time.
  • Gradle cache (~/.gradle/caches/) — build outputs, dependency cache, wrapper distributions. 3-15GB is common.
  • Gradle wrapper distributions (~/.gradle/wrapper/dists/) — full copies of Gradle itself, one per version. Each is ~150MB.

Quick win:

# Gradle: remove old caches
rm -rf ~/.gradle/caches/
rm -rf ~/.gradle/wrapper/dists/

# Maven: remove the local repo (re-downloads on next build)
rm -rf ~/.m2/repository/

9. The Long Tail

Several other tools contribute smaller but meaningful amounts:

  • Go — ~/go/pkg/mod/ for module cache, ~/go/bin/ for installed binaries. Typically 1-5GB.
  • Ruby — gem caches in ~/.gem/ or managed by rbenv/rvm. 1-3GB.
  • PHP — Composer cache in ~/.composer/cache/. Usually under 1GB.
  • .NET — NuGet cache in ~/.nuget/packages/. 1-5GB.
  • Terraform — .terraform/ directories in every project with their own copy of provider binaries. Each provider is 100-500MB.
  • Playwright — downloads full browser binaries (Chromium, Firefox, WebKit) per version. Each set is ~1GB, and old versions aren’t automatically removed.
  • Flutter/Dart — pub cache in ~/.pub-cache/, plus the Flutter SDK itself is ~2GB.
  • Android SDK — emulator images, build tools, platform tools. Lives in ~/Library/Android/sdk/. Can reach 10-30GB on its own.

Individually, none of these are catastrophic. Together, they add another 5-20GB of invisible cache.

Why Generic Mac Cleaners Miss All of This

I tried CleanMyMac and other popular cleaners before building my own tool. They’re good at what they do — finding system caches, language files, old log files, mail attachments. But they have no idea what DerivedData is. They don’t know that ~/Library/Developer/CoreSimulator/Devices/ contains 50GB of old simulator runtimes. They’ll never scan your home directory for orphaned node_modules folders or stale Python virtual environments.

Generic cleaners are built for general Mac users. They look for browser caches, system logs, and application leftovers. Developer tools live in completely different locations, use different caching strategies, and require different safety assessments. Deleting ~/Library/Caches/com.apple.Safari/ is straightforward. Deciding whether a Docker image is still needed requires understanding the tool’s context.

This gap between “general Mac cleanup” and “developer-specific cleanup” is where 50-100GB of reclaimable space hides — and where most developers end up manually running Terminal commands every few months.

What I Did About It

After the third time I found myself spending an hour running du -sh on various Library directories and Googling “is it safe to delete Xcode archives,” I decided to automate the whole process.

I built MegaCleaner — a native macOS app with 29 scanners (21 for developer tools, 8 for general system cleanup) that knows exactly where each tool stores its caches and which files are safe to remove.

The 21 developer tool scanners cover everything in this article: Xcode (with its sub-categories), Docker, node_modules, Python, Rust, Homebrew, IDE caches, Java/Gradle, CocoaPods, Swift Package Manager, Git repos, Go, Ruby, PHP, .NET, Android, Flutter/Dart, C/C++, Terraform, and Playwright. The 8 general scanners handle browser data, system caches, downloads, Trash, mail attachments, app leftovers, iOS device backups, and log files.

A few design decisions I’m proud of:

Three confidence levels. Every scannable item gets a confidence rating — “definite” (DerivedData, pip cache — always safe), “probable” (old archives, unused simulators — almost certainly safe), or “possible” (items that need your judgment). You can filter by confidence so you only clean what you’re comfortable with.

Moves to Trash, not permanent delete. Everything MegaCleaner removes goes to your Trash. Changed your mind? Pull it back out. This was non-negotiable for me — when a tool offers to delete 80GB of data, “undo” needs to exist.

Free to scan, pay to clean. You can run a full scan and see exactly how much space each tool is wasting before spending anything. The scan itself often teaches you things about your system you didn’t know. Cleaning requires a license — $49 one-time, not a subscription.

I built MegaCleaner because I needed it. If you’re a developer whose Mac is perpetually full, give the scan a try. At minimum, you’ll learn where your space is going.

Quick Wins: 5 Commands to Reclaim the Most Space Right Now

If you don’t want to install anything and just want to reclaim space immediately, here are the five highest-impact commands. Run them in Terminal:

1. Nuke Xcode DerivedData (10-50GB)

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

Zero risk. Everything rebuilds on next compile.

2. Remove old Xcode simulators (5-30GB)

xcrun simctl delete unavailable

Removes simulators for iOS versions your current Xcode no longer supports.

3. Prune Docker (10-30GB)

docker system prune -a --volumes

Removes all stopped containers, unused images, and orphaned volumes. Run with care if you have images you want to keep — this removes everything not currently in use.

4. Find and kill old node_modules (5-20GB)

find ~ -name "node_modules" -type d -maxdepth 5 -prune -exec du -sh {} \; 2>/dev/null | sort -hr | head -20

This shows your 20 largest node_modules folders. Delete the ones in projects you haven’t touched recently:

rm -rf /path/to/old-project/node_modules

5. Clean package manager caches (2-10GB)

# Homebrew
brew cleanup --prune=all

# pip
pip cache purge

# npm
npm cache clean --force

Combined, these five steps typically reclaim 30-100GB on a Mac that’s been used for development for 6+ months. No tools required, no cost, just Terminal commands and 10 minutes of your time.

The Bigger Picture

Your Mac isn’t broken. Apple didn’t sell you insufficient storage. The problem is that modern software development involves a dozen tools, each maintaining its own caches, and none of them talk to each other about total disk usage.

A 512GB Mac is fine for development — as long as you periodically clean up. The choice is between doing it manually (bookmarking this article and revisiting it quarterly), automating it (with MegaCleaner or scripts), or buying a 1TB Mac next time and kicking the can down the road.

I chose to automate it. Whatever you choose, at least now you know where the space is going.