Can I Delete the Pods Folder? Yes, CocoaPods Rebuilds It
**/PodsYes, you can delete the Pods folder. It contains the iOS and macOS dependencies that CocoaPods installed into your project, and running pod install rebuilds it from your Podfile.lock. The only real cost is the time it takes to re-download and reinstall everything before your next build. Keep the Podfile and Podfile.lock, delete the rest without worry.
What it is
Pods is the folder CocoaPods creates inside an Xcode project when you run pod install. It holds the source code (or prebuilt binaries) for every dependency listed in your Podfile: networking libraries, analytics SDKs, UI components, all of it, plus a generated Pods.xcodeproj that Xcode compiles alongside your app. It sits next to your Podfile in the project root, so every CocoaPods project on your Mac has its own copy.
It grows with your dependency list. A small app with a handful of pods might carry a Pods folder of 100 to 300 MB. Apps that pull in Firebase, heavyweight SDKs, or long dependency chains often pass a gigabyte per project. If you have five or ten old projects sitting in a Developer folder, the duplicated Pods folders add up fast, which is usually how people end up searching for this page.
Is it safe to delete?
Deleting Pods is safe because it is entirely reproducible. Your Podfile says what you depend on, and Podfile.lock pins the exact versions. Run pod install in the project folder and CocoaPods rebuilds the Pods folder to the same state. You lose nothing permanent. What you pay is a re-download and a fresh build: a few minutes on a decent connection for most projects, longer for dependency-heavy apps.
The one thing to get right is what not to delete. Podfile and Podfile.lock stay. Lose the lock file and the version pins go with it, so the next pod install can quietly upgrade dependencies; lose the Podfile and CocoaPods has nothing to work from. Also close Xcode first, since it holds references to Pods.xcodeproj through the workspace. For projects you still build regularly, deleting Pods only buys you temporary space. For old projects you have shelved, it is some of the easiest space on a developer Mac. Diskmack finds every Pods folder across your projects automatically and cleans them the safe way.
How to check its size
In Finder: Open Finder, press Command-Shift-G (Go > Go to Folder), and enter your project path, for example ~/Developer/MyApp. Select the Pods folder inside it, then press Command-I to see its size. Repeat for each project, since every CocoaPods project has its own Pods folder.
In Terminal:
du -sh ~/Developer/MyApp/PodsReplace ~/Developer/MyApp with your project's path; if the path contains spaces, quote everything after the ~/, like du -sh ~/"My Projects/MyApp"/Pods. To measure every Pods folder under your projects directory at once: find ~/Developer -type d -name Pods -prune -exec du -sh {} +.
How to clean it
- Quit Xcode so nothing holds the workspace or Pods.xcodeproj open.
- In Finder, open your project folder. You should see Podfile, Podfile.lock, and the Pods folder side by side.
- Drag the Pods folder to the Trash. Do not touch Podfile or Podfile.lock.
- Empty the Trash to actually reclaim the space.
- Next time you work on that project, open Terminal, cd into the project folder, and run pod install. CocoaPods rebuilds Pods from Podfile.lock, then you build from the .xcworkspace as usual.
Delete the Pods folder, never Podfile.lock. The lock file is what lets pod install restore the exact same dependency versions instead of whatever is newest.
Will it come back?
Yes, and that is by design. The next pod install recreates the Pods folder at roughly the same size, because it reinstalls the same pinned dependencies. Deleting it is a real win only for projects you are not actively building: archived client work, abandoned side projects, old tutorials. For a project you build every day, the space comes back within minutes of your next install, so clean the stale projects and leave the active ones alone.
Common questions
Will deleting the Pods folder break my Xcode project?
Not permanently. The workspace still opens, but builds fail, usually complaining that a Pods xcconfig file cannot be found or that the sandbox is not in sync with Podfile.lock, until you run pod install again. One command puts everything back.
Should I delete Podfile.lock too?
No. Podfile.lock records the exact version of every dependency. Keep it, and pod install rebuilds the identical setup. Delete it, and the next install may pull newer versions than your project was tested against.
Should the Pods folder be in .gitignore?
Teams disagree, and CocoaPods supports both choices. Many projects ignore it because pod install can rebuild it from Podfile.lock, which keeps the repository small. Either way, deleting your local copy is safe as long as the Podfile and Podfile.lock are intact.
What about the CocoaPods cache in ~/Library/Caches/CocoaPods?
That is a separate download cache CocoaPods keeps so reinstalls are faster. You can clear it with pod cache clean --all. The trade-off is that your next pod install downloads everything from the network again.
Related folders
- Is It Safe to Delete Xcode's DerivedData Folder?
- Is It Safe to Delete Xcode Archives? Yes, but Keep the Ones That Matter
- Is Xcode's Download Cache Safe to Delete? (com.apple.dt.Xcode)
- Is It Safe to Delete iOS DeviceSupport Files on Your Mac?
- iOS Simulator Caches Taking Up Space? Yes, You Can Delete Them
- What Is the .hermes Folder on Your Mac, and Can You Delete It?