# Developer Caches on Mac: What's Safe to Clear

> Where Xcode, simulators, npm, pnpm, Homebrew, Docker, pip, uv and AI model caches live on a Mac, what rebuilds, and each tool's own cleanup command.

- Published: 2026-10-10
- Updated: 2026-10-10
- Author: @cemali (https://www.linkedin.com/in/cemaligencer/)
- Topic: Storage
- URL: https://fresh.ist/blog/developer-caches-mac/

**TL;DR:** Developer caches are usually the biggest reclaimable space on a coding Mac. Xcode DerivedData, old simulator runtimes and Homebrew downloads are cheap to rebuild. Package caches (npm, pnpm, pip, uv) cost a re-download. Maven repositories, Docker volumes and local AI models are expensive or impossible to get back. Measure first, then use each tool's own cleanup command before deleting folders by hand.

*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:

```bash
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.

| Tool | Default location on macOS | Check with | Tool's own cleanup | Cost of clearing |
| --- | --- | --- | --- | --- |
| Xcode build products | `~/Library/Developer/Xcode/DerivedData` | `du -sh` | Delete with Xcode closed | Low: next build recompiles |
| Xcode device support | `~/Library/Developer/Xcode/iOS DeviceSupport` | `du -sh` | Remove old OS versions | Low: re-downloaded when the device reconnects |
| Simulators | Runtimes managed by Xcode | `xcrun simctl runtime list` | Xcode Settings or `simctl` | Low to medium: runtimes re-download |
| Homebrew | `~/Library/Caches/Homebrew` | `brew --cache` | `brew cleanup` | Low |
| npm | `~/.npm` | `npm config get cache` | `npm cache clean --force` | Medium: re-downloads packages |
| pnpm | `~/Library/pnpm/store` | `pnpm store path` | `pnpm store prune` | Medium |
| Yarn 1 | `~/Library/Caches/Yarn` | `yarn cache dir` | `yarn cache clean` | Medium |
| CocoaPods | `~/Library/Caches/CocoaPods` | `pod cache list` | `pod cache clean --all` | Medium |
| Gradle | `~/.gradle/caches` | `du -sh` | Automatic cleanup | Medium |
| Maven | `~/.m2/repository` | `du -sh` | Per-project purge | High: everything re-downloads |
| pip | `~/Library/Caches/pip` | `pip3 cache dir` | `pip3 cache purge` | Medium |
| uv | `~/.cache/uv` | `uv cache dir` | `uv cache prune` | Medium |
| Docker | `Docker.raw` disk image | `docker system df` | `docker builder prune` and friends | Medium to irreplaceable |
| Hugging Face | `~/.cache/huggingface/hub` | `hf cache ls` | `hf cache rm`, `hf cache prune` | High: large re-downloads |
| Ollama | `~/.ollama/models` | `ollama ls` | `ollama rm <model>` | High: large re-downloads |

## 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:

   ```bash
   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](/caches/), [Help & Docs](/help/) or [how it compares](/compare/).

## Related guides

- [What is System Data on Mac?](/blog/what-is-system-data-on-mac/)
- [Lost storage after the macOS 27 update? Here's why](/blog/mac-storage-after-macos-27-update/)
- [Time Machine local snapshots taking up space](/blog/time-machine-local-snapshots-space/)
- [Mac Library folders explained](/library/)

## Sources

- npm Docs: [npm cache](https://docs.npmjs.com/cli/v11/commands/npm-cache)
- pnpm Docs: [pnpm store](https://pnpm.io/cli/store)
- Yarn Classic Docs: [yarn cache](https://classic.yarnpkg.com/en/docs/cli/cache)
- Homebrew Docs: [FAQ](https://docs.brew.sh/FAQ) and [brew manpage](https://docs.brew.sh/Manpage)
- CocoaPods Guides: [Command-line reference: pod cache](https://guides.cocoapods.org/terminal/commands.html)
- Gradle User Manual: [Gradle directories and automatic cleanup](https://docs.gradle.org/current/userguide/directory_layout.html)
- pip Docs: [pip cache](https://pip.pypa.io/en/stable/cli/pip_cache/)
- uv Docs: [Caching](https://docs.astral.sh/uv/concepts/cache/)
- Docker Docs: [Prune unused Docker objects](https://docs.docker.com/engine/manage-resources/pruning/) and [Docker Desktop for Mac FAQs](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/)
- Hugging Face Docs: [Manage huggingface_hub cache-system](https://huggingface.co/docs/huggingface_hub/guides/manage-cache)
- Ollama Docs: [FAQ](https://docs.ollama.com/faq) and [CLI reference](https://docs.ollama.com/cli)
- Apple Developer: [Downloading and installing additional Xcode components](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components)

## Frequently asked questions

### Will clearing developer caches break my projects?

Clearing a cache doesn't change your source code or lockfiles. The next build or install just takes longer while the tool downloads or compiles again. The exceptions are data that isn't really a cache, such as Docker volumes, Xcode archives and artifacts you installed locally with Maven.

### How often should I clear developer caches?

Only when you need the space. Several tools already clean themselves: Homebrew runs cleanup on a schedule, and Gradle removes unused entries automatically. Clearing caches on a timer mostly makes your next builds slower.

### Why didn't deleting node_modules free as much space as expected?

If you use pnpm, files in node_modules are hard links to a shared store, so the same bytes are counted in two places. Space only comes back once nothing links to those files any more, which is what pnpm store prune handles.

### Should developer caches be in my Time Machine backup?

There's little point. They can be downloaded or rebuilt, and they change constantly, which makes backups bigger and slower. You can exclude folders such as DerivedData in System Settings › General › Time Machine › Options.

---

Canonical page: https://fresh.ist/blog/developer-caches-mac/
Official site: https://fresh.ist/ (fresh.ist only)
Generated: 2026-10-10