CocoaPods predates Swift Package Manager as the dominant dependency manager for iOS and macOS projects, and a large number of established codebases still rely on it, sometimes alongside SPM for newer dependencies. Its cache follows a similar shape to other package managers' — a shared store that avoids re-downloading the same library version across projects — but it has its own quirks worth understanding before you clear it.

Where CocoaPods keeps its cache

On macOS, CocoaPods stores its cache at ~/Library/Caches/CocoaPods/. Inside, you'll typically find:

  • Pods/ — the actual downloaded source for every pod version you've ever installed across any project, organised by pod name and version.
  • A specs cache — metadata about available pod versions and their dependency requirements, pulled from the CocoaPods spec repositories (or, more commonly today, the CDN-backed trunk source) so pod install doesn't need to re-fetch the entire index on every run.

This is conceptually the same split as npm's or pip's caches: downloaded package content plus resolution metadata, kept together under one root.

Checking the size

du -sh ~/Library/Caches/CocoaPods

or, using CocoaPods' own reporting:

pod cache list

which prints every cached pod and version currently stored, giving you a sense of scale before deciding whether a full clean is worth it.

pod cache clean --all

pod cache clean --all

This clears the entire cache — every downloaded pod source across every project you've ever built. The next pod install for any project re-downloads whatever it needs. This is safe in the same sense every package manager cache is safe: nothing here is unique data, only a local copy of something publicly available (or available from your private spec source, if you use one).

You can scope the clean to a specific pod if you suspect one particular cached version is the problem rather than wanting a full reset:

pod cache clean <PodName>

When a stale cached pod actually causes a problem

The most common real-world trigger is a pod version that was updated at its source (a git tag that got force-pushed, or a spec repository entry that changed) after CocoaPods had already cached the old content locally. pod install then keeps installing what's in your local cache instead of pulling the corrected version, because from CocoaPods' perspective the version number hasn't changed even though the underlying content has. Clearing that specific pod's cache entry, or the whole cache if you're not sure which one, forces a fresh download and resolves the mismatch.

Another trigger: a partially downloaded pod left behind by an interrupted pod install (network drop, a killed process), leaving inconsistent or incomplete cached data that later installs try and fail to use.

Source pods versus pre-built pods

It's worth understanding the two ways CocoaPods can deliver a dependency, since they interact differently with the cache and with your project's build time:

  • Source pods — the default. CocoaPods downloads the library's source code and compiles it as part of your project's own build, every time, using whatever build settings your project specifies. The cache here stores the source, not a compiled artefact, so clearing it costs you a re-download but not necessarily a longer build if the source was already fine.
  • Pre-built pods (via use_frameworks! combined with tools or workflows that support prebuilt binary distribution, or pods that ship as .xcframework binaries directly) — CocoaPods uses a compiled binary rather than compiling source itself. These tend to be larger individual cache entries since they include compiled code for multiple architectures, but they save build time on every subsequent pod install and build cycle.

Clearing the cache affects both categories the same way — a fresh download on next install — but the practical cost in rebuild time differs: losing a cached pre-built binary and having to compile that dependency from source instead (if that's the fallback) can meaningfully lengthen your next build, whereas losing a cached source pod just means a re-download before the same compile step that would have happened anyway.

The Pods folder inside each project is separate

Don't confuse the shared cache at ~/Library/Caches/CocoaPods with the Pods/ directory that lives inside each individual project after running pod install — that project-local folder contains the actual installed dependencies for that specific project, generated from the shared cache, and is what your Xcode workspace directly references. Deleting a project's local Pods/ folder is also safe (CocoaPods regenerates it from the cache, or re-downloads if the cache has also been cleared), but it's a different folder serving a different purpose from the shared cache this article covers.

Private spec repositories add their own storage

If your team maintains a private CocoaPods spec repository — common for internal libraries shared across multiple apps within a company — be aware that CocoaPods clones and keeps a local copy of that entire spec repository, separate from the CDN-backed trunk source most public pods use today. These private spec repo clones are typically stored under ~/.cocoapods/repos/, not inside ~/Library/Caches/CocoaPods, and can grow over time as the spec repository's own history grows, particularly for repositories that have been in use for years and accumulated many historical pod version entries.

du -sh ~/.cocoapods/repos/*

is worth checking separately if your projects reference a private source in their Podfile. Removing an entry here and running pod repo update (or pod install, which triggers an implicit update in most configurations) re-clones it fresh, at the cost of a full re-clone rather than an incremental fetch.

A practical routine

  1. pod cache list or du -sh ~/Library/Caches/CocoaPods to see the current scale.
  2. If you're chasing a specific install problem, try pod cache clean <PodName> for the pod in question before clearing everything.
  3. For general disk pressure with no install issues, pod cache clean --all reclaims the space at the cost of slower re-downloads on your next pod install across any project.
  4. Separately, if a specific project's local Pods/ folder looks unusually large or you suspect it's out of sync, delete it and re-run pod install — CocoaPods regenerates it from the (still-warm, unless you also cleared it) shared cache.

Where VolumeLens fits in

CocoaPods' shared cache and each project's local Pods/ folder both add up quietly across an iOS developer's history of projects, and neither is obvious from Finder's default view. VolumeLens scans your whole disk and shows both, sized honestly, next to Xcode's own DerivedData and Archives folders that tend to accumulate on the same machine. Learn more about Insights for automatic recognition of CocoaPods and other developer caches.