Migrate in small steps and record the before and after. Export the current pod versions from your lock file, move one dependency at a time to a Swift package at the same version, and compare lists after each step. That way you never lose track of what ships or which advisories apply.
Why migrations lose visibility
Moving package managers changes where versions are written down. CocoaPods records installed versions in Podfile.lock. Swift Package Manager records them in its own resolved file. During a move, a library can quietly change version, switch to a different fork, or gain new transitive packages. If nobody compared the lists, you find out after release.
Step by step
- Snapshot the current state. Save
Podfile.lockand a list of pod names with versions. This is your baseline. - Check availability. For each pod, confirm the upstream project publishes a Swift package. Do not assume a third party mirror is the same code.
- Match versions first. Add the package at the version you already ship, using a version requirement such as
from. Upgrading during migration mixes two changes and makes problems hard to trace. - Remove one pod at a time. Delete it from the Podfile, run
pod install, add the package, build, and test. - Compare lists. After each move, list your dependencies again and diff against the baseline. Look for new transitive packages.
- Check source URLs. A Swift package is identified by its repository URL. Confirm it is the maintainer's own repository.
- Handle binary pods. If a pod ships a prebuilt framework, see how SwiftPM treats a binary SDK and its checksum.
- Commit the new resolved file and remove the Pods artifacts you no longer use.
- Keep the old lock file in history so an audit can reconstruct what shipped before the move.
What to watch for
| Risk | Check |
|---|---|
| Version drift | Compare against the baseline after each step |
| Look alike repositories | Verify the URL belongs to the maintainer |
| Hidden transitive packages | Re-list dependencies after each change |
| Pods with build scripts | Review what the script did and whether SwiftPM needs an equivalent |
CocoaPods guidance says to always commit Podfile.lock, and the same habit applies to the Swift resolved file.
Try it yourself
Click through it at your own pace, or open it full screen. Use it to picture the before and after inventory you want to compare.
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
Should I migrate and upgrade at the same time?
No. Match versions first, then upgrade as a separate change so any new problem has one cause.
How do I know a Swift package is the real one?
Check that the repository URL is the maintainer's own, and compare the version and tag history with what you used as a pod.
Sources
Last reviewed: 19 October 2026.
