CocoaPods stores every pod three times, and only one is your project
A pod sits on your disk as index metadata, as a cached download, and as a copy in every project. Where each lives, what is safe to clear, and what to check first.
A pod you use in one app is on your disk in three separate places, and only the third one is anything to do with the project you are working on.
| Location | What it holds | Recreated by |
|---|---|---|
~/.cocoapods/repos | The index of every pod that exists, and its versions | pod install |
~/Library/Caches/CocoaPods | Downloaded pod source, kept per name and version | pod install |
<project>/Pods | The copy your build actually compiles | pod install in that project |
du -sh ~/.cocoapods ~/Library/Caches/CocoaPods 2>/dev/nullIf repos is gigabytes, you are still on the old setup
On the Mac used for this guide, ~/.cocoapods is 16 MB, all of it in repos/trunk. That is the modern arrangement, where the index is fetched on demand rather than held locally.
The older arrangement cloned the entire specification repository, every podspec for every pod ever published, as a git checkout at repos/master, along with its full history. It grew forever and it was routinely several gigabytes. Many Macs still have it because nothing removes it when you move on.
ls -1 ~/.cocoapods/repos
du -sh ~/.cocoapods/repos/* | sort -rhIf you see a master folder in that listing, that is the one. It can be removed with pod repo remove master, and pod install will use the on demand index instead. The exception is a project whose Podfile explicitly names the git source rather than the default, which needs that line changed first, otherwise the next install clones it all back.
The download cache
~/Library/Caches/CocoaPods keeps the downloaded source of every pod version you have installed, so a second project using the same pod does not fetch it again. Like every other package cache, nothing prunes it.
pod cache list | head -40
pod cache clean --allClearing it is safe and costs one slower pod install on whichever project you set up next.
The Pods folders are usually the real number
Each project keeps its own Pods directory, commonly a few hundred megabytes and much more for anything using a large analytics or maps dependency. Old projects keep theirs indefinitely, so the total scales with how many iOS repos you have ever cloned.
find ~ -type d -name Pods -not -path "*/Pods/*" 2>/dev/null \
| xargs du -sh 2>/dev/null | sort -rh | head -20A Pods folder is rebuilt exactly by pod install, as long as the project still has its Podfile.lock, which pins the precise versions. That lock file is the thing to check before deleting anything: with it, the rebuild is identical, and without it you get whatever resolves today.
What else is under the same roof
Pods sit next to the other things an iOS machine accumulates, and they are rarely the largest. The Xcode folders that cleanup guides miss covers archives and device support, which are usually bigger, and DerivedData is bigger again. Clearing all of them in one pass is the difference between a few gigabytes and a few tens of gigabytes.
Common questions
Is it safe to delete a Pods folder?
Yes, as long as the project still has its Podfile.lock. Running pod install rebuilds the folder at exactly the pinned versions. Check whether the project commits its Pods folder to git first, since deleting it there shows as a change in the repository.
How do I clear the CocoaPods cache on a Mac?
Run pod cache clean --all, which empties ~/Library/Caches/CocoaPods. The next pod install redownloads what it needs. You can see what is stored first with pod cache list.
What is the ~/.cocoapods/repos/master folder?
A full git clone of every published podspec, from the older CocoaPods setup, and often several gigabytes. Modern installs fetch the index on demand into repos/trunk instead, which is a few megabytes. If master exists you can remove it with pod repo remove master.