Developer caches on macOS you can safely delete

Every developer cache on a Mac in one table: exact paths, typical sizes, whether it's safe, whether it comes back, and the official clean command.

Short answer

On a developer's Mac, most reclaimable space sits in a handful of rebuildable folders: Xcode DerivedData and simulator runtimes, Docker's disk image, node_modules, and package manager caches for npm, pnpm, Homebrew, Gradle, Cargo, Go and pip. All of the caches below are safe to clear in the sense that the tool rebuilds or re-downloads them, but use each tool's official clean command where one exists. Never delete the parent folders (~/.gradle, ~/.m2, ~/.cargo, ~/Library/Developer) wholesale, because they also hold settings, credentials and installed tools.

How to read this reference

Each table row is one cache, with:

  • Path: the default location on macOS. If you've changed it with an environment variable or setting, the tool's "show path" command tells you where yours is.
  • Typical size: a rough range to tell you whether it's worth looking at. These are estimates, not measurements; yours may be far smaller or larger. Measure with du -sh <path>.
  • Safe?: Safe means the tool can rebuild or re-download it with no loss. Check first means it's rebuildable but costs something real (a large download, a project setup step) or you might still be using it. Your files means it can hold data you can't get back.
  • Comes back?: whether it refills on its own as you work.
  • Clean with: the official command where one exists. Where none exists, moving the folder to the Trash with the tool closed is the safe fallback.

Rows marked (not documented) are paths I could confirm on a real Mac or from community sources but not in the tool's own documentation. Treat them with a little more care.

To measure everything in one go:

Terminal
$ du -sh ~/Library/Developer/Xcode/DerivedData ~/Library/Caches/* ~/.npm ~/.gradle/caches \
$   ~/.m2/repository ~/.cargo/registry ~/go/pkg/mod ~/.cache/* 2>/dev/null | sort -hr | head -25

Apple: Xcode, simulators, Swift and iOS dependencies

CachePathTypical sizeSafe?Comes back?Clean with
Xcode DerivedData~/Library/Developer/Xcode/DerivedData1–30 GBSafeYes, on next buildQuit Xcode, move to Trash; or Product > Clean Build Folder per project
Unavailable simulator devices~/Library/Developer/CoreSimulator/Devices0.1–3 GBSafeNoxcrun simctl delete unavailable
Simulator runtimessystem-managed disk images (outside your home folder)several GB eachCheck firstOnly if downloaded againxcrun simctl runtime delete <id>, or Xcode > Settings > Components
iOS / watchOS / tvOS DeviceSupport~/Library/Developer/Xcode/iOS DeviceSupport (and watchOS, tvOS variants)2–5 GB per OS versionSafe for versions you don't debugYes, when that device is connectedMove old version folders to Trash
Xcode Archives~/Library/Developer/Xcode/Archives0.1–2 GB per archiveYour filesNoWindow > Organizer > Archives
SwiftUI Previews~/Library/Developer/Xcode/UserData/Previews0.5–10 GBSafeYesMove to Trash with Xcode closed (not documented)
CoreSimulator caches~/Library/Developer/CoreSimulator/Caches0.5–5 GBSafeYesMove to Trash with Simulator closed (not documented)
Swift Package Manager~/Library/Caches/org.swift.swiftpm0.1–5 GBSafeYesswift package purge-cache, or File > Packages > Reset Package Caches in Xcode (path not documented)
SwiftPM build folders.build inside each package0.1–5 GB eachSafeYesswift package clean or swift package reset in the package
CocoaPods download cache~/Library/Caches/CocoaPods0.1–5 GBSafeYespod cache clean --all
CocoaPods project podsPods/ inside each project0.1–2 GB eachCheck firstYes, with pod installMove to Trash; only if Podfile.lock exists and Pods/ isn't committed
Carthage~/Library/Caches/org.carthage.CarthageKit0.1–5 GBSafeYesMove to Trash (not documented)

Details and commands: How to clear Xcode DerivedData and old simulators.

Check first

Simulator runtimes and Archives are the two Apple items that don't come back by themselves. A runtime is a multi-gigabyte download; an archive holds the debug symbols you need to read crash reports for that release.

pod cache clean refuses to clear everything without --all, by design. swift package purge-cache is listed in swift package --help as "Purge the global repository cache".

Shedi checks the big ones for you in about 10 secondsXcode, Docker, node_modules and the npm, pnpm, Yarn, Homebrew, CocoaPods, SwiftPM, Cargo, Gradle, pip and Go caches, each explained. Docker and Homebrew are cleaned with their own commands.
Get Shedi

Homebrew

CachePathTypical sizeSafe?Comes back?Clean with
Downloads cache~/Library/Caches/Homebrew (check with brew --cache)0.1–5 GBSafeYesbrew cleanup
Old installed versionsin the Homebrew prefix (/opt/homebrew on Apple silicon, /usr/local on Intel)0.1–5 GBSafeNo, unless you reinstall thembrew cleanup
Terminal
$ brew cleanup -n          # dry run: show what would be removed
$ brew cleanup             # remove old versions and downloads older than 120 days
$ brew cleanup --prune=all # remove all cached downloads, regardless of age

Homebrew already runs brew cleanup for the packages you install or upgrade, and for everything every 30 days, unless HOMEBREW_NO_INSTALL_CLEANUP is set. brew cleanup -s also scrubs downloads for the latest versions, but never the downloads of installed formulae or casks.

JavaScript: npm, pnpm, Yarn, Bun

CachePathTypical sizeSafe?Comes back?Clean with
npm cache~/.npm/_cacache0.5–5 GBSafeYesnpm cache verify (garbage-collects), npm cache clean --force
npx packages~/.npm/_npx0.1–3 GBSafeYes, next time you npxnpm cache npx rm (npm 11)
pnpm store~/Library/pnpm/store (check with pnpm store path)1–20 GBSafeYespnpm store prune
Yarn 1 cacheshown by yarn cache dir0.5–5 GBSafeYesyarn cache clean
Yarn 2+ global cache~/.yarn/berry/cache0.5–5 GBSafeYesyarn cache clean --mirror
Bun cache~/.bun/install/cache0.2–3 GBSafeYesbun pm cache rm (run inside a project)
node_modulesinside each project0.1–1 GB eachCheck firstYes, with your install commandMove to Trash

Details, including why deleting node_modules in a pnpm project frees less than du says: Delete node_modules safely.

Python: pip, Poetry, uv

CachePathTypical sizeSafe?Comes back?Clean with
pip cache~/Library/Caches/pip (check with pip cache dir)0.1–5 GBSafeYespip cache purge
Poetry cache~/Library/Caches/pypoetry0.1–5 GBSafeYespoetry cache clear --all (older versions: poetry cache clear PyPI --all)
Poetry virtualenvs~/Library/Caches/pypoetry/virtualenvs0.1–2 GB eachCheck firstYes, with poetry installpoetry env remove <python> in the project
uv cache~/.cache/uv (check with uv cache dir)0.5–20 GBSafeYesuv cache prune (unused entries) or uv cache clean (everything)
Project .venv foldersinside each project0.1–2 GB eachCheck firstYes, with your install commandMove to Trash

Notes:

  • uv on macOS uses ~/.cache/uv, not ~/Library/Caches. Its docs call uv cache prune "safe to run periodically"; uv cache clean empties the cache entirely. uv cache size shows how big it is.
  • Poetry's virtualenvs live inside its cache folder by default, so clearing the whole Poetry folder by hand also removes every project's environment. Prefer poetry cache clear, which only touches cached packages.

Rust: Cargo

CachePathTypical sizeSafe?Comes back?Clean with
Registry downloads~/.cargo/registry/cache0.1–3 GBSafeYesMove to Trash (no official command)
Extracted crate sources~/.cargo/registry/src0.5–5 GBSafeYesMove to Trash (no official command)
Git dependencies~/.cargo/git/db, ~/.cargo/git/checkouts0.1–3 GBSafeYesMove to Trash (no official command)
Project build outputtarget/ inside each project1–20 GB eachSafeYes, on next buildcargo clean in the project

The Cargo Book says that "in theory, you can always remove any part of the cache and Cargo will do its best to restore sources", by re-extracting or re-downloading them. Leave ~/.cargo/bin alone: that's where cargo install puts your tools, and on many setups the Rust toolchain itself is reached through it.

Per-project target/ folders are often bigger than the global cache; they're Rust's equivalent of node_modules and DerivedData combined, so check them first.

Go

CachePathTypical sizeSafe?Comes back?Clean with
Build cache~/Library/Caches/go-build (check with go env GOCACHE)0.5–10 GBSafeYesgo clean -cache
Module cache~/go/pkg/mod (check with go env GOMODCACHE)0.5–10 GBSafeYesgo clean -modcache
Test and fuzz cachesinside the build cachesmallSafeYesgo clean -testcache, go clean -fuzzcache

Go's docs describe the build cache's default as "a subdirectory named go-build in the standard user cache directory", which on macOS is ~/Library/Caches. Use go clean -modcache rather than rm -rf or the Trash: Go makes module cache directories read-only by default, so a plain delete fails part-way.

Java and Kotlin: Gradle and Maven

CachePathTypical sizeSafe?Comes back?Clean with
Gradle caches~/.gradle/caches1–20 GBSafeYesLet Gradle's automatic cleanup run, or stop daemons and move to Trash
Gradle wrapper distributions~/.gradle/wrapper/dists0.1–3 GBSafeYes, when a project needs that versionGradle cleans unused ones after 30 days; or move old versions to Trash
Gradle daemon logs~/.gradle/daemonsmall to 1 GBSafeYesCleaned after 14 days automatically
Maven local repository~/.m2/repository0.5–10 GBSafeYesmvn dependency:purge-local-repository per project, or move the repository folder to Trash

Gradle's documentation lists automatic cleanup periods: released wrapper distributions 30 days, snapshot distributions 7 days, downloaded resources 30 days, created resources 7 days, build cache entries 7 days, daemon logs 14 days. Cleanup "runs in the background when the Gradle daemon is stopped or shut down". If you delete ~/.gradle/caches by hand, stop the daemons first:

Terminal
$ ./gradlew --stop      # or: gradle --stop
$ mv ~/.gradle/caches ~/.Trash/gradle-caches
Check first

Don't trash ~/.gradle or ~/.m2 as a whole. ~/.gradle/gradle.properties and ~/.m2/settings.xml often hold repository credentials and signing settings that aren't stored anywhere else.

Android

CachePathTypical sizeSafe?Comes back?Clean with
Emulator system images~/Library/Android/sdk/system-images1–4 GB eachCheck firstOnly if downloaded againsdkmanager --uninstall "<package>", or Android Studio's SDK Manager
Emulator devices (AVDs)~/.android/avd/<name>.avd1–10 GB eachYour filesNoavdmanager delete avd -n <name>, or Android Studio's Device Manager
Old SDK platforms and build-tools~/Library/Android/sdk/platforms, build-tools0.1–1 GB eachCheck firstOnly if downloaded againsdkmanager --uninstall "<package>"
Gradle cachessee Gradle above

~/Library/Android/sdk is Android Studio's default SDK location on macOS; Android Studio's SDK Manager shows where yours is. An AVD holds the emulator's data, including apps and anything you set up inside it, so treat it as yours.

Editors and IDEs

CachePathTypical sizeSafe?Comes back?Clean with
JetBrains caches~/Library/Caches/JetBrains/<product><version>0.5–10 GB per IDE versionSafeYes, after re-indexingFile > Invalidate Caches in the IDE; Help > Delete Leftover IDE Directories for old versions
JetBrains logs~/Library/Logs/JetBrains/<product><version>smallSafeYesMove to Trash
VS Code caches~/Library/Application Support/Code/Cache, CachedData, Code Cache, GPUCache0.1–1 GBSafeYesQuit VS Code, move to Trash (not documented)
VS Code extension downloads~/Library/Application Support/Code/CachedExtensionVSIXs0.1–1 GBSafeYesQuit VS Code, move to Trash (not documented)
Cursor cachessame folder names under ~/Library/Application Support/Cursor0.1–1 GBSafeYesQuit Cursor, move to Trash (not documented)

JetBrains documents that installing a new major version of an IDE "automatically deletes the caches and logs directories for older versions of the IDE that have not been updated in the last 180 days", while the configuration and plugins directories "will remain forever, unless you remove them manually".

Check first

For VS Code and Cursor, clear only the cache folders named above. The same parent folder holds User (your settings, keybindings and snippets), Backups (unsaved files) and workspace storage. Your installed extensions are in ~/.vscode/extensions and ~/.cursor/extensions; those aren't a cache.

Containers and browsers for testing

CachePathTypical sizeSafe?Comes back?Clean with
Docker images, containers, build cacheinside ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw5–60 GBCheck firstYes, when pulled or rebuiltdocker system df, then docker image prune -a, docker container prune, docker builder prune
Docker volumesinside the same disk imagevariesYour filesNodocker volume rm <name> after checking
Playwright browsers~/Library/Caches/ms-playwright0.5–2 GBSafeYes, with npx playwright installnpx playwright uninstall --all
Puppeteer browsers~/.cache/puppeteer0.2–2 GBSafeYes, on next installnpx @puppeteer/browsers clear
Electron downloads~/Library/Caches/electron0.1–1 GBSafeYesMove to Trash
electron-builder downloads~/Library/Caches/electron-builder0.1–1 GBSafeYesMove to Trash (not documented)

Docker details: Reclaim disk space from Docker on a Mac. Playwright's docs show each browser taking "a few hundred megabytes", and Playwright already removes browser versions no installed Playwright needs any more. npx playwright uninstall removes the browsers of the current installation; --all removes those of every installation.

What not to delete

  • Parent folders. ~/Library/Developer, ~/.gradle, ~/.m2, ~/.cargo, ~/.android, ~/Library/Application Support/Code. Each mixes caches with settings, credentials, tools or your data.
  • Docker's Docker.raw from Finder: it holds volumes too.
  • Anything in /System or /Library to chase a cache. None of the caches above require it, and the ones that live there (like simulator runtimes) have their own commands.
  • Caches of a running tool. Quit the IDE, stop the Gradle daemon, stop Docker builds first.

For the non-developer side of a full disk (Photos, iOS backups, Downloads, System Data), see How to free up space on a Mac without losing anything.

A five-minute routine

Terminal
# Apple
$ mv ~/Library/Developer/Xcode/DerivedData ~/.Trash/
$ xcrun simctl delete unavailable

# Package managers
$ brew cleanup
$ npm cache verify
$ pnpm store prune
$ go clean -cache
$ pip cache purge

# Docker
$ docker system df
$ docker builder prune

Run what applies to you, then measure again. I built Shedi because I was running some version of this list by hand every few weeks; it does the same with an explanation per item and everything that can go to the Trash going there first. If you'd rather keep doing it yourself, this page will stay updated.

Sources

Questions

Which developer caches are safe to delete on a Mac?

Download caches for package managers (npm, pnpm, Yarn, Bun, Homebrew, CocoaPods, SwiftPM, Cargo, Go, Gradle, Maven, pip, Poetry, uv) and build outputs such as Xcode DerivedData are safe: the tool downloads or rebuilds them when needed. Prefer each tool's own clean command, because it knows what's in use.

What's the safest way to clear a developer cache?

Use the tool's own command (for example brew cleanup, go clean -modcache or pnpm store prune) or move the folder to the Trash with the tool closed. Avoid deleting whole parent folders like ~/.gradle, ~/.m2 or ~/.cargo, which also hold settings, credentials or installed binaries.

Will clearing developer caches slow me down?

Only once. The next install or build re-downloads or rebuilds what it needs, which costs time and bandwidth, and after that everything is as fast as before.

Do these caches come back after I delete them?

Yes, nearly all of them refill as you keep working, so clearing them is maintenance rather than a permanent fix. The exceptions are things like simulator runtimes, Android system images and old IDE versions' folders, which only come back if you download them again.

Why use the tool's command instead of rm -rf?

Some caches have rules a plain delete ignores: Go's module cache is read-only, so rm fails part-way; pnpm's store is shared by hard links; Homebrew keeps downloads for installed versions. The official commands handle those cases and are what the tool's authors test.