Run pod install in CI and on release builds. It installs the versions recorded in Podfile.lock and does not look for newer ones. Run pod update by hand, on purpose, when you want newer versions, then review and commit the changed lock file.
What each command does
The CocoaPods guides describe the split clearly.
| Command | Reads lock file | Looks for newer versions | Typical use |
|---|---|---|---|
pod install | Yes | Just for pods not yet locked | Setup, CI, adding or removing a pod |
pod update | Ignored | Yes, within Podfile limits | Deliberate upgrade |
pod update PODNAME | Ignored for that pod | Yes, for that pod | Targeted upgrade |
pod outdated | No changes made | Reports newer versions | Review |
For pods already in Podfile.lock, pod install uses the locked version without checking for a newer one.
Why this is a security question
Two properties matter. A build you cannot reproduce is a build you cannot audit. And an automatic upgrade means a new release of a dependency can reach your app without a human reading what changed.
If CI runs pod update, every build can pull different code. If CI runs pod install with a committed lock file, the build matches what was reviewed. The guide also notes that exact versions in the Podfile are not enough, because a pod's own dependencies can resolve differently over time. The lock file is what fixes that.
A workable routine
- Commit
Podfile.lock. CocoaPods says to do so even if you do not commit the Pods folder. - Use
pod installin CI. - Schedule
pod outdatedweekly and read the list. - When an advisory affects a pod, run
pod update PODNAMEfor just that pod. - Review the lock file diff in the pull request. Look for transitive pods that appeared or moved.
- Build and test before merging.
Common mistakes
- Running
pod updateto fix an unrelated build error, which upgrades everything. - Leaving the lock file out of version control, so each developer resolves differently.
- Approving a lock file diff without reading it.
For more on lock file integrity, see CocoaPods supply chain security and Podfile.lock integrity risks.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is surfaced for a vulnerable package, which is the signal that tells you to run a targeted update.
Safeguard builds an SBOM and scans your dependencies for known vulnerabilities, and you can run a free scan at gold.safeguard.sh/scan to see what your own project pulls in.
Quick check
Does pod install ever upgrade a pod?
Not one that is already in the lock file. It resolves pods that are new or whose Podfile requirement changed.
Should the Pods folder be committed?
The CocoaPods guide treats that as a team policy decision. It is firm that Podfile.lock should be committed.
Sources
Last reviewed: 19 October 2026.
