Free Up Disk Space on a Developer Mac: Every Folder

To free up disk space on a developer Mac, start with the folders your toolchains rebuild on their own: Xcode DerivedData, old iOS DeviceSupport folders, unavailable simulators, and the package caches of Gradle, npm, pnpm, Yarn, pub, CocoaPods, Cargo and Go. Measure each one with du -sh first, then use the tool's own clean command where it has one. Everything in this list comes back on the next build or install, so the real cost of deleting it is a slower first build, not lost work.

This page is the map. Each section below says where a folder lives, whether it is safe to remove, and links to a dedicated guide with the full steps.

Measure before you delete anything

When a build fails with "No space left on device", the temptation is to delete whatever looks big. Spend two minutes measuring instead. These commands only read; they change nothing.

# Free space on the startup volume
df -h /

# The big developer folders in one pass
du -sh ~/Library/Developer/Xcode/DerivedData \
       ~/Library/Developer/Xcode/"iOS DeviceSupport" \
       ~/Library/Developer/CoreSimulator \
       ~/.gradle ~/.npm ~/.pub-cache ~/.cocoapods ~/.cargo ~/go 2>/dev/null

# Everything in your home folder, sorted by size
du -sh ~/* ~/.[!.]* 2>/dev/null | sort -h

Folders that do not exist on your Mac are simply skipped. Write down the numbers. They tell you where to spend your time, and they let you confirm afterwards that you actually got the space back.

If you prefer a picture, Apple's Storage pane (System Settings › General › Storage) gives a rough breakdown by category, and a disk map such as DaisyDisk, GrandPerspective or OmniDiskSweeper will show hidden dot-folders that Finder hides by default. All three are good tools for seeing where space went.

Xcode: the usual first stop

Apple's developer tools write into ~/Library/Developer, and several of its subfolders grow every time you build, connect a device or install a new Xcode.

DerivedData

~/Library/Developer/Xcode/DerivedData holds build products, indexes and module caches for every project you have opened. Xcode recreates it as needed, which makes it the safest large folder on the Mac to clear. Quit Xcode, then remove the contents. The guide on deleting Xcode DerivedData covers the Xcode settings shortcut, the Finder route and the one-line Terminal command, plus why Product › Clean Build Folder is not the same thing.

iOS DeviceSupport

Each time you connect an iPhone, iPad, Apple Watch or Apple TV running a new OS build, Xcode copies its debug symbols into a folder such as ~/Library/Developer/Xcode/iOS DeviceSupport/iPhone15,2 18.1 (22B83). Old OS versions you no longer test against are dead weight. Keep the folder for the version your device runs today. See how to delete old iOS DeviceSupport folders for the watchOS, tvOS and visionOS equivalents.

Simulators and runtimes

Simulator devices live in ~/Library/Developer/CoreSimulator/Devices, and every Xcode upgrade can leave behind devices whose runtime is gone. xcrun simctl delete unavailable removes those in one go. Runtimes themselves are separate downloads, managed in Xcode › Settings › Components or with xcrun simctl runtime list. The guide to deleting old Xcode simulators and runtimes walks through both, plus the CoreSimulator caches folder.

Archives: keep these

~/Library/Developer/Xcode/Archives looks like another cache, but it is not. Each archive holds the dSYM files you need to symbolicate crash reports from builds you shipped. Review them in Window › Organizer › Archives and delete only archives for versions nobody runs any more.

Android and the JVM: Gradle

Gradle keeps downloaded dependencies and transformed artifacts in ~/.gradle/caches, and a copy of every Gradle version your projects' wrappers have asked for in ~/.gradle/wrapper/dists. Both rebuild on demand. Stop running daemons first with ./gradlew --stop, and leave ~/.gradle/gradle.properties and ~/.gradle/init.d alone, because those are your settings, not cache. The full steps are in how to clear the Gradle cache on Mac.

Android emulators are a separate story. They live in ~/.android/avd and are best removed from Android Studio's Device Manager, so the IDE stays in sync.

JavaScript: two different problems

JavaScript projects use disk in two places, and it helps to keep them apart.

Per-project node_modules

Every project has its own node_modules, and old side projects keep theirs forever. Deleting node_modules in a project you are not using is harmless; npm install puts it back. The same goes for a dormant app's CocoaPods Pods folder, Dart's .dart_tool and Flutter's build/ folder: pod install, flutter pub get and the next build recreate them. The guide on finding and deleting old node_modules folders shows a find command that lists every one with its size, and covers the npkill tool.

Global package caches

npm, Yarn and pnpm also keep a global cache so the next install is faster: ~/.npm/_cacache, ~/Library/pnpm/store, and for Yarn either yarn cache dir (Yarn 1) or ~/.yarn/berry/cache (Yarn 2 and later). Each package manager has an official clean or prune command, and the guide to clearing npm, Yarn and pnpm caches lists them side by side, along with what to expect on the next install.

Flutter, CocoaPods, Rust and Go

These four ecosystems each keep a shared download cache in your home folder:

Tool	Folder	Own clean command
Dart and Flutter	`~/.pub-cache`	`flutter pub cache clean`
CocoaPods	`~/.cocoapods/repos`, `~/Library/Caches/CocoaPods`	`pod cache clean --all`
Cargo (Rust)	`~/.cargo/registry/cache`, `~/.cargo/registry/src`	none built in; remove the folders
Go	`~/go/pkg/mod`, `~/Library/Caches/go-build`	`go clean -modcache`, `go clean -cache`

Clearing these is a little less free than clearing DerivedData, because the next build has to download everything again, and an offline laptop on a train cannot do that. The guide to clearing Flutter pub, CocoaPods, Cargo and Go caches explains each command and the one quirk worth knowing: Go marks its module cache read-only, so plain rm -rf fails.

Things that are big but outside this list

A few large developer folders are best handled with their own tool's commands, which give you finer control than deleting folders:

Docker: docker system df shows usage; docker system prune removes stopped containers, unused networks, dangling images and unused build cache. Read its prompt before confirming, because it can remove things you want. Add --volumes only if you are sure, because volumes hold your data. More in Docker taking up space.
Homebrew: brew cleanup removes old versions in the Cellar and downloads it no longer needs; brew autoremove removes unused dependencies. See freeing up space from Homebrew.
Python: pip cache purge empties pip's cache, conda clean --all trims conda, and old virtual environments in finished projects can go. See cleaning up Python on Mac.
Ollama and other local model runners: ollama list shows models and ollama rm removes one.
JetBrains IDEs: caches live under ~/Library/Caches/JetBrains; the IDE's File › Invalidate Caches action is the gentler route.
AI apps and editors: Claude, VS Code, Cursor and Windsurf keep caches and logs in ~/Library/Application Support/<app> folders such as Cache, CachedData and logs. Quit the app before removing them, and leave conversation history like ~/.claude/projects alone.

How CleanLoupe does it

CleanLoupe – Mac Cleaner has a Developer group inside its Cleanup module that knows most of the folders above. It is free, with no subscription, trial or account. Files it removes go to the Trash and into its History list, where Put Back restores them until you empty the Trash; the two exceptions, simulators and Docker, are noted below.

What it covers, with the label it shows:

Xcode DerivedData, simulator caches, SwiftUI preview data, device logs and the documentation cache: Safe.
iOS, watchOS, tvOS and visionOS DeviceSupport: Safe, except that the newest folder for each device is offered but never preselected.
Unavailable simulators, removed through xcrun simctl the way Xcode does it: Safe.
Xcode Archives: Careful, never preselected, because they hold dSYMs.
Gradle caches and ~/.android/cache: Safe. Gradle wrapper distributions: Review.
npm, pnpm and Yarn Berry caches, including npx's ~/.npm/_npx: Safe.
Dependencies of old projects (node_modules, CocoaPods Pods, Dart .dart_tool, Flutter build/) in projects untouched for 90 days, on your home folder and other local disks: Review, or Careful when the project has no lockfile. Never preselected. The age is set in Settings, and Settings › Projects lets you choose which folders it searches.
pub cache, CocoaPods specs, Cargo registry cache and the Go module cache: Review.
Docker Desktop logs in ~/Library/Containers/com.docker.docker/Data/log: Safe. While the Docker daemon is running, "Unused images, stopped containers & build cache": Review. Cleaning it runs docker system prune --all --force and docker builder prune --all --force, which can't be put back. Volumes are never touched, and Docker's disk image is not edited directly.

Outside the Developer group, an AI tools group lists caches and logs of Claude, Codex, VS Code, Cursor and Windsurf (Safe), Claude's virtual machine image in ~/Library/Application Support/Claude/vm_bundles (Review; quit Claude first) and downloaded models from Ollama, LM Studio, Hugging Face, Whisper and PyTorch (Review; each tool's models folder goes as a whole, so use ollama rm to drop a single model). Command-line caches in ~/.cache are Safe, and Homebrew's download cache and JetBrains caches show up among App caches because they live in ~/Library/Caches.

Anything written in the last hour is never preselected, so a build that is running right now is left alone.

What it does not do: it does not remove simulator runtimes, Android emulators, Docker volumes, old Homebrew versions in the Cellar or Python virtual environments. Use the manual commands in the previous section for those. It also does not run each tool's clean command for you, apart from simctl for simulators; it moves the cache folders to the Trash, and the tools rebuild them.

A sensible order when the disk is full

Quit Xcode, Android Studio and any running dev servers, and run ./gradlew --stop in an Android project.
Clear DerivedData. It is usually the quickest win and costs only a slower next build.
Run xcrun simctl delete unavailable.
Remove DeviceSupport folders for OS versions you no longer use.
Delete node_modules, Pods and Flutter build folders in dormant projects.
Clean the package caches you rely on least.
Empty the Trash, then re-run df -h / to confirm.

FAQ

What is taking up so much space on my developer Mac?

On most developer Macs the biggest folders are under ~/Library/Developer (DerivedData, DeviceSupport, CoreSimulator) and in hidden dot-folders such as ~/.gradle, ~/.npm and ~/.cargo. Run the du -sh commands above to see your own numbers rather than guessing. Docker's disk image can also be large if you use it.

Is it safe to delete developer caches on a Mac?

Caches that a tool rebuilds, such as DerivedData, Gradle caches and npm's cache, are safe to delete; the cost is a slower next build and a fresh download. Be careful with Xcode Archives, simulator data you need for testing, and settings files like ~/.gradle/gradle.properties, which are not caches.

Why does Xcode take up so much space?

Xcode itself is a large app, and it also writes build products, indexes, device symbols and simulator data into ~/Library/Developer as you work. Those folders grow with every project and every OS version you test against. macOS does not clear them for you, which is why they are worth checking now and then.

Will deleting these folders break my projects?

No source code lives in any of the folders listed here. Your projects will rebuild, re-index and re-download what they need. Make sure you have network access before clearing package caches, and keep the current DeviceSupport folder for each device you debug on.

If you want a single list of these folders with sizes and labels, download CleanLoupe and open Cleanup's Developer group. The manual commands on this page work just as well if you would rather stay in Terminal.