Such a big piece of history and a de facto standard for managing dependencies for Apple platforms for years.
Big "thank you" to all maintainers for your great job! And respect that you recognise moment when ecosystem changed and have courage to deprecate library instead of maintaining it forever - to leave place for migrating to new, superior solutions
This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift that current developer tools won't read, ...), and worst of all, it stores the full repositories of all the dependencies with their full history on your machine and downloads them every time when you do CI properly, which often means GBs of data.
Apple has always made it painful to step too far off the path with their tooling and frameworks and cocoapods was not immune to that pain. I'm grateful of what they made and the pressure they put on Apple to make things better, but I was very happy to remove yet another 3rd party dependency from our toolchain the moment we were able to.
The end of an era! Goodbye xcworkspace. For most of my use cases SPM is now much easier to use and causes less issues but a great effort from all the Cocoapods maintainers over the years.
I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
Finally!! I never liked CocoaPods due to how it “takes over” your Xcode project. I used to prefer Carthage, then just git submodules, then SPM. In my last job I oversaw SDK development and CocoaPods was the bain of my existence. Constant CDN problems causing release delays, annoying extra file in Ruby to maintain, different behavior than our other releases due to how CocoaPods builds projects, etc. SPM was as simple as pushing a git tag and maintaining a simple Swift file, while pushing to CocoaPods was rolling the dice how many times I’d get an error message. Good riddance!
The interesting question is what happens to the ~100k+ pods that never migrated to SPM. There's probably a lot of useful but abandoned code that smaller projects still depend on. This creates a bifurcation where legacy projects get stuck on older toolchains.
17 comments
[ 4.7 ms ] story [ 52.5 ms ] threadBig "thank you" to all maintainers for your great job! And respect that you recognise moment when ecosystem changed and have courage to deprecate library instead of maintaining it forever - to leave place for migrating to new, superior solutions
1 take over the thing 2 succeed at it as a platform owner 3 not put in resources to do it well
https://blog.cocoapods.org/CocoaPods-Support-Plans/
The timeline in the original article seems very reasonable to me. They go out of their way to avoid breakages.
I didn't like the way that it rewrote my project structure.
Once Swift Package Manager matured, I stopped using CocoaPods.
I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.