Developer Caches on Mac: What's Safe to Clear

Written for macOS 27 Golden Gate and macOS 26 Tahoe.

If you write code on a Mac, the biggest chunk of reclaimable space usually isn't in Downloads. It's spread across a dozen tool caches you never look at: Xcode build products, simulator runtimes, package stores, container layers and, more and more often, local AI models. Each tool keeps them for a good reason, and most can rebuild them. Some are expensive to get back, though. This guide shows where each one lives, how to measure it and how to clear it with the tool's own command first.

#Key takeaways

• Measure before you delete. A two-minute size check tells you which one or two caches actually matter.
• Use the tool's own cleanup command where one exists. It knows what's still in use.
• Cheap to rebuild: Xcode DerivedData, device support files, Homebrew downloads.
• Costs a re-download: npm, pnpm, Yarn, pip, uv, CocoaPods, Gradle.
• Expensive or irreplaceable: Maven repositories, Docker volumes, Xcode archives, local AI models.

#How big are your developer caches?

Start by measuring. These commands only read sizes and paths; they change nothing. Run the ones for tools you have installed:

du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/"iOS DeviceSupport"
xcrun simctl runtime list
npm config get cache
pnpm store path
brew --cache
pip3 cache dir
uv cache size

On the Mac used to test this guide (macOS 26.5, Xcode 26.4.1), the results were 4.4 GB of DerivedData, 5.5 GB of iOS device support files, 12.3 GB of simulator runtimes, 2.8 GB of npm cache, 1.9 GB in the pnpm store and 1.8 GB of uv cache. That's about 28 GB, and none of it was project data.

#Where does each tool keep its cache?

The paths below are macOS defaults. Environment variables or config files can move them, so trust the tool's own "where is my cache" command over this table.

#Is it safe to delete Xcode DerivedData?

Yes. DerivedData holds build products and indexes, and Xcode recreates them on the next build. The cost is a slower first build and some re-indexing. Quit Xcode, then move the folder's contents to the Trash. For a single project, Product › Clean Build Folder in Xcode clears just that project's build output.

Two neighbours need more thought:

• iOS DeviceSupport holds debug symbols copied from iPhones and iPads you've connected. These are not device backups. Xcode copies them again when you reconnect a device, so folders for OS versions you no longer test on are safe to remove.
• Archives (~/Library/Developer/Xcode/Archives) are your shipped builds and their debug symbols. Keep the ones you might need for crash reports, and delete old ones from Xcode's Organizer, not Finder.

#How do you clean up old simulators?

Simulator devices and simulator runtimes are separate things.

1. Remove devices for runtimes you no longer have. This command (not run while testing this guide) deletes only devices the current Xcode can't use:

   xcrun simctl delete unavailable
   

2. Remove old runtimes. In Xcode, open Settings › Components (called Platforms in some older versions), select a runtime you don't need and delete it. From Terminal, xcrun simctl runtime list shows each runtime's identifier, and xcrun simctl runtime delete <identifier> removes one. Add --dry-run to preview.

Don't delete runtime files from Finder. They're mounted disk images that Xcode manages.

#How do you clear npm, pnpm and Yarn caches?

• npm: npm cache clean --force. The --force flag is required. npm's own documentation notes that clearing is "typically unnecessary" because the cache is self-healing. Clear it to reclaim space, not to fix problems.
• pnpm: pnpm store prune removes packages that no project references. pnpm calls pruning "not harmful", though it may slow down future installs. Projects hard-link files from the store, so pruning is the way to free space. Deleting the store folder by hand frees less than you'd expect.
• Yarn 1: yarn cache dir shows the path and yarn cache clean empties it. Yarn 2 and later use a different cache layout and commands, so check yarn --version and the docs for your version first.

Old node_modules folders in projects you've finished with are often bigger than all three caches. Delete those per project. A fresh install brings them back.

#How do you clean Homebrew, CocoaPods, Gradle and Maven?

• Homebrew already tidies up: its FAQ says it removes old versions on upgrade and runs extra cleanup every 30 days. Preview with brew cleanup -n, then run brew cleanup. Add --prune=all to remove every cached download regardless of age.
• CocoaPods: pod cache list shows the cache and pod cache clean --all empties it. Without a pod name, --all is required, as a guard against wiping everything by accident.
• Gradle cleans ~/.gradle/caches on its own. By default, unused downloaded dependencies go after 30 days and the build cache after 7. You rarely need to step in. If you do, stop the daemons with gradle --stop first.
• Maven keeps every dependency in ~/.m2/repository, and it has no global cleanup command. Clearing it means re-downloading everything. It can also hold artifacts you built and installed locally with mvn install, which can't be downloaded again. Treat it as high-cost, and remove only folders for libraries you know you don't use.

#How do you clean pip, uv and Docker?

• pip: pip3 cache dir shows the location (~/Library/Caches/pip on macOS) and pip3 cache purge empties it.
• uv: uv cache prune removes unused entries only. uv cache clean clears everything, or one package if you name it. Prefer prune.
• Docker keeps images, containers and volumes in a single disk image (Docker.raw) inside ~/Library/Containers/com.docker.docker/Data/vms/0/data. With Docker running, docker system df shows what uses the space. docker builder prune clears build cache, and docker image prune -a removes images no container uses. docker system prune leaves volumes alone by default, which is right: volumes can hold databases. Prune them only when you know what's inside. Docker's docs also note that many tools report the image's maximum size, not the space it really uses.

#What about local AI models?

Models are now often the largest single item on a developer Mac. They're not really caches, since each one is a deliberate multi-gigabyte download.

• Hugging Face stores downloads in ~/.cache/huggingface/hub. hf cache ls lists what's cached with sizes and last-access dates. hf cache rm <repo> removes a model and hf cache prune clears unreferenced revisions and broken downloads. Both accept --dry-run.
• Ollama stores models in ~/.ollama/models. ollama ls lists them and ollama rm <model> removes one.

Remove models one at a time, by name, rather than deleting the whole folder.

#What should you not do?

• Don't run rm -rf on ~/Library/Developer as a whole. It mixes caches with archives, device logs and settings.
• Don't delete caches while the tool is running. Quit Xcode, stop builds and close package installs first.
• Don't prune Docker volumes blindly. A local database is not a cache.
• Don't clear caches before a flight or on a slow connection. Everything you delete has to come back over the network.
• Don't treat a big cache as a problem by default. A warm cache is what makes builds fast. Clear what you need, when you need it.

#Seeing every cache in one list

If you'd rather review all of this in one place than run fifteen commands, look for a tool that lists each cache with its size, explains what happens if you remove it and moves items to the Trash.

Freshist's Clean module covers developer junk such as Xcode derived data, npm, pnpm and Homebrew. Low-risk items like DerivedData and Homebrew downloads are pre-selected, while package stores, the Maven repository and AI models are listed for you to review but never pre-selected. For per-tool details, see the cache guides, Help & Docs or how it compares.

#Related guides

• What is System Data on Mac?
• Lost storage after the macOS 27 update? Here's why
• Time Machine local snapshots taking up space
• Mac Library folders explained

#Sources

• npm Docs: npm cache
• pnpm Docs: pnpm store
• Yarn Classic Docs: yarn cache
• Homebrew Docs: FAQ and brew manpage
• CocoaPods Guides: Command-line reference: pod cache
• Gradle User Manual: Gradle directories and automatic cleanup
• pip Docs: pip cache
• uv Docs: Caching
• Docker Docs: Prune unused Docker objects and Docker Desktop for Mac FAQs
• Hugging Face Docs: Manage huggingface_hub cache-system
• Ollama Docs: FAQ and CLI reference
• Apple Developer: Downloading and installing additional Xcode components