CocoaPods trunk read-only plan

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.

The reasoning is here, from 2024

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.

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.

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!

Doesn't React Native depend on this very heavily for iOS?

It was useful, but way too delicate.

I didn't like the way that it rewrote my project structure.

Once Swift Package Manager matured, I stopped using CocoaPods.

Isnt this a old news? I'm thinking of Swift Package manager for all the stuff new.

Thoroughly enjoyed while it lasted! Thank you maintainers.

End of an era.

>I don't think I'm amenable to moving it forwards, but within reason there's space for backwards.

Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.

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.

good news, react native and flutter piggyback on external deps need to stop

And this, kids, is why you should always vendorize your dependencies

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)?

Sad, truly an end of an era. Big thanks to all maintainers!