Forem: Sergey Nikiforov

I Scanned My MacBook and Found 127GB of Developer Junk. Here's What It Was

Sergey Nikiforov — Wed, 29 Apr 2026 14:51:21 +0000

Last week I ran MegaCleaner on my development MacBook for the first time in months. It found 127GB of junk. Not "maybe junk" — actual build artifacts, stale caches, and orphaned data from tools I use every day.

My 512GB drive had 47GB free. After cleaning, I had 168GB free. That's a quarter of my entire disk reclaimed.

Here's the full breakdown of what was hiding on my machine.

The Scan Results

MegaCleaner scans 29 categories (21 developer tools + 8 general system categories). On my machine, almost everything had something to report. Here's what it found, from largest to smallest.

Xcode DerivedData + Simulators — 42GB

This is always the big one. I do iOS work across several projects, and Xcode is relentless about caching.

DerivedData: 16GB across about 30 project folders, most of which I haven't opened in months. Xcode never cleans these up. Ever.
Old simulator runtimes: 19GB. I had iOS 17.2, 17.5, and 18.0 runtimes still installed. I'm building against iOS 18.4 now. Those are dead weight.
Device support files: 5GB. Debug symbol caches from old iOS versions on devices I connected once.
Stale archives: 2GB. Old .xcarchive bundles from builds I submitted to App Store Connect months ago.

DerivedData alone is the single easiest win on any developer's Mac. It rebuilds automatically. There's zero risk in deleting it.

Docker Images and Build Cache — 31GB

Docker Desktop on macOS stores everything inside a single Docker.raw disk image, which makes it invisible to most disk analyzers. You have to actually query Docker to see what's inside.

My breakdown:

Unused images: 18GB. Old base images, intermediate layers from builds I ran weeks ago, images for projects I'm no longer working on.
Build cache: 11GB. Docker keeps every build layer cached. Great for rebuild speed, terrible for disk space when you have dozens of Dockerfiles.
Stopped containers and dangling volumes: 2GB. Easy to forget about.

The thing about Docker is that docker system prune exists, but most people never run it. And even when they do, it doesn't remove images that still have tags. You need docker system prune -a for that, and most people are (reasonably) nervous about running it.

node_modules Across 23 Projects — 18GB

This one is a classic. I counted 23 separate node_modules directories on my machine. Some of them were in projects I haven't touched in over a year.

The average node_modules directory was about 780MB. The largest was 2.1GB — a Next.js project with a heavy dependency tree including Playwright browsers.

Here's the thing: node_modules is fully reproducible. npm install or yarn install recreates it from the lockfile. There is no reason to keep node_modules for a project you're not actively working on today. None.

I kept 4 (active projects). Deleted 19.

Rust target/ Directories — 14GB

Rust compile artifacts are large. This is well-known in the Rust community — a single project's target/ directory can hit 5-10GB easily, especially in debug mode.

I had 6 Rust projects. Two of them I'm actively developing. The other four had target/ folders sitting there doing nothing, totaling about 10GB. Even for the active projects, the target/debug directories had artifacts from dependencies I'd since removed.

cargo clean exists but you have to run it per-project. And you have to remember.

Python Conda Environments — 9GB

I keep conda around for ML experiments. The problem is that conda environments are self-contained — each one bundles its own copy of Python plus every dependency. That's great for isolation, terrible for disk space.

I had 5 conda environments. Two were from experiments I ran once in late 2025 and never looked at again. Each environment was about 2GB. The pip cache added another 2GB on top.

Homebrew Cache — 4GB

Every time Homebrew installs or upgrades a package, it downloads the source/bottle and caches it. These caches stick around indefinitely. brew cleanup is supposed to help, but I hadn't run it in 4 months.

4GB isn't dramatic, but it's free money — there's no reason to keep old Homebrew downloads.

IDE Caches (VS Code, JetBrains) — 3GB

I use VS Code daily and occasionally fire up a JetBrains IDE for Java work. Both cache aggressively.

VS Code extensions, workspace storage, cached data: 1.8GB
JetBrains system caches and local history: 1.2GB

Nothing critical in any of it. IDE caches rebuild seamlessly.

Browser Caches — 2GB

Chrome and Arc combined. Not developer-specific, but it all counts. These regenerate automatically as you browse.

System Caches and Logs — 4GB

macOS system logs, crash reports, temporary files, expired caches under ~/Library/Caches. The kind of stuff that accumulates silently on every Mac, developer or not.

The Surprises

A few things caught me off guard.

Docker was bigger than I expected. I knew I had some images lying around, but 31GB? I had mentally budgeted for maybe 10-15GB. The build cache was the hidden killer — I didn't realize how much Docker was hoarding in layer cache.

Rust's target/ directories were surprisingly large for such few projects. Six projects, 14GB. That's over 2GB average per project. Debug builds in Rust are aggressively unoptimized (intentionally — for faster compile times), which means the artifacts are huge.

Xcode was not a surprise. Anyone who's done iOS development for more than a year knows DerivedData is a storage black hole. The simulators were the real problem — 19GB for runtimes I'll never use again.

node_modules was exactly what I expected — which is its own kind of sad. We've all accepted that JavaScript projects casually consume a gigabyte of disk space each. It doesn't have to be that way (keeping them around for stale projects, I mean).

What I Cleaned vs. What I Kept

This is where MegaCleaner's confidence levels were useful. Every item it finds is tagged with a confidence level:

Definite — 100% safe to delete. Caches, build artifacts, derived data. Regenerates automatically on next use.
Probable — Very likely safe. Old archives, stale environments, unused images. Check if you're unsure.
Possible — Worth reviewing first. Things like large unknown files or old Xcode versions that might still be needed.

I cleaned everything marked "definite" without hesitation — that was about 95GB. For "probable" items, I skimmed the list and cleaned most of them (another 26GB). The few "possible" items (6GB) I reviewed individually and cleaned about half.

Total cleaned: ~121GB out of the 127GB found.

What I kept:

DerivedData for 2 active Xcode projects (rebuild takes 8 minutes each)
node_modules for 4 active projects
target/ for 2 active Rust projects
My current conda environment for an ongoing ML project

Everything else went to Trash. (MegaCleaner moves to Trash, not permanent delete — so you can always undo if something feels wrong.)

The Before and After

	Before	After
Used space	465 GB	344 GB
Free space	47 GB	168 GB
Cleaned	—	121 GB

I went from "I need to buy a new laptop" to "I'm fine for another year."

A 512GB drive with 47GB free is stress. You're getting macOS warnings, Docker complains, Xcode builds fail because there's no room for intermediate files. At 168GB free, everything just works again.

Why I Built MegaCleaner

I used to do this manually. Every few months, when my disk got uncomfortably full, I'd open Terminal and start running commands:

rm -rf ~/Library/Developer/Xcode/DerivedData/*
docker system prune -a
find ~ -name "node_modules" -type d -maxdepth 5
# ...and so on, for 20 minutes

The problem isn't that it's hard. Each command is simple. The problem is that it's tedious, you have to remember all the paths, and you inevitably forget something. I'd clean up 40GB, feel good, and then three months later realize Docker build cache had quietly grown to 15GB again.

So I automated it. First as a script for myself, then as a proper macOS app with a UI, safety checks, and the ability to see everything in one scan.

That became MegaCleaner.

Try It Yourself

The scan is free. You can download MegaCleaner, run it, and see exactly how much space your dev tools are wasting — no purchase required.

If you want to actually clean, it's $49 one-time. Not a subscription. You buy it once, it's yours.

Given that a 512GB to 1TB MacBook upgrade costs Apple $200, reclaiming 100+ GB for $49 is a decent deal.

Download MegaCleaner — free scan, see what your Mac is hiding.

I'm Sergey — I build developer tools at Morco Labs. MegaCleaner is a native macOS app, built in Swift, no Electron, no subscriptions. If you have questions or feedback, find me on Twitter/X.

Cargo Target Directories: Why Rust Projects Eat 10GB Each

Sergey Nikiforov — Wed, 29 Apr 2026 14:49:00 +0000

Each Rust project's target/ directory can easily hit 5-15GB. If you have 10 projects on your machine, that's 50-150GB of disk space consumed by build artifacts alone. On a 256GB or 512GB MacBook, that's a significant chunk of your drive gone to compiled code you probably aren't actively using.

This isn't a bug. It's a direct consequence of how Rust's compilation model works — and once you understand the mechanics, you can make informed decisions about what to clean and how to prevent the bloat from coming back.

Why Rust Builds Are So Large

Rust's compilation strategy optimizes for correctness and runtime performance at the cost of disk space. Several factors compound to produce those multi-gigabyte target/ directories.

Debug Info

By default, cargo build produces a debug build. The compiler embeds full DWARF debug information into every binary and library artifact — function names, variable locations, type definitions, line number mappings. This debug info alone can double or triple the size of a compiled artifact compared to what the actual machine code requires.

A simple "hello world" debug binary is around 3-4MB. A real application with a handful of dependencies? Easily 50-200MB for the final binary, plus all the intermediate artifacts.

Incremental Compilation

Rust's incremental compilation keeps fine-grained intermediate results from previous builds so that recompilation only touches changed code. This is essential for fast iteration — without it, even a one-line change in a large project could mean a full rebuild taking several minutes.

The trade-off: these incremental artifacts live in target/debug/incremental/ and can grow to several gigabytes per project. Each code change produces new incremental snapshots, and old ones aren't garbage collected aggressively.

Dependency Compilation

When you cargo build, the compiler doesn't just compile your code — it compiles every one of your dependencies from source. A typical Rust project with 100-300 transitive dependencies (check yours with cargo tree | wc -l) will compile each of those crates and store the resulting .rlib files, metadata, and build script outputs in target/.

Unlike languages with precompiled package distributions (Python wheels, npm prebuilds), Rust compiles everything locally. This means your target/ directory contains compiled output for every crate in your dependency tree.

Multiple Build Profiles and Targets

The target/ directory grows further if you use multiple build configurations:

target/debug/ — your default cargo build output
target/release/ — cargo build --release output (separate compilation, separate artifacts)
target/<triple>/ — cross-compilation targets like aarch64-apple-darwin or wasm32-unknown-unknown

Each profile and target combination gets its own full set of compiled artifacts. If you cross-compile for two targets in both debug and release mode, you have four complete copies of your dependency tree.

Where Exactly the Space Goes

Let's break down every location where Cargo stores data on your machine.

Per-Project: `target/debug/`

This is the primary build output for cargo build. It contains:

deps/ — compiled .rlib and .rmeta files for every dependency
build/ — output from build scripts (build.rs), including generated code and compiled C dependencies
incremental/ — incremental compilation cache (often the largest subdirectory)
.fingerprint/ — hashes Cargo uses to determine if a crate needs recompilation
The final binary or library artifact itself

Typical size: 2-10GB per project, depending on dependency count.

Safe to delete? Yes. Running cargo build regenerates everything. You lose cached compilation, so your next build will be a full rebuild.

Per-Project: `target/release/`

Same structure as debug/, but for cargo build --release. Release builds have different trade-offs: no debug info by default, full optimization passes, but the intermediate artifacts still take significant space.

Typical size: 1-5GB per project. Often smaller than debug due to lack of debug info, but optimized artifacts can be larger.

Safe to delete? Yes, same as debug.

Global: `~/.cargo/registry/`

This is Cargo's global package registry cache. It has two main subdirectories:

registry/cache/ — compressed .crate files downloaded from crates.io. These are the raw downloaded packages.
registry/src/ — extracted source code from those .crate files. Cargo extracts sources here before compiling them into your project's target/ directory.

The registry is shared across all your projects — if ten projects depend on serde, Cargo downloads and extracts it once.

Typical size: 1-5GB, depending on how many unique crates you've used across all projects.

Safe to delete? Yes. Cargo re-downloads crates as needed. Deleting registry/cache/ forces re-download; deleting registry/src/ forces re-extraction.

Global: `~/.cargo/git/`

When your Cargo.toml specifies a git dependency (git = "https://github.com/..." instead of a version from crates.io), Cargo clones the repository here.

git/db/ — bare git repositories (the full clone)
git/checkouts/ — checked-out working copies at specific commits

Typical size: 500MB-5GB, depending on how many git dependencies you use. Some large git dependencies (like forks of big frameworks) can add gigabytes on their own.

Safe to delete? Yes. Cargo re-clones as needed. You'll pay the download cost again, but nothing is lost.

Cleanup Commands

Per-Project: `cargo clean`

The simplest approach. Run this from any Rust project directory:

cargo clean

This removes the entire target/ directory for that project. Your next cargo build will be a full rebuild from scratch.

To clean only release artifacts:

cargo clean --release

Registry Cache

Remove the global registry cache (all downloaded crate files):

rm -rf ~/.cargo/registry/cache
rm -rf ~/.cargo/registry/src

The registry/index directory contains the crates.io index — you can delete it too, but it's smaller and takes time to re-download.

To clean git caches:

rm -rf ~/.cargo/git

Finding All Target Directories

The real problem isn't one project — it's the ten projects scattered across your filesystem that you haven't touched in months. Find them all:

find ~ -name "target" -type d -maxdepth 5 | while read dir; do
  if [ -f "$dir/../Cargo.toml" ]; then
    size=$(du -sh "$dir" 2>/dev/null | cut -f1)
    echo "$size  $dir"
  fi
done

This finds target/ directories that are actually Rust projects (verified by the presence of Cargo.toml in the parent directory) and shows their sizes. Review the output, then clean the ones you want:

# Clean a specific project without cd-ing into it
cargo clean --manifest-path /path/to/project/Cargo.toml

cargo-sweep: Time-Based Cleanup

cargo-sweep is a community tool that removes build artifacts older than a specified number of days, keeping your recent work intact:

cargo install cargo-sweep

# Remove artifacts older than 30 days (run from project root)
cargo sweep --time 30

# Or stamp current artifacts, then later sweep unstamped ones
cargo sweep --stamp
# ... work on the project ...
cargo sweep --file

This is more surgical than cargo clean — it preserves incremental compilation cache for code you're actively working on while removing artifacts for features or dependencies you changed weeks ago.

To sweep across all projects:

find ~ -name "Cargo.toml" -maxdepth 5 | while read manifest; do
  project_dir=$(dirname "$manifest")
  if [ -d "$project_dir/target" ]; then
    echo "Sweeping $project_dir"
    cargo sweep --time 30 --manifest-path "$manifest"
  fi
done

The Shared Target Directory Trick

If you work on multiple Rust projects, you can point them all at a single shared target/ directory using the CARGO_TARGET_DIR environment variable:

# Add to your ~/.zshrc or ~/.bashrc
export CARGO_TARGET_DIR="$HOME/.cargo-target"

Or set it in ~/.cargo/config.toml:

[build]
target-dir = "/Users/yourname/.cargo-target"

What this does: All projects compile into the same directory. Shared dependencies are compiled once and reused across projects — if five projects depend on tokio, it's compiled once instead of five times.

What this saves: Potentially 50-70% of total target directory space if your projects share many dependencies.

The caveat: You can no longer cargo clean a single project without wiping artifacts for all projects. This trade-off works best if you have many small projects with overlapping dependency trees. You can also set this per-project in .cargo/config.toml at the project root for monorepo setups.

The Automated Way

Manual cleanup works, but it's tedious. Most developers do this once every few months when they get a "disk full" warning — by which point 50-100GB of stale build artifacts have accumulated.

MegaCleaner automates this with a dedicated Rust scanner. It searches your configured project directories for target/ folders alongside Cargo.toml files, and separately finds your global Cargo caches at ~/.cargo/registry/ and ~/.cargo/git/. Each location is sized and presented individually so you can review before cleaning.

The scanner has two sub-features you can toggle independently:

Cargo — finds and sizes your ~/.cargo/registry and ~/.cargo/git caches
Build Output — discovers every target/ directory in your projects, reads the project name from Cargo.toml, and reports the size

It also checks staleness by examining the last-modified dates of source files (.rs, .toml, .json, .yaml, .yml) in each project. If you haven't touched a project's source code in a while, MegaCleaner flags that target/ directory as stale and pre-selects it for cleanup. Projects you're actively working on are left unselected by default.

Rust is just one of MegaCleaner's 29 scanners (21 developer-focused, 8 general). It handles Node.js node_modules, Xcode DerivedData, Python virtual environments, Docker images, and more — all the caches that quietly consume your disk across different tech stacks. One-time purchase, $49, native macOS app.

Quick Reference

Location	What It Stores	Typical Size	Cleanup Command
`<project>/target/debug/`	Debug build artifacts, incremental cache	2-10 GB	`cargo clean`
`<project>/target/release/`	Release build artifacts	1-5 GB	`cargo clean --release`
`~/.cargo/registry/cache/`	Downloaded `.crate` files	500 MB-2 GB	`rm -rf ~/.cargo/registry/cache`
`~/.cargo/registry/src/`	Extracted crate source code	500 MB-3 GB	`rm -rf ~/.cargo/registry/src`
`~/.cargo/git/`	Git dependency clones	500 MB-5 GB	`rm -rf ~/.cargo/git`

Total across 10 projects: 30-150+ GB

Everything in this table is safe to delete. Cargo rebuilds and re-downloads automatically. The only cost is time — a full rebuild of a large project might take 5-10 minutes, and re-downloading dependencies requires an internet connection.

For ongoing maintenance, pick one approach:

Manual: Run cargo clean on projects you haven't touched in a month
cargo-sweep: cargo sweep --time 30 for time-based cleanup
Shared target: CARGO_TARGET_DIR to deduplicate dependencies across projects
Automated: MegaCleaner to scan, size, and clean everything with staleness detection

Your Mac's SSD is too valuable for build artifacts from six months ago. Reclaim it.

Don't Let Conda Eat Your Hard Drive: Python Environment Cleanup for Mac

Sergey Nikiforov — Wed, 29 Apr 2026 14:36:53 +0000

My Anaconda installation was 28GB. I had 12 conda environments I'd forgotten about — one for every tutorial I'd followed, every Kaggle competition I'd started and abandoned, every "let me just try this library real quick" session. Each one had its own copy of NumPy, pandas, and scikit-learn. Three of them had PyTorch installed. That's 2-3GB per copy, sitting in folders I hadn't touched in months.

If you do any data science or ML work on a Mac, you've been there. Python's environment model is designed to keep things isolated — and it does, by duplicating everything. That isolation comes at a cost: disk space, and lots of it.

This guide covers every place Python stores things on macOS, how big each category typically gets, and how to clean them safely — whether you do it manually or let a tool handle it.

Quick Reference

Category	Path	Typical Size	Safe to Delete?
Conda environments	`~/anaconda3/envs/` or `~/miniconda3/envs/`	2-30 GB	Yes (except active ones)
Conda pkgs cache	`~/anaconda3/pkgs/`	2-10 GB	Yes — `conda clean --all`
pip cache	`~/Library/Caches/pip/`	0.5-5 GB	Yes — `pip cache purge`
Virtual envs (.venv)	Scattered across projects	1-15 GB total	Yes (recreatable)
pyenv versions	`~/.pyenv/versions/`	1-5 GB	Yes (except active ones)
Poetry cache	`~/Library/Caches/pypoetry/`	0.5-3 GB	Yes — `poetry cache clear --all`
uv cache	`~/.cache/uv/`	0.5-5 GB	Yes — `uv cache clean`
pycache / .pyc	Inside every project	10-500 MB total	Yes — always safe
Tool caches	`.ruff_cache`, `.mypy_cache`, `.pytest_cache`	10-200 MB total	Yes — always safe
tox environments	`~/.tox/`	0.5-5 GB	Yes — regenerated on next run

Total potential savings: 10-50+ GB depending on how many projects and environments you've accumulated.

Why Python Environments Get So Large

Every virtual environment or conda environment is a self-contained copy of a Python interpreter plus all its packages. Nothing is shared between environments. Great for reproducibility. Terrible for disk space.

Here's why it adds up so fast:

PyTorch: 2-3 GB per installation
TensorFlow: 1-2 GB per installation
NumPy + SciPy + pandas + scikit-learn: ~500 MB as a stack
Jupyter + its dependencies: ~300 MB
Conda base environment: 3-5 GB before you install anything extra

Five conda environments with a ML framework plus the standard data science stack? That's 15-25 GB just in environments. Add caches, and you're at 20-40 GB of Python data on your machine.

The problem compounds because environments accumulate. You create one for a project, move on, forget about it. A year later, you have a dozen environments and no idea which ones matter.

1. Conda Environments

The biggest offender. Each conda environment is a full, isolated Python installation with its own packages. A single ML-focused environment can be 3-8 GB.

Where they live:

~/anaconda3/envs/
~/miniconda3/envs/
~/opt/anaconda3/envs/
~/miniforge3/envs/
~/mambaforge/envs/

The exact path depends on which distribution you installed and how you installed it. If you're not sure, check:

conda env list

This shows every environment and its path. You'll probably be surprised by how many there are.

How to clean them:

First, identify which environments you actually use. Anything you haven't touched in 3+ months is probably safe to remove.

Remove a specific environment:

conda env remove -n old-project-env

Remove multiple environments:

conda env remove -n kaggle-titanic
conda env remove -n nlp-tutorial
conda env remove -n test-env-2024

What to keep: Don't remove base — it's your main conda installation. Keep any environment that belongs to an active project, especially if it has a complex dependency setup that took time to get working.

How big are they? Check individual environment sizes:

du -sh ~/anaconda3/envs/* 2>/dev/null
du -sh ~/miniconda3/envs/* 2>/dev/null

2. Conda Package Cache

Even after deleting environments, conda keeps a cache of every package it has ever downloaded. This cache lives inside your conda installation directory.

Where it lives:

~/anaconda3/pkgs/
~/miniconda3/pkgs/

How to clean it:

conda clean --all

This removes:

Cached package tarballs
Extracted packages no longer linked to any environment
Index cache

It's completely safe. Conda will re-download any package it needs next time you create an environment or install something.

Typical savings: 2-10 GB, depending on how long you've been using conda.

3. pip Cache

Every time you pip install something, pip downloads the wheel or sdist and caches it locally. This speeds up future installs, but the cache grows indefinitely.

Where it lives on macOS:

~/Library/Caches/pip/

(On Linux it's ~/.cache/pip/ — if you see that path in tutorials, the macOS equivalent is the Library path above.)

How to clean it:

pip cache purge

Or manually:

rm -rf ~/Library/Caches/pip

Typical savings: 0.5-5 GB. If you install a lot of packages with native extensions (like numpy, scipy, torch), the cache tends to be larger because those wheels are big.

Is it safe? Completely. The cache only speeds up reinstallation — pip will re-download anything it needs.

4. Virtual Environments (.venv, venv, env)

Unlike conda environments, which live in a central location, Python virtual environments are typically created inside project directories. This makes them easy to forget about — they're scattered across your filesystem.

Common locations:

~/projects/my-app/.venv/
~/projects/my-app/venv/
~/projects/my-app/env/

The standard naming conventions are .venv, venv, and env. A valid virtual environment contains a pyvenv.cfg file and a bin/python executable.

Finding all of them:

find ~ -name "pyvenv.cfg" -maxdepth 5 2>/dev/null

This finds every virtual environment within 5 levels of your home directory. Each result shows the root of a venv — the parent directory is what you'd delete.

A more targeted approach:

find ~/projects ~/code ~/dev -type d \( -name ".venv" -o -name "venv" -o -name "env" \) -maxdepth 4 2>/dev/null

How to clean them:

Simply delete the directory:

rm -rf ~/projects/old-project/.venv

Is it safe? Yes — as long as you can recreate it. If the project has a requirements.txt, pyproject.toml, or Pipfile, you can always rebuild:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Orphaned environments are especially safe to delete — these are venvs where the parent project no longer has any Python source files or config files. The project was probably deleted or moved, but the environment was left behind.

Typical total size: 1-15 GB across all projects, depending on how many you have and whether any include ML frameworks.

5. pyenv, Poetry, and uv

A few more Python tools that accumulate disk usage:

pyenv installs each Python version separately at ~/.pyenv/versions/. Each version is 200-500 MB. Run pyenv versions to see what's installed, and pyenv uninstall 3.9.7 to remove old point releases.

Poetry caches packages at ~/Library/Caches/pypoetry/. Clean with poetry cache clear --all .

uv caches aggressively at ~/.cache/uv/ for speed — expect 1-5 GB if you use it regularly. Clean with uv cache clean.

6. pycache and Tool Caches

These are small individually but add up across many projects.

pycache directories contain compiled Python bytecode (.pyc files). Every Python project has them scattered throughout its source tree. Tool caches include .ruff_cache/, .mypy_cache/, .pytest_cache/, and .tox/ (tox environments at ~/.tox/ can be large).

All of these are completely safe to delete — they regenerate automatically.

find ~/projects -type d -name "__pycache__" 2>/dev/null | head -20
find ~/projects -type d \( -name ".mypy_cache" -o -name ".ruff_cache" -o -name ".pytest_cache" \) 2>/dev/null

Typical total size: 10-500 MB across all projects. Not huge, but it's free space with zero risk.

What's Safe to Delete vs. What to Keep

Here's the short version:

Always safe (zero risk):

pip cache
conda package cache (conda clean --all)
__pycache__ / .pyc files everywhere
.ruff_cache, .mypy_cache, .pytest_cache
uv and Poetry caches

Safe if you can recreate (low risk):

Virtual environments with a requirements.txt or pyproject.toml nearby
Conda environments you haven't used in months
Old pyenv versions

Verify first:

Conda environments for active projects with complex dependency pinning
Virtual environments with no dependency file (you might not remember what was installed)
The conda base environment — don't delete this unless you're uninstalling conda entirely

Prevention: Keeping Python Lean

You can't avoid the problem entirely, but you can slow the growth:

Use Miniconda instead of Anaconda. A full Anaconda install is 3-5 GB out of the box because it includes hundreds of packages. Miniconda starts at ~400 MB. If you're already on Anaconda, switching is probably the single biggest disk savings you can make.

Use Miniforge or Mambaforge on Apple Silicon. Miniforge gives you conda-forge as the default channel with native ARM packages. Mamba (a faster conda replacement) is included with Mambaforge.

Clean caches monthly. Run conda clean --all and pip cache purge once a month. It takes 5 seconds and prevents multi-gigabyte cache buildup.

Export before deleting. The environment file is what matters, not the installed copy.

conda env export -n my-env > environment.yml
conda env remove -n my-env

The Automated Way

Finding all Python environments manually — across conda directories, scattered venvs, multiple cache locations — is tedious. That's part of why the cleanup doesn't happen: it's not hard, it's just annoying enough that you put it off.

This is exactly the problem I built MegaCleaner to solve.

MegaCleaner's Python scanner finds everything covered in this article automatically:

Conda environments across all installation paths (~/anaconda3/envs/, ~/miniconda3/envs/, ~/opt/anaconda3/envs/, ~/miniforge3/envs/, ~/mambaforge/envs/)
Virtual environments (.venv, venv, env) scattered across all your project directories, with orphan detection — it flags venvs where the parent project no longer has source files
pip cache at ~/Library/Caches/pip/
uv cache at ~/.cache/uv/
Poetry cache at ~/Library/Caches/pypoetry/
tox environments at ~/.tox/
__pycache__ directories and .pyc files across all projects
Tool caches — .ruff_cache, .mypy_cache, .pytest_cache in every project

Each item gets a confidence level: caches are marked "definitely safe," stale environments are "probably safe," and active environments are "verify first." Everything goes to Trash (undoable) — nothing is permanently deleted.

And Python is just one of 29 scanners (21 developer tools + 8 system categories). If you also use Docker, Node.js, Xcode, Rust, or Homebrew, those get scanned too.

How it works:

Scan is free — see exactly how much space Python (and everything else) is using
Confidence levels — every item is labeled so you know what's safe
One click — select what to clean, hit Clean, done
$49 one-time — not a subscription

Quick Reference Commands

Bookmark this section for next time your disk fills up.

conda env list                                    # List all environments
du -sh ~/anaconda3/envs/* 2>/dev/null             # Check environment sizes
conda env remove -n <env-name>                    # Remove an environment
conda clean --all                                 # Clean package cache

# pip
pip cache info                                    # Check cache size
pip cache purge                                   # Purge cache

# Virtual environments
find ~ -name "pyvenv.cfg" -maxdepth 5 2>/dev/null # Find all venvs
rm -rf /path/to/project/.venv                     # Remove a venv

# pyenv
pyenv versions                                    # List installed versions
pyenv uninstall <version>                         # Remove a version

# Other caches
uv cache clean                                    # Clean uv cache
poetry cache clear --all .                        # Clean Poetry cache

# __pycache__ cleanup
find ~/projects -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null

Summary

Python environments silently consume 10-50 GB on most data scientists' and ML engineers' Macs. The biggest culprits are forgotten conda environments (2-8 GB each) and duplicated ML framework installations across virtual environments.

At a minimum, do this quarterly:

Run conda env list and delete environments you don't recognize
Run conda clean --all to clear the package cache
Run pip cache purge to clear the pip download cache
Search for orphaned .venv directories in old project folders
Check ~/.pyenv/versions/ for Python versions you no longer use

The manual cleanup takes 10-15 minutes if you follow this guide. Or scan with MegaCleaner and do it in under a minute.

Either way, your hard drive will thank you.

node_modules is Why Your Mac is Full: Find and Delete All of Them

Sergey Nikiforov — Wed, 29 Apr 2026 14:32:11 +0000

I had 47 node_modules folders totaling 38GB on my Mac. Most of them were for projects I hadn't touched in months. A weekend tutorial from last year? Still has its node_modules. That side project I abandoned after two commits? node_modules. A cloned repo I opened once to read the source? You guessed it — node_modules.

If your Mac keeps telling you the disk is full and you're a JavaScript developer, there is a very good chance that node_modules is the single biggest reason why. It's not your photos. It's not your music. It's 200,000 tiny files spread across dozens of forgotten project directories.

Let's fix that.

Why node_modules Gets So Absurdly Big

If you've ever looked at a fresh node_modules folder and wondered how a project with three dependencies ended up with 900MB of installed packages, you're not imagining things. There are real structural reasons why this happens.

Flat Dependency Trees

npm v3 introduced flat dependency trees to solve the deeply nested paths problem on Windows. The trade-off? Every transitive dependency gets hoisted to the top level of node_modules. Install create-react-app and you'll find yourself with 1,400+ packages in a flat directory. Your project depends on 5 things. Those 5 things depend on 1,395 other things. All of them live in your project folder.

Duplicate Packages Across Projects

Here's where the math gets painful. If you have 10 React projects on your machine, you likely have 10 complete copies of React, 10 copies of webpack, 10 copies of TypeScript, and 10 copies of every shared dependency between them. There's no deduplication across projects. Each node_modules is an island.

A typical React project's node_modules weighs 300-500MB. A Next.js project can hit 600MB-1GB. Multiply that by every project on your machine and you start to see how 20-50GB disappears silently.

Native Binaries and Platform-Specific Code

Some packages include prebuilt native binaries — esbuild, swc, sharp, better-sqlite3, Playwright's browser binaries. These are often 50-200MB each. They compile or download platform-specific builds during npm install, and they're not small.

Build Output Hiding in Plain Sight

On top of node_modules itself, most JavaScript projects also generate build output directories: dist, build, .next, .nuxt, out. A Next.js build cache (.next) alone can be 200-500MB. These add up across projects too, and they're just as safe to delete as node_modules — they regenerate on the next build.

Finding All node_modules on Your Mac

Before you delete anything, let's see the damage. This command finds every node_modules directory under your home folder and shows its size:

find ~ -name "node_modules" -type d -maxdepth 5 -exec du -sh {} \; 2>/dev/null

You'll see output like this:

1.2G    /Users/you/projects/webapp/node_modules
487M    /Users/you/projects/api-server/node_modules
923M    /Users/you/code/nextjs-blog/node_modules
341M    /Users/you/tutorials/react-course/node_modules
756M    /Users/you/clients/dashboard/node_modules
...

Want just the total? Pipe it through awk:

find ~ -name "node_modules" -type d -maxdepth 5 -exec du -sm {} \; 2>/dev/null | awk '{total += $1} END {printf "Total: %.1f GB\n", total/1024}'

Fair warning: this command can take a minute or two to run. du has to stat every file inside every node_modules, and there are a lot of files.

If you want a quick count of how many node_modules folders you have without waiting for sizes:

find ~ -name "node_modules" -type d -maxdepth 5 2>/dev/null | wc -l

Don't be surprised if it's more than you expected. I never would have guessed 47.

The Nuclear Option: Delete Them All

Once you've seen the list, you'll probably realize that most of these projects don't need their dependencies installed right now. You can always run npm install (or yarn, or pnpm install) again later when you actually work on a project. The package.json and lockfile are what matter — node_modules is just a cache.

To delete every node_modules folder under your home directory:

find ~ -name "node_modules" -type d -maxdepth 5 -exec rm -rf {} + 2>/dev/null

A few things to know before you run this:

It's safe. node_modules is fully regenerable from your lockfile. Nothing unique lives in there.
Running projects will break. If you have a dev server running, it will crash. Stop your dev servers first.
You'll need to reinstall. The next time you cd into a project and run it, you'll need to npm install first. This is normal.
It won't touch your source code. Only the node_modules directories are deleted. Your package.json, lockfiles, and source files are untouched.

If you want to be more selective — say, only delete node_modules for projects you haven't modified in over 30 days — that's harder to do from the command line. You'd need to cross-reference each node_modules with the modification dates of the source files in the parent project directory. (This is actually something MegaCleaner does automatically — more on that below.)

Package Manager Caches: The Other Storage Hog

Deleting node_modules folders is only half the story. Your package manager also keeps a global cache of downloaded packages. This cache speeds up future installs so npm doesn't have to re-download packages from the registry, but it grows over time and can get large — especially if you work across many projects with different dependency versions.

Here's where each package manager stores its cache on macOS and how to clean it.

npm

Cache location: ~/.npm

npm's cache stores tarballs and metadata for every package you've ever installed. It grows indefinitely.

# Check size
du -sh ~/.npm

# Clean it
npm cache clean --force

The --force flag is required because npm wants you to really mean it. After cleaning, future installs will be slightly slower for the first run as packages are re-downloaded.

Yarn (v1/Classic)

Cache location: ~/Library/Caches/Yarn

You can verify the exact path on your system:

yarn cache dir

To clean it:

# Check size
du -sh ~/Library/Caches/Yarn

# Clean it
yarn cache clean

pnpm

Cache location: ~/Library/pnpm

pnpm uses a content-addressable store, which is actually more efficient than npm or yarn — it deduplicates packages across projects using hard links. That said, the store still grows over time as you install different package versions.

# Check size
du -sh ~/Library/pnpm

# Remove unreferenced packages
pnpm store prune

pnpm store prune is gentler than a full delete — it removes packages that aren't referenced by any project on your machine, but keeps the ones that are still in use.

Bun

Cache location: ~/.bun/install/cache

Bun's cache stores downloaded packages in its own format:

# Check size
du -sh ~/.bun/install/cache

There's no built-in bun cache clean command as of this writing. To clear it, you can delete the directory manually:

rm -rf ~/.bun/install/cache

Deno

Cache location: ~/.deno

Deno stores downloaded dependencies and compilation caches here:

# Check size
du -sh ~/.deno

Turborepo

Cache location: ~/.turbo

If you use Turborepo for monorepo build orchestration, it maintains a global build cache:

# Check size
du -sh ~/.turbo

The One-Liner to Check All of Them

Want to see how much space all your package manager caches are consuming? Run this:

echo "=== Package Manager Caches ===" && \
du -sh ~/.npm 2>/dev/null; \
du -sh ~/Library/Caches/Yarn 2>/dev/null; \
du -sh ~/Library/pnpm 2>/dev/null; \
du -sh ~/.bun/install/cache 2>/dev/null; \
du -sh ~/.deno 2>/dev/null; \
du -sh ~/.turbo 2>/dev/null

In my experience, the combined size of these caches ranges from 2-10GB depending on how many different projects and package versions you've worked with.

Prevention Tips: Keeping node_modules Under Control

Deleting everything feels great, but it'll grow back. Here are some strategies to keep node_modules from swallowing your disk again.

Use pnpm Instead of npm

pnpm's content-addressable store means that if 10 projects use the same version of React, only one copy exists on disk. Each project's node_modules contains hard links to the central store. In practice, this reduces total disk usage by 50-70% compared to npm.

Switching is straightforward — pnpm uses the same package.json format and can import existing lockfiles:

npm install -g pnpm
pnpm import        # converts package-lock.json to pnpm-lock.yaml
pnpm install       # creates a linked node_modules

Configure .npmrc for Smaller Installs

Add these to your ~/.npmrc to reduce what gets installed:

# Don't install optional dependencies (often native binaries you don't need)
optional=false

# Disable package-lock generation for throwaway projects
# (only use this for experiments, not real projects)
# package-lock=false

Clean Up Regularly

Set a reminder to clean node_modules every month or two. Or, if you want to remember which projects are stale, use ls -la on your project directories and sort by modification date:

# List projects by last modification date
ls -lt ~/projects/*/package.json 2>/dev/null | head -20

Don't Forget Build Artifacts

JavaScript build tools generate output directories that are just as safe to delete as node_modules. Common ones include:

dist/ — Vite, Rollup, webpack, esbuild
build/ — Create React App, various tools
.next/ — Next.js build cache and output
.nuxt/ — Nuxt.js build output
out/ — Next.js static export, other tools

These regenerate on the next npm run build. If a project is sitting idle, there's no reason to keep them around.

The Automated Way: Let MegaCleaner Handle It

The command-line approach works, but it has limitations. find is slow on large directory trees, it can't tell you which projects are stale versus actively in use, and you have to remember to run it. Plus, manually tracking six different cache directories across four package managers gets old.

MegaCleaner is a native macOS app I built specifically for this problem. Its Node.js scanner handles all of the above automatically:

What it finds:

Every node_modules folder across all your project directories and external drives
Package manager caches: npm (~/.npm), Yarn (~/Library/Caches/Yarn), pnpm (~/Library/pnpm), Bun (~/.bun/install/cache), Deno (~/.deno)
Turborepo global build cache (~/.turbo)
JS/Web build artifacts (dist, build, .next, .nuxt, out) in any project that has a package.json

What makes it smarter than find:

Staleness detection. MegaCleaner checks the modification dates of actual source files in each project (.js, .ts, .tsx, .vue, .svelte, .astro, .json, .css, .scss, and more) — not just the node_modules folder itself. If you haven't edited source code in a project for months, it marks that project's node_modules as stale and pre-selects it for cleanup.
Project name detection. It reads each project's package.json to show you human-readable project names instead of raw directory paths.
Package manager awareness. It detects which package manager each project uses by checking for lockfiles (bun.lockb, pnpm-lock.yaml, yarn.lock, package-lock.json) and shows you the correct reinstall command (bun install, pnpm install, yarn, or npm install).
No nested duplicates. It skips node_modules inside other node_modules folders to avoid double-counting, and follows canonical paths to prevent counting symlinked directories twice.
Symlink safety. It skips symbolic links entirely to avoid infinite loops and accidental deletion of linked directories.

Node.js is just one of MegaCleaner's 29 scanners. It also covers Xcode DerivedData, Docker images, Python virtual environments, Rust target directories, Go module caches, Homebrew leftovers, and more. If you're a polyglot developer, the savings add up fast.

MegaCleaner is a one-time purchase: $49, no subscription. It's a native macOS app — no Electron, no web views.

Download MegaCleaner

Quick Reference: Commands Checklist

Here's everything from this article in one place. Bookmark this section.

Find all node_modules and their sizes:

find ~ -name "node_modules" -type d -maxdepth 5 -exec du -sh {} \; 2>/dev/null

Delete all node_modules:

find ~ -name "node_modules" -type d -maxdepth 5 -exec rm -rf {} + 2>/dev/null

Clean npm cache:

npm cache clean --force

Clean Yarn cache:

yarn cache clean

Prune pnpm store:

pnpm store prune

Delete Bun cache:

rm -rf ~/.bun/install/cache

Check all cache sizes at once:

du -sh ~/.npm ~/Library/Caches/Yarn ~/Library/pnpm ~/.bun/install/cache ~/.deno ~/.turbo 2>/dev/null

JavaScript's dependency model means node_modules will always come back. The key is not to let it sit around consuming space in projects you're not actively working on. Whether you set up a monthly terminal ritual or let MegaCleaner handle it automatically, your Mac's storage will thank you.

Homebrew, Gradle, and the Hidden Caches Eating Your Mac's Storage

Sergey Nikiforov — Wed, 29 Apr 2026 14:30:00 +0000

Most developers know about the big offenders — Xcode's DerivedData, Docker images, node_modules. But there's a second tier of caches that almost nobody thinks about: Homebrew downloads, Gradle wrapper distributions, Maven repositories, Go module caches, Ruby gems, and IDE workspace storage.

None of these is massive on its own. Homebrew might be 3GB. Gradle caches, 8GB. Your IDE's workspace storage, another 4GB. But stack five or six of these together and you're looking at 20-40GB of disk space consumed by files you'll never open, never reference, and never miss if they're gone.

I built MegaCleaner specifically because I kept rediscovering these folders every few months, manually cleaning them, and then forgetting about them again. This article covers every location, every cleanup command, and the typical savings you can expect.

1. Homebrew Cache

Homebrew is installed on nearly every developer Mac, and it quietly caches every package it downloads. Upgrade a formula? The old tarball stays. Install something, try it, uninstall it? The download stays. Over time, these downloads pile up.

Where it lives:

~/Library/Caches/Homebrew/

This directory holds cached downloads, bottle tarballs, and formula metadata. Homebrew also stores build and install logs separately:

~/Library/Logs/Homebrew/

What most people don't know about: Beyond the download cache, Homebrew keeps old versions of installed formulas in its Cellar directory. If you've had a formula installed through several upgrades, each old version sits in its own folder:

/opt/homebrew/Cellar/<formula>/<old-version>/    # Apple Silicon Macs
/usr/local/Cellar/<formula>/<old-version>/       # Intel Macs

These outdated kegs aren't cleaned up automatically. If you've been running brew upgrade for a year or two, you may have dozens of old versions sitting idle.

How big it gets: 2-10GB, depending on how many packages you use and how often you upgrade. Heavy Homebrew users (those installing large casks like databases, language runtimes, or GUI apps) can see even more.

How to clean it:

Remove cached downloads (anything older than 120 days by default):

brew cleanup

Force-remove all cached downloads regardless of age:

brew cleanup -s

Remove packages that were installed only as dependencies and are no longer needed:

brew autoremove

For a full cleanup, run both:

brew cleanup -s && brew autoremove

Is it safe? Yes. Cached downloads are re-downloaded on next install. Old keg versions are only used if you explicitly brew switch to them, which almost nobody does. Homebrew logs are purely informational.

2. Gradle and Maven Caches

If you do any JVM development — Java, Kotlin, Android, Spring Boot — Gradle and Maven are downloading dependencies into local caches that grow without bound. These are some of the largest caches on a typical developer Mac.

Gradle

Where it lives:

~/.gradle/caches/

This is where Gradle stores downloaded dependencies, transformed artifacts, build cache entries, and metadata. It's the main storage consumer.

Gradle also downloads full Gradle distributions for each version referenced by the wrapper in your projects:

~/.gradle/wrapper/dists/

Each Gradle version is roughly 100-200MB, and if you work across multiple projects using different Gradle versions, you might have 5-10 versions sitting here.

How big it gets: 5-20GB. Android developers tend toward the higher end because the Android build system downloads substantial support libraries, build tools, and transformed artifacts. If you've been doing Android development for a few years, 15-20GB is common.

How to clean it:

Delete the entire cache (dependencies will re-download on next build):

rm -rf ~/.gradle/caches/

Delete old wrapper distributions:

rm -rf ~/.gradle/wrapper/dists/

Gradle itself doesn't provide a built-in cleanup command for the local cache. There's a --no-build-cache flag, but it only prevents writing to the cache — it doesn't remove existing entries.

Is it safe? Yes. Everything in ~/.gradle/caches/ is downloaded from remote repositories and will be fetched again when needed. The first build after cleaning will be slower as dependencies are re-resolved. Wrapper distributions are re-downloaded automatically.

Maven

Where it lives:

~/.m2/repository/

Maven's local repository is a mirror of every dependency your projects have ever resolved. Unlike Gradle, Maven stores artifacts in a structured directory tree (groupId/artifactId/version/), which makes it easy to browse but doesn't help with cleanup.

How big it gets: 2-10GB for most developers. If you work on large enterprise projects with extensive dependency trees, it can exceed 15GB.

How to clean it:

Delete the entire local repository:

rm -rf ~/.m2/repository/

Or use Maven's dependency plugin to selectively purge:

mvn dependency:purge-local-repository

Is it safe? Yes. Everything is re-downloaded from Maven Central (or your configured repositories) on next build. The only risk: if you have locally installed artifacts (mvn install on local projects), those will need to be rebuilt.

3. Go Module and Build Caches

Go has two distinct caches that grow independently and are both safe to clean.

Module cache

Where it lives:

~/go/pkg/mod/

This is the default location when $GOPATH is not set (which is the case for most modern Go setups). If you've customized $GOPATH, the module cache lives at $GOPATH/pkg/mod/ instead.

The module cache stores downloaded source code for every version of every dependency your Go projects have ever used. Because Go modules are versioned, switching between dependency versions doesn't remove old ones — they accumulate.

Build cache

~/.cache/go-build/

The build cache stores compiled object files so that unchanged packages don't need recompilation. This is separate from the module cache and grows based on how many packages you compile.

How big they get: 1-5GB combined for most developers. Heavy Go users working on microservice architectures with many dependencies can see more.

How to clean them:

Clear the build cache:

go clean -cache

Clear the module cache (requires sudo since Go sets directories to read-only):

go clean -modcache

Clear both:

go clean -cache -modcache

Is it safe? Yes. Modules are re-downloaded via go mod download (triggered automatically on next build). Build artifacts are recompiled as needed.

4. Ruby Gems and Bundler

Ruby's gem ecosystem creates multiple cache layers, and if you use version managers like rbenv or RVM, the storage multiplies across Ruby versions.

Gem cache

Where it lives:

~/.gem/

This directory contains downloaded gem files, compiled native extensions, and metadata for every gem you've installed. Each Ruby version gets its own subdirectory.

Bundler cache

~/.bundle/cache/

Bundler stores its own cache of downloaded gems separately from the system gem cache.

Version managers

If you use rbenv or RVM, each installed Ruby version is a full Ruby installation:

~/.rbenv/versions/     # rbenv
~/.rvm/                # RVM (entire installation)

Vendor bundles

Projects that use bundle install --deployment or bundle install --path vendor/bundle store a complete copy of all gems inside the project directory at vendor/bundle/. These are easy to overlook because they're buried inside project folders.

How big it gets: 1-5GB for the gem and bundler caches alone. Add version managers and you can add 500MB-2GB per installed Ruby version. Vendor bundles add 200MB-1GB per project.

How to clean it:

Remove old gem versions (keeps only the latest version of each gem):

gem cleanup

Preview what would be removed:

gem cleanup --dryrun

Clear bundler cache:

rm -rf ~/.bundle/cache/

Is it safe? Gem cleanup is safe — old versions are rarely needed, and gem install restores them. Be careful with version manager directories if you actively use multiple Ruby versions. Vendor bundles can be restored with bundle install.

5. IDE Caches

Your code editor or IDE maintains its own caches, extensions, and workspace state. If you use multiple IDEs, this adds up fast.

VS Code

VS Code stores caches and workspace data across several locations:

~/Library/Application Support/Code/Cache/
~/Library/Application Support/Code/CachedData/
~/Library/Application Support/Code/User/workspaceStorage/
~/.vscode/extensions/

The Cache and CachedData directories are standard Electron app caches — safe to delete, rebuilt automatically. workspaceStorage holds per-project state for extensions (search history, git state, etc.) and grows with every project you open. The extensions directory holds your installed extensions and their data.

How big it gets: 2-8GB. Workspace storage alone can be 1-4GB if you've opened many projects. Extensions can be another 1-3GB depending on how many you have installed.

Cursor and Windsurf

If you use Cursor or Windsurf (VS Code-based AI editors), they maintain their own separate caches in the same structure:

~/Library/Application Support/Cursor/Cache/
~/Library/Application Support/Cursor/CachedData/
~/.cursor/extensions/

~/Library/Application Support/Windsurf/Cache/
~/Library/Application Support/Windsurf/CachedData/

These are independent from VS Code's caches, so if you run multiple editors you're paying the storage cost for each.

JetBrains IDEs

IntelliJ IDEA, WebStorm, PyCharm, CLion, GoLand, Android Studio, RustRover, and every other JetBrains IDE stores caches and logs in versioned subdirectories:

~/Library/Caches/JetBrains/<IDEVersion>/
~/Library/Logs/JetBrains/<IDEVersion>/

For example, ~/Library/Caches/JetBrains/IntelliJIdea2024.1/. Each IDE version gets its own folder, and caches from old versions remain after you upgrade. If you've used IntelliJ through several yearly releases, you might have 4-5 old cache directories.

How big it gets: 1-5GB per IDE, multiplied by the number of versions you've had installed. Two JetBrains IDEs across three version upgrades can easily be 10-15GB of stale caches.

Sublime Text and Zed

Smaller editors leave smaller footprints, but they still cache:

~/Library/Caches/com.sublimetext.3/
~/Library/Caches/com.sublimetext.4/
~/Library/Caches/Zed/

How to clean IDE caches:

VS Code — clear caches (extensions stay intact):

rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData

JetBrains — remove old version caches (check which versions you actually use first):

ls ~/Library/Caches/JetBrains/
rm -rf ~/Library/Caches/JetBrains/IntelliJIdea2023.*/

Is it safe? Cache and CachedData directories are safe — IDEs rebuild them on launch. Workspace storage is safe to clear but you'll lose per-project editor state. Extensions directories should be handled with care — deleting them means reinstalling your extensions.

6. The Combined Impact

Here's what all of these look like together. On a developer Mac that's been in use for a year or more, these are typical numbers:

Tool	Cache Path	Typical Size
Homebrew cache	`~/Library/Caches/Homebrew/`	2-5 GB
Homebrew logs	`~/Library/Logs/Homebrew/`	100-500 MB
Homebrew outdated kegs	`/opt/homebrew/Cellar/*/`	500 MB-3 GB
Gradle caches	`~/.gradle/caches/`	5-15 GB
Gradle wrapper	`~/.gradle/wrapper/dists/`	500 MB-2 GB
Maven repository	`~/.m2/repository/`	2-10 GB
Go module cache	`~/go/pkg/mod/`	1-3 GB
Go build cache	`~/.cache/go-build/`	500 MB-2 GB
Ruby gems	`~/.gem/`	500 MB-2 GB
Bundler cache	`~/.bundle/cache/`	200 MB-1 GB
VS Code caches	`~/Library/Application Support/Code/`	2-5 GB
JetBrains caches	`~/Library/Caches/JetBrains/`	2-10 GB
Total		~20-50 GB

That's 20-50GB of disk space consumed by caches from tools that aren't even your primary development stack in many cases. And none of these clean themselves up automatically.

The uncomfortable truth: even if you're diligent about running cleanup commands, you have to remember to do it. For each tool. Regularly. Most developers run brew cleanup once, feel good about it, and then forget for six months.

7. The Automated Way

This is the problem I built MegaCleaner to solve.

MegaCleaner is a native macOS app with 29 specialized scanners — 21 for developer tools (including dedicated scanners for Homebrew, Gradle/Maven, Go, Ruby, and IDE caches) and 8 for general macOS cleanup. It scans every path covered in this article, plus Xcode, Docker, Node.js, Python, Rust, Cocoapods, SPM, and more.

What it does that manual cleanup doesn't:

Scans all tools at once — no switching between terminals and remembering paths.
Shows you exactly what's stale — MegaCleaner tracks file modification dates and flags caches that haven't been touched in weeks or months, so you can keep recent caches and clean only what's truly idle.
Handles outdated Homebrew kegs — it identifies old formula versions in the Cellar, keeping only the latest version of each package.
Finds IDE caches across editors — VS Code, Cursor, Windsurf, JetBrains (all IDEs, all versions), Sublime Text, Zed, even Vim/Neovim undo files. If you use more than one editor, this adds up.
Discovers vendor bundles in projects — finds vendor/bundle directories buried inside Ruby projects across your codebase.
Respects $GOPATH — automatically resolves custom Go paths instead of assuming the default.

Pricing: $49 one-time purchase. No subscription. Free updates.

Download MegaCleaner

8. Quick Reference Commands

Bookmark this section. Here's every cleanup command from this article in one place:

Homebrew

brew cleanup -s          # Remove all cached downloads
brew autoremove          # Remove unused dependencies

Gradle

rm -rf ~/.gradle/caches/         # Delete dependency cache
rm -rf ~/.gradle/wrapper/dists/  # Delete wrapper distributions

Maven

rm -rf ~/.m2/repository/         # Delete local repository

Go

go clean -cache       # Clear build cache
go clean -modcache    # Clear module cache

Ruby

gem cleanup              # Remove old gem versions
rm -rf ~/.bundle/cache/  # Clear Bundler cache

VS Code

rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData
rm -rf ~/Library/Application\ Support/Code/User/workspaceStorage

JetBrains

ls ~/Library/Caches/JetBrains/
ls ~/Library/Logs/JetBrains/
# Then remove old versions selectively

Nuclear option (everything at once)

brew cleanup -s && brew autoremove
rm -rf ~/.gradle/caches/ ~/.gradle/wrapper/dists/
rm -rf ~/.m2/repository/
go clean -cache -modcache
gem cleanup
rm -rf ~/.bundle/cache/
rm -rf ~/Library/Application\ Support/Code/Cache
rm -rf ~/Library/Application\ Support/Code/CachedData

Fair warning: the nuclear option means slower first builds across all your projects as dependencies are re-downloaded. It's safe, but plan for it.

Wrapping Up

Developer tool caches are a death-by-a-thousand-cuts storage problem. No single one is outrageous, but they compound. And they all share the same characteristic: they grow without limit and never clean themselves up.

You have two options. You can bookmark this article and run through the commands every few months. Or you can let MegaCleaner scan everything in one pass and show you exactly what's safe to remove, with size and staleness information for every item.

Either way, go check ~/Library/Caches/Homebrew/ and ~/.gradle/caches/ right now. You might be surprised.

Docker Ate Your Disk: Reclaiming 20-50GB on macOS

Sergey Nikiforov — Wed, 29 Apr 2026 14:10:07 +0000

Docker Desktop was using 67GB on my Mac. I didn't notice until my build failed with "no space left on device" and I started digging.

67GB. For containers I hadn't run in months, images I'd pulled once for a quick test, build cache from projects I'd abandoned, and a VM disk file that had ballooned to 40GB and refused to shrink.

If you're a developer running Docker on macOS, you're almost certainly in the same situation. Docker is designed to cache aggressively and clean up never. On Linux, Docker stores everything directly on the filesystem, so standard disk tools can see it. On macOS, Docker runs inside a Linux VM — and everything it stores is hidden inside a single disk image file. That file only grows. It never shrinks on its own.

This guide covers every category of Docker disk usage on macOS: what it is, how to find it, how to clean it, and how to stop it from coming back.

How Docker Uses Disk on macOS

Before we start cleaning, it helps to understand why Docker on macOS is a special kind of disk hog.

Docker containers are Linux. macOS is not Linux. So Docker Desktop runs a lightweight Linux virtual machine behind the scenes, and all your images, containers, volumes, and build cache live inside that VM's virtual disk. That disk is a single file on your Mac — typically called Docker.raw or Docker.qcow2.

Here's the problem: the VM disk file is dynamically allocated. It grows as Docker stores more data inside it. But when you delete images or containers inside Docker, the VM disk file does not shrink. The space is freed inside the VM, but the file on your Mac stays the same size.

This means Docker's disk usage on macOS is driven by two things:

What's inside Docker — images, containers, volumes, build cache
The VM disk file itself — which remembers its high-water mark

You need to address both.

Finding How Much Space Docker Uses

Start by asking Docker itself:

docker system df

This shows a breakdown by category:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          47        3         18.72GB   16.48GB (88%)
Containers      12        1         1.24GB    1.19GB (95%)
Local Volumes   23        2         8.31GB    7.89GB (95%)
Build Cache     184       0         14.2GB    14.2GB (100%)

That's what Docker knows about. But it doesn't tell you the size of the VM disk file on your Mac's filesystem — which is often much larger than the sum of those numbers.

To see the VM disk file size:

ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Don't be surprised if this file is 40-60GB even when docker system df reports only 15-20GB of actual content.

For a more detailed breakdown, add the verbose flag:

docker system df -v

This lists every image, container, and volume individually with sizes — useful for finding the worst offenders.

Images: Dangling and Unused

What they are: Every docker pull and docker build downloads or creates image layers. Over time, you accumulate images from projects you no longer work on, base images for stacks you've moved away from, and "dangling" images — intermediate layers that aren't tagged and aren't referenced by any other image.

How big they get: 5-25GB easily. A single Node.js or Python image can be 1GB+. If you work across multiple projects with different base images, this stacks up fast.

How to see them:

docker images -a

# Show only dangling images (untagged, unreferenced)
docker images -f "dangling=true"

How to clean them:

Remove only dangling images (safe, minimal impact):

docker image prune

Remove all images not used by a running container (more aggressive, frees the most space):

docker image prune -a

You'll be prompted to confirm. Add -f to skip the confirmation prompt.

Is it safe? Dangling images are always safe to remove — they're orphaned layers that serve no purpose. Unused images (the -a flag) are also safe, but you'll need to re-pull them if you want to use them again. If you have a slow connection or work with large proprietary images, consider being selective.

Re-pulling is cheap: For public images, docker pull node:20 takes 30 seconds on a decent connection. The disk space you save is worth more than the re-download time.

Containers: Stopped and Dead

What they are: Every docker run creates a container. When the process exits, the container stays on disk in a "stopped" state. It retains its filesystem layer (any files written during execution) and metadata. Most developers have dozens of stopped containers they've forgotten about.

How big they get: Usually 100MB-2GB total, but containers that wrote large files (logs, databases, build artifacts) can individually be much larger.

How to see them:

docker ps -a

# Show only stopped containers
docker ps -a -f "status=exited"

How to clean them:

docker container prune

This removes all containers with status exited, dead, or created (never started).

Is it safe? If a container is stopped and you don't plan to docker start it again, yes. Any data not stored in a volume is lost when the container is removed — that's the point. If you need the data, copy it out first with docker cp.

Volumes: Orphaned Data

What they are: Docker volumes are persistent storage that survives container removal. They're used for databases, file uploads, configuration — anything that should persist across container restarts. The problem is that volumes are not automatically deleted when the container that created them is removed.

Over time, you accumulate "dangling" volumes — volumes that no running or stopped container references. These are pure dead weight.

How big they get: 2-15GB. Database volumes (Postgres, MySQL, MongoDB) can individually be several GB. If you've been spinning up database containers for different projects, this adds up.

How to see them:

docker volume ls

# Show only dangling (unused) volumes
docker volume ls -f "dangling=true"

How to clean them:

docker volume prune

This removes only dangling volumes — ones not referenced by any container (running or stopped).

Is it safe? Dangling volumes are by definition not attached to any container. But they may contain data you care about — old database dumps, uploaded files, test fixtures. If in doubt, inspect a volume before removing it:

docker volume inspect <volume_name>

Check the Mountpoint path and verify what's inside if you're unsure.

Warning: Volume data is not recoverable after deletion. Unlike images (which can be re-pulled) and containers (which can be re-run), volume data is gone forever. Be more careful here than with other categories.

Build Cache: The Silent Hog

What it is: Docker's BuildKit caches intermediate build steps so that subsequent builds are faster. Every RUN instruction in your Dockerfile produces a cached layer. Over time — especially if you work with multiple projects or iterate frequently — this cache grows large.

How big it gets: 5-20GB is common. If you build large images (anything with native compilation, ML dependencies, or monorepos), the cache can exceed 30GB.

How to see it:

docker system df

The "Build Cache" row shows total size and how much is reclaimable. Usually 100% is reclaimable.

How to clean it:

docker builder prune

To remove all build cache including tagged intermediate results:

docker builder prune -a

Is it safe? Completely. Build cache is a performance optimization, not data. Your next build will be slower (it has to re-execute cached steps), but everything still works. If you're not actively iterating on Docker builds, this is free space.

The Nuclear Option

If you want to clean everything at once — all unused images, all stopped containers, all dangling volumes, and all build cache — Docker provides a single command:

docker system prune -a --volumes

This is the "start fresh" button. It keeps only:

Running containers
Images used by running containers
Volumes used by running containers

Everything else is removed.

When to use it: When you haven't done a cleanup in months and don't have any stopped containers or images you need to preserve. I run this roughly quarterly and it typically frees 15-30GB.

When NOT to use it: If you have stopped containers with data you haven't extracted, or named volumes with database data you still need. Review docker ps -a and docker volume ls first.

Docker.raw: The File That Never Shrinks

This is the part most guides skip, and it's usually the biggest chunk of wasted space.

What it is: The virtual disk file for Docker's Linux VM. All Docker data (images, containers, volumes, cache) lives inside this file. On macOS, it's typically at:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Depending on your Docker Desktop version and architecture, it might also be at:

~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.raw
~/.docker/desktop/vms/0/data/Docker.raw

The file format may be .raw or .qcow2 depending on your Docker Desktop settings.

Why it's a problem: Docker.raw uses sparse/dynamic allocation. It grows when Docker needs more space but does not automatically shrink when space is freed inside the VM. If your Docker usage peaked at 50GB at some point — even if you've since pruned everything — the file stays at 50GB.

How to check its size:

ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Compare this to what docker system df reports. The difference is wasted space — freed inside the VM but not released back to macOS.

How to reclaim the space:

The most reliable way to shrink Docker.raw is to reset the Docker Desktop VM:

Open Docker Desktop > Settings > Resources > Disk image size
Note the current allocation
Quit Docker Desktop completely
Delete the disk image file:

   rm ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Start Docker Desktop — it creates a fresh, small disk image
Re-pull only the images you actually need

This is the most effective single action you can take. Going from a 50GB Docker.raw to a fresh 2GB one is a common outcome.

Alternative — reduce the disk size limit:

In Docker Desktop, go to Settings > Resources > Advanced and lower the "Disk image size" slider. This sets the maximum size the VM disk can grow to. Reducing it from the default 64GB to 32GB (or whatever your actual usage requires) prevents future bloat.

After reducing the limit, Docker Desktop may need to recreate the disk image. Back up any volumes you need before doing this.

Not Just Docker Desktop: Colima and OrbStack

If you use Docker alternatives like Colima or OrbStack instead of Docker Desktop, you have the same VM disk problem — just in different locations:

Runtime	Disk Image Path
Docker Desktop	`~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`
Colima	`~/.colima/default/colima.qcow2` and `~/.colima/default/diffdisk`
OrbStack	`~/.orbstack/data/disk.img`

The same cleanup principles apply: prune Docker content first, then address the VM disk file if it's oversized.

Prevention: Keeping Docker Lean

Cleaning up is good. Not accumulating junk in the first place is better.

Use Multi-Stage Builds

Multi-stage Dockerfiles separate the build environment from the runtime environment. Your final image contains only what's needed to run — no compilers, no dev dependencies, no build artifacts.

FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Runtime stage — small, only production dependencies
FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

This alone can reduce image sizes from 1.5GB to 200MB.

Use .dockerignore

A .dockerignore file prevents large, irrelevant files from being copied into the Docker build context. Without it, Docker sends your entire project directory to the build daemon — including node_modules, .git, test fixtures, and anything else in the folder.

node_modules
.git
*.md
.env
dist
coverage
.DS_Store

Set Up a Prune Schedule

Add a monthly cleanup to your calendar, or add it to your shell profile:

# Add to ~/.zshrc or ~/.bashrc
alias docker-cleanup='docker system prune -a --volumes -f && echo "Docker cleanup complete"'

Use --rm for Temporary Containers

When running containers you don't need to keep:

docker run --rm -it ubuntu:22.04 bash

The --rm flag automatically removes the container when it exits — no stopped container left behind.

Lower the Disk Size Limit

In Docker Desktop settings, reduce the disk image size from the default 64GB to something reasonable for your workload. 32GB is enough for most developers. This caps the Docker.raw file growth.

The Automated Way

If you're reading this and thinking "I do not want to remember all these commands and run them manually every month" — I built MegaCleaner for exactly this reason.

MegaCleaner's Docker scanner covers all five categories described in this guide:

Docker Images — finds all images, flags dangling ones as definitely safe to remove
Docker Containers — identifies stopped and exited containers
Docker Volumes — detects unused/orphaned volumes
Docker Build Cache — shows reclaimable build cache with exact sizes
VM Disk Files — locates Docker.raw, qcow2, Colima, and OrbStack disk images and reports their sizes

It pulls data directly from the Docker CLI (same docker images, docker ps, docker volume ls, and docker system df commands described above) and presents everything in a single view with confidence levels: "definitely safe" for dangling images and build cache, "probably safe" for stopped containers and unused volumes, "verify first" for VM disk files.

And Docker is just one of 29 scanners (21 developer tools + 8 system categories). If you're also running Xcode, node_modules, Python environments, Rust/Cargo, Homebrew, or any of the other tools developers accumulate — MegaCleaner scans all of them in seconds.

Scanning is always free — see the full breakdown before paying anything
$49 one-time — not a subscription
Everything goes to Trash — fully undoable

Download at megacleaner.app.

Quick Reference: All Commands in One Block

Bookmark this. You'll need it again in three months.

docker system df            # Summary by category
docker system df -v         # Detailed per-item breakdown

# ── Clean by category ────────────────────────────────
docker image prune          # Remove dangling images only
docker image prune -a       # Remove ALL unused images
docker container prune      # Remove stopped containers
docker volume prune         # Remove orphaned volumes
docker builder prune        # Remove build cache
docker builder prune -a     # Remove ALL build cache

# ── Nuclear option ───────────────────────────────────
docker system prune -a --volumes   # Remove everything unused

# ── Check VM disk file size ──────────────────────────
ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

# ── Prevent container accumulation ───────────────────
docker run --rm -it <image> <cmd>   # Auto-remove on exit

# ── Clean alias (add to ~/.zshrc) ────────────────────
alias docker-cleanup='docker system prune -a --volumes -f'

Summary

Docker on macOS consumes disk through five channels: images, containers, volumes, build cache, and the VM disk file. The first four are standard Docker content that docker system prune handles. The fifth — Docker.raw — is the one most people miss, and it's often the biggest offender because it never shrinks automatically.

A full cleanup looks like this:

Run docker system df to see the damage
Prune each category (or use docker system prune -a --volumes for everything)
Check the Docker.raw file size — if it's much larger than your Docker content, reset it
Lower the disk size limit in Docker Desktop settings to prevent future bloat
Adopt prevention habits: multi-stage builds, .dockerignore, --rm flag, regular prune schedules

Do this quarterly and Docker will never silently eat 50GB of your disk again. Or scan with MegaCleaner and handle it in under a minute.

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

Sergey Nikiforov — Wed, 29 Apr 2026 13:15:08 +0000

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:

Download dependencies, SDKs, container images, or runtimes
Cache compiled artifacts, build products, and intermediate files
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.

CleanMyMac vs MegaCleaner: Why Generic Cleaners Miss 80% of Developer Bloat

Sergey Nikiforov — Wed, 29 Apr 2026 13:07:14 +0000

You're a developer. Your Mac says you have 15GB free. You download CleanMyMac, run a scan, and it proudly offers to clean 4.7GB of system caches and browser data. You clean it. The number barely moves. Meanwhile, you have 40GB of stale node_modules folders, 25GB of Xcode DerivedData, 18GB of Docker images you forgot about, and 8GB of Rust target/ directories scattered across old projects.

That's not CleanMyMac's fault. It was never designed to find those things. It's a general-purpose Mac cleaner built for everyone — your parents, your coworkers in marketing, your friend who just wants their MacBook to stop saying "Your disk is almost full."

But as a developer, your storage problem is fundamentally different. Most of your disk bloat comes from tools that generic cleaners don't even know exist.

This article is a fair, honest comparison of CleanMyMac, MegaCleaner, DevCleaner for Xcode, and DaisyDisk. Each has real strengths. The right choice depends on who you are and what's eating your disk.

Why Developer Disks Are Different

A typical Mac user's storage problem is old photos, browser cache, duplicate files, forgotten app data. Generic cleaners handle this well — they scan ~/Library/Caches, system temp files, browser data, mail attachments, and old logs. That covers 90% of Mac users.

A developer's storage problem is fundamentally different:

Category	Typical Size	What Creates It
Xcode DerivedData	10-50 GB	Every build of every project, forever
iOS Simulators & Runtimes	20-150 GB	Each iOS version = 5-8 GB
`node_modules` directories	10-60 GB	Every JS/TS project, often duplicated
Docker images & volumes	10-50 GB	Docker.raw grows silently
Cargo `target/` folders	5-30 GB	Rust builds are notoriously large
Python venvs & conda envs	5-20 GB	Forgotten environments accumulate
Gradle/Maven caches	3-15 GB	Java/Android build caches
Homebrew cache	2-10 GB	Downloaded bottles and logs
IDE caches	2-10 GB	VS Code, JetBrains, Zed extensions/cache

Total developer-specific bloat: 60-300+ GB. This is space that CleanMyMac, by design, does not scan.

These aren't "system junk" — they're the byproducts of development tools. Scanning them requires knowing what each tool creates, where it stores data, and what's safe to delete. That's the gap MegaCleaner was built to fill.

What CleanMyMac Actually Does Well

Before comparing, CleanMyMac deserves its credit. MacPaw has been building it for over a decade, and it's a polished product. It organizes its tools into five categories:

Cleanup — System junk, old caches, broken downloads, mail attachments, language files, and about 20 other categories of system-level waste.
Protection — A proprietary malware scanner that MacPaw claims detects 99% of macOS-specific threats. This is a real feature with a continuously updated threat database.
Performance — Maintenance scripts, DNS cache clearing, Spotlight re-indexing, login item management, RAM optimization.
Applications — Full app uninstaller that finds and removes leftover files when you drag an app to Trash. Also identifies old, unused applications.
My Clutter — Finds large and old files across your system and helps you decide what to keep.

For general Mac maintenance, this is a strong package. The malware scanner and app uninstaller are genuinely useful features that most competing tools don't offer.

Where it stops: CleanMyMac treats your Mac as a consumer device. It doesn't know that ~/Library/Developer/Xcode/DerivedData contains build caches, that ~/.cargo/registry is a package cache, or that 47 node_modules folders scattered across your home directory are safe to delete. It may catch some of these under "System Junk," but it won't systematically find, categorize, or explain them.

What MegaCleaner Does Differently

MegaCleaner approaches the problem from the opposite direction. It was built by a developer (me — I'm the solo founder), specifically because I kept running out of disk space and no existing tool could find what was actually using it.

MegaCleaner has 29 scanners: 21 for developer tools and 8 for general system cleaning.

The 21 Developer Tool Scanners

Xcode — DerivedData, simulators, archives, device support, documentation cache, old Xcode versions (6 sub-categories)
CocoaPods — Pod cache and spec repositories
Swift Package Manager — Build artifacts and package cache
Docker — Images, containers, volumes, build cache, Desktop VM (Docker.raw)
Homebrew — Bottle cache, downloads, logs
node_modules — Recursive discovery across all projects, plus npm/yarn/pnpm/bun caches, duplicate detection
Python — Virtual environments, conda environments, pip cache
Rust/Cargo — Registry cache, target/ directories across all projects
Go — Module cache, build artifacts
Java — Maven .m2 cache, Gradle caches
Android — SDK components, emulator images, build cache
Flutter/Dart — Flutter cache, Dart package cache
C/C++ — CMake build artifacts, Conan package cache
.NET — NuGet cache, build artifacts
PHP — Composer cache
Ruby — Gem cache, Bundler cache
Git Repositories — Duplicate repos, repository history bloat
Git Worktrees — Forgotten/orphaned worktrees
IDE Caches — VS Code, JetBrains (IntelliJ, WebStorm, etc.), Sublime Text, Zed, Vim/Neovim
Playwright — Browser downloads and test cache
Terraform — .terraform directories with provider binaries

The 8 General Scanners

Browser cache, system caches and logs, downloads folder, Trash, Mail data, orphaned app data, iOS backups, and log files. These overlap somewhat with what CleanMyMac does, though with less depth in this category.

Confidence Levels

Every item MegaCleaner finds is tagged with one of three confidence levels:

Definite — 100% safe to delete. DerivedData, caches, temp files. These regenerate automatically.
Probable — Very likely safe. Old archives, stale dependencies, unused simulator runtimes. Reasonable to delete, but worth a glance.
Possible — User should verify. Large files in ambiguous locations, old project directories, things that might matter.

This matters because developer files aren't all equal. Deleting DerivedData has zero risk — it rebuilds in minutes. Deleting an Xcode archive for a build that's currently in the App Store review queue would be a problem. The confidence system lets you clean aggressively on "definite" items and make informed decisions on everything else.

Head-to-Head Comparison

Here's the full feature comparison across four tools. I'm including DevCleaner for Xcode and DaisyDisk because they come up in every "best Mac cleaner" discussion and serve specific niches well.

Feature	MegaCleaner	CleanMyMac	DevCleaner for Xcode	DaisyDisk
Price	$49 one-time	~$40/yr subscription or ~$196 one-time	Free (open source)	$10 one-time
Pricing model	One-time purchase	Subscription or one-time	Free (GPL-3)	One-time purchase
Free scanning	Yes — scan free, pay to clean	No — requires license	Fully free	Scan free, no cleaning engine
Dev tool scanners	21 tools (Xcode, Docker, npm, Python, Rust, Go, Java, etc.)	No dev-specific scanning	Xcode only (6 categories)	None — disk visualizer only
General cleaning	8 scanners (browser, system cache, downloads, etc.)	20+ categories, very thorough	None	None — shows files, manual deletion
Confidence/safety levels	3 tiers (definite, probable, possible)	No per-item safety rating	No	N/A
Malware scanning	No	Yes — proprietary engine, continuously updated	No	No
App uninstaller	No	Yes — finds app leftovers	No	No
Disk visualization	No	Basic	No	Yes — interactive sunburst map
Performance tools	No	Yes — RAM, DNS, login items, maintenance scripts	No	No
Deletion method	Move to Trash (undoable)	Permanent delete	Permanent delete	Manual (Finder)
Native macOS app	Yes (Swift/SwiftUI)	Yes (Objective-C/Swift)	Yes (Swift)	Yes (Objective-C)
Open source	No	No	Yes (GPL-3)	No
macOS requirement	14.0+ (Sonoma)	13.0+ (Ventura)	12.0+ (Monterey)	10.13+
Team behind it	Solo developer	MacPaw (200+ employees)	Solo developer	Software Ambiance (small team)

A few notes on this table:

CleanMyMac's pricing is complex. The subscription runs roughly $40/year for one Mac. The one-time purchase (~$196) only covers the current major version — future major releases require a new purchase. Multi-Mac plans are available at higher prices.

DevCleaner is genuinely free and good — if Xcode is your only concern. It covers DerivedData, simulators, archives, device support, and documentation caches. Open source (GPL-3), on the Mac App Store. The limitation is scope: it doesn't touch Docker, node_modules, Python, Rust, or any non-Xcode tool.

DaisyDisk is a different category. It's a disk space visualizer, not a cleaner — a beautiful interactive map of what's using your disk, at $10 one-time. But it doesn't know what any file is. You need domain knowledge to decide what's safe to delete.

Where CleanMyMac Wins

Let's be honest about what CleanMyMac does better than MegaCleaner:

Malware scanning. MegaCleaner doesn't scan for malware at all. CleanMyMac has a proprietary anti-malware engine with a continuously updated threat database. If you want malware protection bundled with your cleaning tool, CleanMyMac is the only option here.

App uninstaller. When you drag an app to Trash on macOS, it leaves behind preferences, caches, login items, and support files scattered across ~/Library. CleanMyMac finds and removes all of that. MegaCleaner doesn't have an app uninstaller.

General system cleaning depth. A decade of refinement with a large team shows. CleanMyMac catches more types of system junk and offers more granular control over language files, old logs, and similar items. MegaCleaner's 8 general scanners cover the basics but don't go as deep.

Performance and maintenance tools. RAM freeing, DNS cache flushing, Spotlight re-indexing, login item management — CleanMyMac bundles a full system utility suite. MegaCleaner is purely a disk cleaner.

Polish and track record. MacPaw has 200+ employees and millions of users. The UI is refined, the documentation is extensive. MegaCleaner is a solo-developer product — functional and clean, but newer and less proven.

Where MegaCleaner Wins

Now the other side:

Developer tool intelligence. This is the core differentiator. 21 dedicated scanners that understand the structure and safety characteristics of each tool's output. MegaCleaner knows that DerivedData is always safe but Xcode archives might not be, that node_modules can be regenerated with npm install, and that Docker.raw can be reclaimed but active containers shouldn't be removed. CleanMyMac has no equivalent.

Confidence levels. Every item MegaCleaner finds is categorized as "definite," "probable," or "possible" for deletion safety. This gives you the information to make smart decisions without needing to research each file path yourself. No other tool in this comparison offers this.

One-time pricing. $49, once, forever. No subscription, no annual renewal, no "this version only" restrictions. CleanMyMac's subscription means paying ~$40/year indefinitely, and their "one-time" purchase only covers the current major version.

Free scanning. Download MegaCleaner, scan your entire system, see exactly how much space each dev tool is wasting — all without paying. The license is only required to clean. Verify the value before spending a dollar.

Move to Trash, not permanent delete. MegaCleaner sends everything to Trash instead of permanently deleting. Need something back? It's recoverable. CleanMyMac permanently deletes by default.

Built for developers, by a developer. I built MegaCleaner because I had this exact problem — working across Swift, TypeScript, Rust, Python, and Go, tired of running du -sh commands to find what was eating my disk. Every scanner exists because it solves a real problem I've hit.

Who Should Use What

Here's a simple decision framework:

You're not a developer

Use CleanMyMac. It's the best general-purpose Mac cleaner available. The malware scanning, app uninstaller, and system maintenance tools are genuinely useful for everyday Mac users. MegaCleaner's developer scanners would find nothing relevant on your machine.

You're an iOS/Swift developer and Xcode is your only concern

Start with DevCleaner for Xcode. It's free, open source, and covers Xcode storage categories well. If you find yourself wanting more — scanning Docker, node_modules, or other tools — then look at MegaCleaner.

You want to visualize what's using your disk before deciding what to do

Use DaisyDisk. At $10, it's the best disk space visualizer on macOS. It won't tell you what's safe to delete, but it gives you a clear picture of where space is going. Pair it with domain knowledge and you can clean manually.

You're a developer who works across multiple tools and languages

Use MegaCleaner. This is exactly what it was built for. If you work with any combination of Xcode, Docker, Node.js, Python, Rust, Go, Java, or the other tools on the list, MegaCleaner will find tens of gigabytes that no other tool catches. The confidence levels make it safe to clean without second-guessing.

You want the most comprehensive setup

Use both. MegaCleaner handles the 60-300 GB of developer tool bloat. CleanMyMac handles malware scanning, app uninstalling, and deeper general system cleaning. They complement each other with almost no overlap.

A Note on "Free" Alternatives

If you search for "cleanmymac alternative free," a few options are worth knowing about: DevCleaner for Xcode is genuinely free and good, but Xcode-only. AppCleaner by FreeMacSoft is a free app uninstaller that does one thing well. OnyX is a free system maintenance utility — powerful but technical, not focused on disk cleaning. And of course there are manual terminal commands (docker system prune, rm -rf node_modules, cargo clean) — free by definition, but tedious across dozens of projects. That's exactly what MegaCleaner automates.

MegaCleaner itself is free to scan — the $49 license is only required to clean.

The Honest Take

CleanMyMac is a better product for general Mac users. It has more features, more polish, a larger team, malware protection, and a decade of refinement. If you're not a developer, or if your development doesn't generate significant disk bloat, CleanMyMac covers your needs better.

MegaCleaner is a better product for developers. It finds 5-20x more reclaimable space on a developer's machine because it understands the tools developers use. The 21 developer scanners, confidence levels, and one-time pricing make it a straightforward value proposition — scan for free, see the number, decide if $49 is worth it.

They're not really competitors. CleanMyMac cleans your Mac. MegaCleaner cleans your development environment. The overlap is small. The ideal developer setup might genuinely include both.

The real question is simple: do you have developer tools installed? If yes, run a free MegaCleaner scan. The number will speak for itself.

Download MegaCleaner — free to scan, no subscription.

How to Clean Up Xcode and Free 30-50GB on Your Mac

Sergey Nikiforov — Sat, 04 Apr 2026 18:52:02 +0000

Xcode is the single biggest storage consumer on most developers' Macs. A fresh install starts around 35GB, but over months of development it quietly grows to 80, 100, even 150GB+. Most of that growth is invisible — cached build products, old simulators, debug symbols for iOS versions you no longer use.

I've been building iOS apps for years, and this problem is exactly why I built MegaCleaner — I got tired of manually tracking down these hidden folders every few months. But whether you use a tool or do it by hand, you should know where the space goes.

This guide covers every Xcode storage category: what it is, where it lives, how big it typically gets, and whether it's safe to delete. No guesswork, no vague advice — just exact paths and clear safety levels.

Quick Reference

Before we dive in, here's the full picture. Bookmark this table — you'll want it next time your Mac complains about storage.

Category	Path	Typical Size	Safe to Delete?
DerivedData	`~/Library/Developer/Xcode/DerivedData`	10-50 GB	Yes — rebuilds automatically
Simulators	`~/Library/Developer/CoreSimulator/Devices`	20-150 GB	Yes for old versions
Archives	`~/Library/Developer/Xcode/Archives`	5-30 GB	Yes if older than 6 months
Device Support	`~/Library/Developer/Xcode/iOS DeviceSupport`	10-40 GB	Yes for old iOS versions
Module/Doc Cache	`~/Library/Developer/Xcode/DocumentationCache`	1-5 GB	Yes — regenerates
Old Xcode Versions	`/Applications/Xcode*.app`	12-30 GB each	Verify first
CocoaPods Cache	`~/Library/Caches/CocoaPods`	1-5 GB	Yes — `pod install` restores
SPM Cache	`~/Library/Caches/org.swift.swiftpm`	1-5 GB	Yes — `swift package resolve` restores

Total potential savings: 30-150+ GB depending on how long you've been developing.

Now let's go through each one.

1. DerivedData

What it is: Every time you build a project in Xcode, it stores compiled objects, indexes, logs, and debug info in a project-specific subfolder. These are named ProjectName-uniqueID (the unique ID is a 28-character hash), so you can identify which project each folder belongs to.

Where it lives:

~/Library/Developer/Xcode/DerivedData/

How big it gets: 10-50 GB depending on how many projects you work on. Each active project adds 500 MB to several GB of build artifacts. Since Xcode never cleans these up automatically, they accumulate forever.

How to clean it:

From Terminal — delete everything:

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

Or selectively — delete a specific project's cache:

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

From Xcode — go to Settings > Locations, click the small arrow next to the DerivedData path to open it in Finder, then select and delete the contents.

Is it safe? Yes. DerivedData is completely regenerated on your next build. The only cost is a slightly longer first build after cleaning — typically 1-5 minutes depending on project size. This is the single safest cleanup you can do.

Pro tip: If you're mid-project and don't want to rebuild everything, delete only the folders for projects you haven't touched in a while. The folder names include the project name, so it's easy to tell which is which.

2. Simulators and Runtimes

What they are: iOS, watchOS, tvOS, and visionOS simulator instances — full virtual devices that Xcode uses for testing. Each runtime version (iOS 17.5, iOS 18.2, etc.) is a separate download, and each simulated device (iPhone 16 Pro, iPad Air, etc.) creates its own data folder.

Where they live:

~/Library/Developer/CoreSimulator/Devices/

How big they get: This is typically the largest category — 20-150 GB. Each simulator runtime is 5-8 GB. If you've been developing through multiple iOS versions (17, 18, 26), the runtimes alone can be 30-50 GB. Add device data folders and it grows fast.

How to clean it:

First, remove simulators for iOS versions that Xcode no longer supports:

xcrun simctl delete unavailable

List all installed simulators to see what you have:

xcrun simctl list devices

Delete a specific simulator by its UUID:

xcrun simctl delete <UDID>

Remove old runtimes you no longer need:

xcrun simctl runtime delete "iOS 17.5"

You can also manage simulators in Xcode: Window > Devices and Simulators, then right-click any device to delete it.

Is it safe? For old iOS versions (more than 2 major versions behind), absolutely — you're never going to debug against iOS 16 when you're building for iOS 26. For current versions, it's safe but you'll need to re-download the runtime if you delete it (5-8 GB download).

Watch for orphans: Sometimes simulator device folders survive crashes or manual cleanup attempts. These folders exist on disk but don't appear in xcrun simctl list. They're dead weight — safe to delete.

3. Archives

What they are: .xcarchive bundles created every time you build for distribution (Product > Archive). Each archive contains the compiled app, debug symbols (dSYMs), and metadata. They're organized by date in subfolders like 2026-03-15/.

Where they live:

~/Library/Developer/Xcode/Archives/

How big they get: 5-30 GB. Individual archives range from 100 MB to 2+ GB depending on app size. If you archive regularly, this adds up.

How to clean it:

From Xcode — Window > Organizer > Archives. Right-click an archive and select Delete.

From Terminal — remove archives older than 6 months:

find ~/Library/Developer/Xcode/Archives -name "*.xcarchive" -mtime +180 -exec rm -rf {} +

Is it safe? For archives older than 6 months: yes. The main reason to keep archives is their dSYM files, which you need to symbolicate crash reports. If you've uploaded the build to App Store Connect, Apple retains the dSYMs — so your local copy is redundant.

For recent archives of builds currently in production: keep them until you've confirmed the dSYMs are uploaded.

4. Device Support Files

What they are: Debug symbol caches that Xcode downloads when you connect a physical iPhone, iPad, or Apple Watch. They allow Xcode to symbolicate crash logs and debug on-device.

Where they live:

~/Library/Developer/Xcode/iOS DeviceSupport/
~/Library/Developer/Xcode/watchOS DeviceSupport/

Folder names follow the format DeviceModel version (build) — for example, iPhone15,3 17.4 (21E219). In older Xcode versions, the format was just 17.4 (21E219) without the device model prefix.

How big they get: 10-40 GB. Each iOS version creates a 2-5 GB folder. If you've been developing through several iOS releases, these pile up fast.

How to clean it:

Just delete the folders for old iOS versions you're no longer debugging against:

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*\ 16.*
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*\ 17.*

Keep the folders matching the iOS versions currently on your devices.

Is it safe? For old versions (2+ major versions behind your current iOS): completely safe. These are cached copies — Xcode will re-download them if you ever connect a device running that version again. For your current iOS version: keep it, or you'll trigger a re-download next time you plug in your device.

5. Module and Documentation Cache

What it is: Pre-built module indexes and documentation caches that Xcode creates for quick access to API docs and symbol lookup.

Where they live:

~/Library/Developer/Xcode/DocumentationCache/
~/Library/Developer/Shared/Documentation/

How big they get: 1-5 GB combined. Not the biggest offender, but easy to clean.

How to clean it:

rm -rf ~/Library/Developer/Xcode/DocumentationCache/*
rm -rf ~/Library/Developer/Shared/Documentation/*

Is it safe? Yes. These are fully auto-regenerated by Xcode when needed. No downsides.

6. Old Xcode Versions

What it is: If you've ever installed multiple Xcode versions side-by-side (common when testing against beta versions or maintaining legacy projects), the old versions may still be sitting in your Applications folder.

How to find them:

Check which Xcode is your active version:

xcode-select -p

This returns something like /Applications/Xcode.app/Contents/Developer — meaning Xcode.app is your active version.

Now check for other Xcode installations:

ls -la /Applications/Xcode*.app
ls -la ~/Applications/Xcode*.app

How big they get: 12-30 GB per version. Having Xcode 15 and Xcode 16 both installed wastes 25-35 GB.

How to clean it: Move the old versions to Trash. If you're sure you don't need them:

sudo rm -rf /Applications/Xcode-15.4.app

Is it safe? Only if you no longer need the old version. Some developers keep older Xcode versions for building against older SDKs or submitting to the App Store with specific toolchain requirements. Verify before deleting.

7. CocoaPods and SPM Caches

What they are: Cached downloads and build artifacts from dependency managers — CocoaPods and Swift Package Manager.

CocoaPods

~/Library/Caches/CocoaPods/          # Downloaded pod cache
~/.cocoapods/repos/                   # Spec repositories

Clean with:

rm -rf ~/Library/Caches/CocoaPods
rm -rf ~/.cocoapods/repos

Restore with pod install in your project. Specs restore with pod repo update.

Swift Package Manager

~/Library/Caches/org.swift.swiftpm/   # Package cache

Clean with:

rm -rf ~/Library/Caches/org.swift.swiftpm

Restore with swift package resolve in your project.

Project-level folders

Don't forget per-project Pods/ directories and .build/ folders in Swift packages. These can be large but are fully regenerated by their respective dependency managers.

Combined size: 1-10 GB depending on how many projects you work on.

Is it safe? Yes. Dependency manager caches are fully regenerated. The only cost is re-download time on your next pod install or swift package resolve.

What NOT to Delete

Not everything should be deleted at once. Here's what to keep:

Active project DerivedData. If you're in the middle of working on a project, deleting its DerivedData means a full rebuild — which can take 5-30 minutes on large projects. Clean stale projects, keep active ones.

SPM package cache on slow connections. The ~/Library/Caches/org.swift.swiftpm directory caches all downloaded packages. On a slow network, re-downloading everything takes time. If bandwidth isn't an issue, delete freely.

Current iOS Device Support. If you're actively debugging on a device running iOS 18.5, keep the 18.5 (...) folder. Deleting it means Xcode will need to re-download it the next time you connect your device.

Recent archives you haven't uploaded. If you archived a build for App Store distribution but haven't submitted it yet, you need that archive. Once it's uploaded to App Store Connect, the local copy is safe to delete.

The Automated Way

If hunting through all these paths manually every few months sounds tedious — it is. That's exactly why I built MegaCleaner.

MegaCleaner scans all 6 Xcode storage categories (DerivedData, simulators, archives, device support, docs, old versions) plus CocoaPods and SPM caches — and it doesn't stop at Xcode. It covers 29 tools total (21 developer tools + 8 system categories), including Docker, node_modules, Python environments, Rust/Cargo, Homebrew, and more.

How it works:

Scan is free — see exactly how much space each tool wastes
Confidence levels — every item is marked as "definitely safe" (like DerivedData), "probably safe" (like old archives), or "verify first" (like old Xcode versions)
One click — select what to clean, hit Clean, done. Everything goes to Trash (undoable)
$49 one-time — not a subscription

If you only care about Xcode cleanup, DevCleaner for Xcode is a solid free alternative. It covers similar Xcode categories but doesn't touch other dev tools.

Tool Comparison

Feature	MegaCleaner	DevCleaner	CleanMyMac
Price	$49 one-time	Free (tip jar)	$90/year
Xcode cleanup	6 sub-features	6 categories	Basic cache only
Other dev tools	20 more (Docker, npm, Python...)	None	None
Safety levels	3 confidence tiers	No	No
Open source	No	Yes (GPL-3)	No
Dev tool intelligence	Yes — 21 dev tool scanners	Xcode only	No dev awareness

Summary

Xcode can quietly consume 30-100+ GB of your disk without any visible sign. At a minimum, do this quarterly:

Delete DerivedData for stale projects — instant win, zero risk
Remove old simulator runtimes — usually the biggest savings
Clean Device Support for old iOS versions — easy 10-20 GB
Check for old Xcode versions in /Applications — 12-30 GB each

The manual cleanup takes 10-15 minutes if you follow this guide. Or scan with MegaCleaner and do it in under a minute.

Either way, your Mac will thank you.

Forem: Sergey Nikiforov

I Scanned My MacBook and Found 127GB of Developer Junk. Here's What It Was

The Scan Results

Xcode DerivedData + Simulators — 42GB

Docker Images and Build Cache — 31GB

node_modules Across 23 Projects — 18GB

Rust target/ Directories — 14GB

Python Conda Environments — 9GB

Homebrew Cache — 4GB

IDE Caches (VS Code, JetBrains) — 3GB

Browser Caches — 2GB

System Caches and Logs — 4GB

The Surprises

What I Cleaned vs. What I Kept

The Before and After

Why I Built MegaCleaner

Try It Yourself

Cargo Target Directories: Why Rust Projects Eat 10GB Each

Why Rust Builds Are So Large

Debug Info

Incremental Compilation

Dependency Compilation

Multiple Build Profiles and Targets

Where Exactly the Space Goes

Per-Project: target/debug/

Per-Project: target/release/

Global: ~/.cargo/registry/

Global: ~/.cargo/git/

Cleanup Commands

Per-Project: cargo clean

Registry Cache

Finding All Target Directories

cargo-sweep: Time-Based Cleanup

The Shared Target Directory Trick

The Automated Way

Quick Reference

Don't Let Conda Eat Your Hard Drive: Python Environment Cleanup for Mac

Quick Reference

Why Python Environments Get So Large

1. Conda Environments

2. Conda Package Cache

3. pip Cache

4. Virtual Environments (.venv, venv, env)

5. pyenv, Poetry, and uv

6. pycache and Tool Caches

What's Safe to Delete vs. What to Keep

Prevention: Keeping Python Lean

The Automated Way

Quick Reference Commands

Summary

node_modules is Why Your Mac is Full: Find and Delete All of Them

Why node_modules Gets So Absurdly Big

Flat Dependency Trees

Duplicate Packages Across Projects

Native Binaries and Platform-Specific Code

Build Output Hiding in Plain Sight

Finding All node_modules on Your Mac

The Nuclear Option: Delete Them All

Package Manager Caches: The Other Storage Hog

npm

Yarn (v1/Classic)

pnpm

Bun

Deno

Turborepo

The One-Liner to Check All of Them

Prevention Tips: Keeping node_modules Under Control

Use pnpm Instead of npm

Configure .npmrc for Smaller Installs

Clean Up Regularly

Don't Forget Build Artifacts

The Automated Way: Let MegaCleaner Handle It

Quick Reference: Commands Checklist

Homebrew, Gradle, and the Hidden Caches Eating Your Mac's Storage

1. Homebrew Cache

2. Gradle and Maven Caches

Gradle

Maven

3. Go Module and Build Caches

Module cache

Per-Project: `target/debug/`

Per-Project: `target/release/`

Global: `~/.cargo/registry/`

Global: `~/.cargo/git/`

Per-Project: `cargo clean`