Best Way to Clean Homebrew and Dev Caches on a 256GB MacBook (Without the Terminal)

A 256GB MacBook fills up faster than you expect when you develop software on it. Homebrew alone can accumulate several gigabytes of old package versions, download caches, and stale tarballs in a matter of months. Add CocoaPods, SwiftPM, Xcode derived data, npm, Gradle, and Docker layers, and it is easy to lose 20 to 40GB before you notice. Most cleanup guides hand you a list of terminal commands to memorize or paste. This guide covers what each cache location actually contains, which ones are safe to clear, and how to clean all of it without opening Terminal at all.

Why Dev Machines Run Out of Space So Fast

Package managers are optimized for speed and reproducibility, not disk frugality. They intentionally keep old versions around so you can roll back or switch projects without re-downloading everything. That is useful, until your storage indicator turns red.

Here is a quick map of the main offenders on a typical macOS developer machine running Sonoma or Sequoia (and Tahoe when you upgrade):

• Homebrew: cached downloads at $(brew --cache), typically ~/Library/Caches/Homebrew, plus old formula versions under /opt/homebrew/Cellar (Apple Silicon) or /usr/local/Cellar (Intel).
• CocoaPods: the pod cache lives at ~/Library/Caches/CocoaPods and can grow to several gigabytes on large iOS projects.
• Swift Package Manager: checkouts and build artifacts under ~/Library/Developer/Xcode/DerivedData and ~/.swiftpm.
• Xcode Derived Data: ~/Library/Developer/Xcode/DerivedData is one of the biggest single locations on any iOS or macOS developer machine, often 5 to 15GB per project.
• npm / Yarn / pnpm: caches at ~/.npm/_cacache, ~/.yarn/cache, and ~/.pnpm-store.
• Gradle / Maven: ~/.gradle/caches and ~/.m2/repository hold downloaded JARs indefinitely unless pruned.
• Docker: image layers, build cache, and stopped containers stack up at the Docker data root, usually ~/Library/Containers/com.docker.docker.

The Terminal Approach (for Reference)

If you do want to run it manually, here is what a full developer cleanup looks like. Keep this as a reference so you understand what any tool is doing on your behalf.

# Homebrew: remove old versions and clear download cache
brew cleanup --prune=all

# CocoaPods
pod cache clean --all

# Xcode Derived Data (this is always safe to delete)
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# npm
npm cache clean --force

# Yarn (v1)
yarn cache clean

# Gradle
rm -rf ~/.gradle/caches/

# Maven
rm -rf ~/.m2/repository/

The commands work, but you have to remember the right flags, run them separately for each tool, and trust that you are deleting the right directories. If you are already comfortable in Terminal, that is fine. If you would rather see what is being deleted before you confirm, a GUI approach is worth knowing about.

How to Clean Homebrew Without the Terminal

This is the core question most people arrive with: they know Homebrew is eating space, but they do not want to memorize brew cleanup --prune=all or figure out which formula versions are safe to remove.

The cleanest GUI workflow on macOS in 2026 goes like this:

1. Open a disk-map tool that reads your actual folder sizes. macOS does not show you folder sizes in Finder by default. You need something that scans and presents a ranked list. The free option built into macOS is Storage Management, reachable via Apple menu > System Settings > General > Storage. It gives you broad categories but does not drill into developer caches specifically.
2. Navigate to ~/Library/Caches in Finder. Press Cmd+Shift+G in any Finder window and paste ~/Library/Caches. Sort by size (View > Show View Options > check "Calculate all sizes"). Folders named Homebrew, CocoaPods, com.apple.dt.Xcode, and package managers will show their totals here.
3. Review before deleting. The key habit that separates safe cleanups from painful ones is reading what is inside a folder before you trash it. Homebrew's cache contains .tar.gz archives of packages you have installed. Deleting them forces a re-download if you reinstall, but causes no breakage. Derived Data is always safe to delete. The ~/.gradle/caches folder is also safe but will trigger a fresh dependency resolve on your next build.

Using a GUI App Instead

A dedicated developer disk cleanup Mac app changes the workflow significantly. Rather than hunting folder by folder, a good tool scans your whole drive, identifies known developer cache paths, and lets you review the findings before confirming anything.

Crumb is a native macOS menu-bar app that does exactly this. It runs entirely on your machine (no account needed), recognizes Homebrew caches, CocoaPods, SwiftPM, Xcode Derived Data, npm, Gradle, and other dev tool footprints, and shows you a reviewable plan before removing anything. There is also a built-in "is this safe to delete?" explanation for each category so you are not guessing. If you are juggling multiple projects on a 256GB machine, that reviewable step matters: you can see the size, understand what it is, and decide.

Clearing Dev Caches Category by Category

Homebrew

Homebrew stores downloaded package tarballs in ~/Library/Caches/Homebrew/downloads. It also keeps old formula versions in the Cellar until you explicitly prune them. brew cleanup removes versions older than 120 days by default. Adding --prune=all removes everything not currently linked. Neither operation touches installed binaries you are actively using.

CocoaPods

The CocoaPods download cache at ~/Library/Caches/CocoaPods can reach 3 to 8GB on machines that have worked on multiple iOS projects. Clearing it does not break any existing project. Your Podfile.lock still pins the right versions; CocoaPods will just re-download them on the next pod install.

Xcode Derived Data

Derived Data is the single safest thing to delete on a developer Mac. Xcode rebuilds it automatically. The path is ~/Library/Developer/Xcode/DerivedData. On an active project machine it commonly holds 10 to 20GB across multiple workspace entries. You can also clear it from inside Xcode: Xcode menu > Settings > Locations > Derived Data, then click the arrow to open in Finder and delete the contents.

Swift Package Manager

SwiftPM caches resolved package checkouts under ~/Library/Developer/Xcode/DerivedData (for Xcode-integrated packages) and in ~/.swiftpm/checkouts for command-line projects. Clearing these forces a fresh resolve but breaks nothing.

JavaScript Package Managers

npm's cache at ~/.npm/_cacache is safe to clear entirely. Yarn v1 uses ~/.yarn/cache; Yarn v2+ (Berry) uses a per-project cache defined in .yarnrc.yml. pnpm stores its content-addressable store at ~/.pnpm-store by default, though large monorepo setups sometimes point it elsewhere. All of these are re-populated on the next install run.

Gradle and Maven

Java/Kotlin projects are quiet offenders. Gradle's module cache at ~/.gradle/caches/modules-2 holds every JAR ever resolved. On an Android development machine this can be 5 to 10GB. Maven's local repository at ~/.m2/repository is the same pattern. Both are safe to clear; your build tool will re-fetch what it needs.

The 256GB MacBook Developer Workflow

If you are on a 256GB machine and writing software, a quarterly cleanup routine prevents the low-storage warning from ever appearing mid-deadline. The practical routine looks like this:

• After each major Homebrew upgrade cycle, run a cleanup pass on the Cellar and download cache.
• At the end of a project or before archiving a branch, delete that project's Derived Data entry.
• Once a quarter, do a full sweep of ~/Library/Caches and the hidden dot-folders (~/.npm, ~/.gradle, ~/.m2).
• Keep an eye on Docker: if you use it, run docker system prune or use Docker Desktop's "Clean / Purge data" option in its settings.

The goal is not to obsessively minimize disk usage but to make sure you are not carrying years of stale tarballs and unreferenced build artifacts from projects you shipped in 2023.

What to Do When You Are Already Out of Space

If macOS is already showing a storage warning, the fastest wins are Derived Data (often 10GB or more, zero risk) and Homebrew downloads (typically 2 to 5GB). Delete those two first. Then check ~/.gradle/caches and ~/.m2/repository if you do Java work. That combination usually recovers 15 to 25GB on a machine that has not been cleaned in over a year.

After the emergency clear, set a recurring reminder to run a cleanup every couple of months. Disk space problems on developer machines are almost always accumulation problems, not permanent ones.

If you want a visual picture of where your space went before you start deleting, Crumb's whole-disk map shows you exactly which folders are largest and flags known developer cache locations with an explanation of what each one contains. It is a faster starting point than navigating ~/Library folder by folder, especially when you are in a hurry.