Where developer junk hides on your Mac

By Irshad PC · Published July 17, 2026

Your Mac’s developer junk hides in a handful of predictable places: Xcode’s DerivedData, cached iOS debug symbols, npm and Gradle caches, and node_modules folders scattered across every project you ever cloned. On a machine that’s a year or two old, these quietly add up to tens of gigabytes. All of it is rebuildable, the tools recreate whatever they need on the next build or install, and you can clear every bit of it from Terminal for free.

Here’s the map, manual commands first. One real scan found 117.45 GB of junk on a single Mac, developer caches included, so the numbers get big fast.

The usual suspects

Clear Xcode caches and DerivedData

DerivedData

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

Build intermediates and indexes. Safe because Xcode rebuilds all of it the next time you build. The only cost is one slow build per project.

iOS DeviceSupport

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport

Debug symbols cached for every iPhone and iPad you’ve ever plugged in, including devices you no longer own. Safe because Xcode re-extracts symbols the next time you connect a device.

Simulator runtimes and dead simulators

xcrun simctl runtime list
xcrun simctl runtime delete <ID>
xcrun simctl delete unavailable

Each runtime is a multi-gigabyte disk image. Safe to remove the OS versions you no longer target because Xcode offers to download a runtime again when a project needs it. The last command removes simulator devices whose runtime is already gone, which are pure dead weight.

Xcode’s own cache at ~/Library/Caches/com.apple.dt.Xcode is also fair game. One folder to leave alone unless you’re sure: ~/Library/Developer/Xcode/Archives holds your past release builds, and it’s what lets you symbolicate old crash logs.

Clear JavaScript package caches and node_modules

npm cache clean --force
pnpm store prune
yarn cache clean

All three are download caches. Safe because the package manager re-fetches anything a future install needs.

The bigger wins are the node_modules folders themselves. Find them:

find ~/Projects -name node_modules -type d -prune -exec du -sh {} +

Swap ~/Projects for wherever your code lives, then delete the ones from projects you’re not actively working on. Safe because one install rebuilds the folder exactly from the lockfile.

Clear Gradle and Maven caches

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

Downloaded dependencies and wrapper distributions. Safe because the next build re-fetches what it uses. Your gradle.properties and init scripts are separate files and stay put. Maven keeps its equivalent in ~/.m2/repository, same deal.

Clear the Homebrew download cache

brew cleanup --prune=all

Clears the download cache at ~/Library/Caches/Homebrew, which keeps old bottles around long after upgrades. Safe because brew re-downloads anything it actually needs.

Clear Dart and Flutter caches

dart pub cache clean

Empties ~/.pub-cache. Safe because pub get re-fetches packages per project. Inside a project, flutter clean removes the build and .dart_tool folders, which the next run recreates.

Rust, Swift and other build output

cargo clean

Removes a Rust project’s target folder, which the next build recreates. SwiftPM’s .build, Next.js’s .next and their cousins can simply be deleted for the same reason. Globally, Cargo’s registry cache under ~/.cargo/registry re-fetches on the next build too, and your installed tools in ~/.cargo/bin and credentials live elsewhere.

Be more careful with folders literally named build or target. The name alone doesn’t prove they’re build output, so check they sit next to a package.json, Cargo.toml or similar before deleting.

Quick hits

• pip: rm -rf ~/Library/Caches/pip. Wheels re-download on the next install.
• Go: go clean -cache. The build cache regenerates on the next build.
• CocoaPods: rm -rf ~/Library/Caches/CocoaPods. pod install re-downloads.
• Playwright: rm -rf ~/Library/Caches/ms-playwright. playwright install brings the browsers back.
• Swift Package Manager: rm -rf ~/Library/Caches/org.swift.swiftpm. Re-cloned on the next resolve.

Docker, OrbStack, Colima: not junk, handle differently

Docker Desktop’s VM disk lives at ~/Library/Containers/com.docker.docker/Data/vms, and it grows into tens of gigabytes without ever shrinking on its own. It is not junk. Every image, container and volume you have lives inside that one file, so deleting it wipes them all. Reclaim space from inside the tool instead:

docker system prune
podman system prune -a

The same logic applies to OrbStack, Colima and Lima, whose disks sit in ~/.orbstack, ~/.colima and ~/.lima.

If you’d rather not babysit rm -rf

Everything above works, costs nothing, and is genuinely the way to go if you’re happy in a terminal. The catch is remembering a dozen paths and re-running them every few months.

Dev Mode in SpaceUp Mac scans these caches and artifacts in one pass and shows each with a plain note on what rebuilds it and when. node_modules and build folders appear as one line per project, so you approve each project separately, and folders with generic names like build or target stay unticked until you confirm them. Nothing is cleared until you approve it on the review screen.

It also knows what to leave alone. The scanner never touches source code, git history, credentials or signing keys, and things like your Hugging Face token and Cargo login sit outside the paths it clears. Docker and VM disks appear in Deep Scan as information only, with the same copy-paste reclaim commands as above and no delete button. Simulator runtime removal lives in the Advisor tab of the direct download, which runs Apple’s own simctl and says it’s permanent before you approve. Local AI models are listed with sizes and never deleted, a topic big enough for its own page: see AI app storage on Mac.

That 117.45 GB figure earlier came from one real scan, and developer caches were part of the pile. The first scan and first clean are free, so you can check your own number before paying anything. How the app decides what’s safe is covered in the Dev Mode docs, and if the rest of your disk is the problem, start with freeing up disk space on Mac.