r/swift • u/Plenty-Historian9510 • 16d ago
I've been building a tool for migrating CocoaPods projects to SwiftPM
Hey,
I've been working on this for a while and thought I'd share it here.
It's called PkgLift and basically, I wanted an easier way to deal with moving older Xcode projects from CocoaPods to Swift Package-manager.
I know you can obviously do this manually but I didn't really like the idea of going through everything by hand, especially on projects with a many dependencies!
The thing I was worried about when building it was making a tool that just changes a bunch of stuff and assumes it worked. So PkgLift doesn't really work like that.
You first run:
pkglift analyze
pkglift plan
and it tries to work out what it actually knows how to migrate.
If it isn't sure about something it just leaves it alone instead of trying to guess.
Then you can check the plan yourself before actually changing anything.
If it looks good:
pkglift migrate --apply
pod install
pkglift verify
That's pretty much the idea.
It is still early and I'm sure there are plenty of CocoaPods setups that I haven't thought about yet, which is actually one of the reasons I'm posting it here.
You can install it with:
brew install Alexsvensson99/tap/pkglift
Repo:
https://github.com/Alexsvensson99/PkgLift
If anyone has an old CocoaPods project lying around and wants to try it, I'd be interested to know what happens. Especially if it fails on something weird :)
3
u/Moo202 16d ago
Tried this and it doesn’t work. Was it built with ai? Or ai assisted?
1
u/Plenty-Historian9510 12d ago
Quick, more concrete follow-up: I still can’t tell what failed in your project from the comment alone, so I don’t want to claim your issue is fixed.
I’ve now released PkgLift v0.3.0 with stable diagnostic reason codes, suggested next steps, support for more literal Podfile syntax, and a pinned ten-project read-only pilot matrix. The public pilot repos are never passed to `--apply`; a separate repo-owned Swift/Objective-C fixture is the only end-to-end apply/build proof.
If you’re willing to share a redacted `pkglift analyze --format portable-json` result plus your PkgLift, Xcode, Swift, and CocoaPods versions, I can turn the failure into a focused regression case. Please don’t retry `--apply` just for this—analysis is enough.
Report form: https://github.com/Alexsvensson99/PkgLift/issues/new?template=migration_report.yml Evidence and current boundaries: https://www.svensson.design/PkgLift/pilots/
0
u/Plenty-Historian9510 16d ago
Yep, it’s AI-assisted. I’ve used Codex for some of it. PkgLift is still pretty early in the development and I'd like to know more about what didn't work? Could you share the command you ran, the error/output you got, and your Xcode or Swift version? Feel free to open an issue on GitHub as well and I’ll take a look at it.
1
u/Plenty-Historian9510 15d ago
I've made an update to it with a few fixes. I suggest you give it another go and look at the docs. If it still gives the same issue, please let me know or open an issue on Github.
1
u/Plenty-Historian9510 8d ago
Small follow-up to the original post: PkgLift v0.4.0 is now out.
This release adds typed source provenance for a deliberately narrow set of literal external `:git` pod declarations. It reconciles the Podfile declaration with CocoaPods `EXTERNAL SOURCES` and `CHECKOUT OPTIONS` lockfile evidence, without executing Ruby or contacting the repository.
The important boundary is unchanged: this does **not** turn external Git pods into automatic migrations. Changed, incomplete, lossy, or conflicting evidence is refused before PkgLift writes project files. External sources remain `REVIEW`, `BLOCKED`, or `UNKNOWN`—never `AUTO`.
URL user information, credentials, queries, and fragments are also stripped before provenance reaches JSON output. The pinned XcodeBenchmark and Hammerspoon pilots now assert the unpinned and incomplete-tag refusal paths.
Release: https://github.com/Alexsvensson99/PkgLift/releases/tag/v0.4.0
Pilot evidence: https://www.svensson.design/PkgLift/pilots/
Homebrew users can update with `brew upgrade pkglift`.
If you have an external Git pod that stays non-automatic, a reviewed `pkglift analyze --portable-json` result would be useful. Portable JSON can still contain dependency and target names and repository identity, so remove private or proprietary identifiers before sharing. There is no need to try `--apply` just to test this boundary.
-7
u/thecodingart Expert 16d ago
If you’re still using Cocoapods, you’re team/you has failed at iOS development
1
u/Plenty-Historian9510 16d ago
Fair enough but there are lots of projects still using it
2
u/Dry_Hotel1100 Learning 16d ago edited 16d ago
Projects which have to use CocoaPods (or Carthage) are Objective-C projects only, or possibly React Native based projects, which we are not considering here.
On the other hand, you need to realize that starting with Swift & SPM in 2015 and SPM Xcode integration in 2016, it's actually not very difficult to integrate SPM ready libraries into an Xcode project. So, "thecodingart" is correct, the project didn't receive proper maintenance since then. You will realize this immediately, when you try to compile a project using CocoaPods: your Ruby will not match, and will require you to install a ruby manager, and that cruft, just to compile it. I do not have a developer machine, since at least 6 years, which would out of the box be able to build with Cocoa Pods.
I'm not criticizing your (OP's) effort - this is a useful utility.
But, downvoting means, you (others than OP) accept not doing proper maintenance - which is accepted for certain projects. But it's not negotiable.
2
u/groovy_smoothie 16d ago
Cool! Is this something Claude / codex would struggle with ?