Best/top listicles (2026)

8 Best Mac Cleaner Apps for Developers in 2026 (DerivedData, node_modules, Docker)

Developer machines age fast. A freshly formatted Mac can bloat to 200 GB of cruft within a year — Xcode simulators, abandoned node_modules trees, Docker image layers, Rust build artifacts, and Maven repositories stack up silently while you ship features. Finding the best mac cleaner for developers means finding a tool that understands where developer junk actually hides, not one that only clears browser caches and trashes duplicate photos. This guide covers eight tools worth evaluating in 2026, plus a practical map of the folders that eat the most space on a developer Mac running macOS Sequoia or Tahoe on Apple Silicon or Intel.

Where Developer Disk Space Actually Goes

Before reaching for any cleaner, it helps to know the real culprits. The table below summarizes the most common developer cache locations, their typical sizes, and whether it is safe to delete them cold (without running a build first).

Folder Typical Size Safe to Delete? What Rebuilds It
~/Library/Developer/Xcode/DerivedData 10–80 GB Yes — next build recreates it Xcode build
~/Library/Developer/Xcode/iOS DeviceSupport 5–40 GB Yes — re-downloads when device connects Xcode + connected device
node_modules (project-level) 200 MB–2 GB per project Yes — npm install restores npm install / yarn / pnpm
~/.npm/_cacache 1–10 GB Yes — npm re-downloads on demand npm install
~/.cargo/registry + ~/.cargo/git 2–20 GB Yes — Cargo re-fetches crates cargo build
~/.m2/repository 2–15 GB Mostly yes — Maven re-downloads Maven / Gradle build
~/.gradle/caches 1–10 GB Yes — Gradle re-populates Gradle build
Docker images (~/Library/Containers/com.docker.docker) 5–100 GB Selectively — prune unused images only docker pull
~/Library/Caches/pip 500 MB–5 GB Yes — pip re-downloads packages pip install
Simulator runtimes (~/Library/Developer/CoreSimulator/Cryptex) 3–12 GB per runtime Yes if simulator unused — re-download from Xcode Xcode Platforms prefs

If you want a deeper breakdown of what System Data and other mystery categories actually contain, see what is System Data on Mac storage.

The 8 Best Mac Cleaners for Developers in 2026

1. Crumb

Crumb was designed with the kind of folder map shown above in mind. It scans developer-specific paths — DerivedData, Xcode device support, npm and pip caches, Cargo registries, Gradle and Maven repos — and presents each category with a size estimate and a plain-English description of what rebuilds it. A tool like Crumb can audit all of these at once and show what is safe before you delete, which matters on a machine where accidentally removing a Gradle cache mid-CI-run is a real cost. It runs natively on Apple Silicon and Intel under macOS Sequoia and Tahoe.

2. CleanMyMac X

CleanMyMac X (by MacPaw) is the longest-running mainstream option. Its Space Lens feature gives a visual treemap of disk usage, and its developer module surfaces ~/Library/Developer/Xcode/DerivedData and simulator runtimes. It misses some language-specific caches (Cargo, pip virtual environments) but covers the Xcode surface area well. Monthly subscription required.

3. DaisyDisk

DaisyDisk is a visualizer first, cleaner second. Its sunburst map is excellent for identifying which project directory has ballooned, and you can drag segments to a delete queue. It does not have developer-specific intelligence — you must know that ~/.m2/repository is safe to nuke — but for experienced developers who just want a fast map, it is hard to beat. One-time purchase, Universal binary.

4. Disk Diag

Disk Diag (from Round Robin Software) is a lightweight free option on the Mac App Store. It categorizes disk usage into broad buckets and surfaces large files. Developer caches are not called out by name, but the file-size view is fast and useful for spotting a 20 GB DerivedData folder quickly.

5. GrandPerspective

GrandPerspective is a free, open-source treemap visualizer that has been around since the PowerPC era. In 2026 it runs on Apple Silicon via Rosette or a community-maintained native fork. It has no cleaner intelligence at all — just raw file-size visualization — but it is fast, free, and trusted. Good for a second opinion after running another tool.

6. Brew (with brew cleanup)

Homebrew is not a cleaner, but running brew cleanup regularly removes outdated formula versions and their downloads from ~/Library/Caches/Homebrew. On an active developer Mac, this alone can free 2–5 GB. Pair it with brew autoremove to drop unused dependencies. Add both to a weekly cron or a shell alias.

7. docker system prune

Docker Desktop stores its virtual machine disk image inside ~/Library/Containers/com.docker.docker/Data/vms/ and can silently grow past 100 GB. Running docker system prune -a --volumes removes all stopped containers, dangling images, unused networks, and build cache. Use docker image ls first to confirm which images you still need. This is the single highest-yield command for developers who run local containers.

8. npkill

npkill is a focused CLI tool that recursively finds node_modules directories across your entire filesystem and lets you delete them interactively. Install it with npm install -g npkill and run npkill from any root directory. On a Mac with several years of JavaScript projects, this commonly surfaces 20–60 GB of stale dependencies. For more strategies, see how to clean up node_modules on Mac.

How to Clean Xcode DerivedData Step by Step

DerivedData is consistently the biggest single target on iOS and macOS developer machines. Here is the safest manual process:

  1. Quit Xcode completely before deleting anything.
  2. Open Terminal and run: du -sh ~/Library/Developer/Xcode/DerivedData to confirm the current size.
  3. Delete the entire folder: rm -rf ~/Library/Developer/Xcode/DerivedData
  4. Optionally also clear iOS DeviceSupport for OS versions you no longer test: ls ~/Library/Developer/Xcode/iOS\ DeviceSupport/ — delete subfolders for obsolete iOS versions.
  5. Reopen your project in Xcode. The first build will be a full clean build; subsequent builds index incrementally as usual.

You will not lose any source code, project settings, or signing certificates. DerivedData contains only compiled intermediates and index data that Xcode recreates automatically.

Cleaning Rust, Python, and JVM Caches

Language toolchains each have their own cache locations and clearing commands:

  • Rust / Cargo: Remove old build artifacts with cargo clean inside each project, or purge the global registry with rm -rf ~/.cargo/registry/cache. The cargo-cache crate (cargo install cargo-cache) gives a breakdown before you commit.
  • Python / pip: Clear the pip download cache with pip cache purge. Virtual environments stored inside project folders (typically .venv/ or env/) are safe to delete and recreate with python3 -m venv .venv.
  • Java / Maven: Run mvn dependency:purge-local-repository to remove unused snapshots, or manually prune ~/.m2/repository by deleting subdirectories for libraries you no longer use.
  • Java / Gradle: Run gradle --stop to stop the daemon, then delete ~/.gradle/caches. Gradle rebuilds on the next invocation.
  • Ruby / Bundler: Run gem cleanup to remove old gem versions, and bundle clean --force inside projects to drop gems no longer in Gemfile.lock.

Apple Silicon vs Intel: Does It Change Anything?

On Apple Silicon (M1 through M4), the compiler cache inside DerivedData tends to grow more slowly because the toolchain is more efficient, but the folder structure is identical. Rosetta 2 adds a translation cache at /Library/Apple/usr/libexec/oah/ — this is managed by the OS and should not be manually deleted. Docker on Apple Silicon uses a different hypervisor path but the same docker system prune command works on both architectures. Path names for npm, Cargo, pip, and Maven are the same on both chip families.

How Often Should Developers Clean?

There is no universal schedule, but a practical rule of thumb is:

  • Run brew cleanup and npm cache clean --force monthly.
  • Clear DerivedData whenever you switch Xcode major versions or hit mysterious build errors.
  • Run docker system prune after wrapping up any project that ran containers locally.
  • Do a full audit with a disk scanner quarterly — developer machines can accumulate 50–100 GB of stale artifacts per year without any single obvious culprit.

Reclaim your disk in one click

Crumb audits your whole Mac, tells you what's safe to delete, and frees the space in seconds — private, local, and Apple-notarized.

Download Crumb for macOS

Frequently asked questions

Is it safe to delete the entire DerivedData folder?
Yes. DerivedData contains only compiled intermediates and the Xcode source index — no source code or configuration. Xcode recreates it automatically on the next build. The only downside is that your first build after deletion will be a full clean build, which takes longer than an incremental one.
Will deleting node_modules break my projects?
No, as long as you have a package.json (and ideally a package-lock.json or yarn.lock). Run npm install or yarn inside the project directory to restore all dependencies from the lock file at the exact versions you were using.
How much space can a developer Mac realistically recover?
On a Mac used for active iOS, JavaScript, and Docker work for two or more years, it is common to recover 50–150 GB. DerivedData and Docker images are usually the biggest targets, followed by stale node_modules trees scattered across old project folders.
Can I safely delete the ~/.cargo/registry folder?
Yes. The registry folder is a local cache of crate source tarballs and index data downloaded from crates.io. Cargo re-downloads whatever it needs the next time you run cargo build. You can also use cargo cache -a to prune only old versions while keeping the current ones.
Does cleaning caches affect my running applications or active builds?
Cleaning caches while a build is in progress can corrupt that build. Always stop active builds and quit Xcode, Docker, or your build tool before clearing its cache folders. Applications that are already compiled and running are not affected — they use their installed binaries, not the build caches.