To pin iOS SDK versions, commit the lock file your dependency manager writes, which is Podfile.lock for CocoaPods and Package.resolved for Swift Package Manager. Then change versions only on purpose: run pod install for routine builds, and review any diff to those files in code review.
What each lock file records
CocoaPods generates Podfile.lock after the first pod install. The CocoaPods guide says it tracks the version of each Pod that was installed, and that running pod install on another machine installs the locked versions even if newer ones exist. The same guide says the Podfile and Podfile.lock should always be kept under version control.
Swift Package Manager records the result of resolution in Package.resolved. For an app, Apple's package documentation says you can find the file inside your xcodeproj or xcworkspace.
If those files are not committed, two developers can build different SDK versions on the same day. The build you test is then not the build you ship.
Routine builds versus deliberate updates
CocoaPods users often run pod update when they mean pod install. The CocoaPods guide itself notes that people often use pod update where pod install is the right command. The first can move every pod within its allowed range. The second respects the lock.
A practical rule for the team:
- CI and daily work use pod install, or SwiftPM resolution from the committed Package.resolved.
- Upgrades happen in a dedicated branch, one SDK at a time where possible.
- The lock file diff is part of the pull request, and a named reviewer reads it.
Choosing a SwiftPM version rule
Apple's documentation describes three common choices:
| Rule | What it allows | Apple's guidance |
|---|---|---|
| From (up to next major) | Bug fixes and backward compatible features, not the next major | Described as the recommended way to specify a remote dependency |
| Exact | One version only | Not recommended, because it can cause conflicts in the dependency graph |
| Revision (commit) | One commit only | Not recommended, limited to exceptional cases; you receive no updates |
For an app, a from rule plus a committed Package.resolved is a common balance. The resolved file holds the exact version in practice, while the rule keeps future upgrades possible. Treat revision pins as an exception that needs a written reason and an end date.
Add a gate so pins mean something
Pinning prevents accidental drift. It does not stop a deliberate bump to a bad version. Add two checks in CI:
- Fail the build if a lock file changed and the pull request has no approver from the SDK owner list.
- Scan the resolved versions for known advisories before merge.
The first check ties pinning to your approval workflow. The second keeps a pinned version from quietly becoming a pinned vulnerability. When a fix is needed, see how fast you can ship a mobile fix for a vulnerable SDK.
Binary SDKs
Some SDKs ship as prebuilt frameworks. Apple's page says signatures are required where listed SDKs are used as binary dependencies, and that Xcode validates that a new version of a signed SDK was signed by the same developer. Treat that as a useful integrity check, not a full review.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the exact versions listed for each component. That is the information a lock file carries, and what you want a scanner to read.
Safeguard's dependency scanning reads lock files and manifests, and its free scan at gold.safeguard.sh/scan is a quick way to see what a repository resolves to today.
Quick check
Should Package.resolved be committed for an app?
Yes in most app teams, so every build resolves the same versions. Apple's page does not state a commit rule, so this is team practice rather than a vendor requirement.
Is an exact SwiftPM version safer than a from rule?
Not necessarily. Apple does not recommend exact rules because they can cause graph conflicts. A from rule with a committed resolved file gives stable builds without that cost.
Sources
- CocoaPods guide: Using CocoaPods
- Swift Package Manager: PackageDescription
- Apple: Upcoming third-party SDK requirements
Last reviewed: 19 October 2026.
