CocoaPods trunk read-only plan

Here are the main themes from the Hacker News discussion about CocoaPods:

Acknowledgment of CocoaPods' Historical Significance and Impact

Many users recognize CocoaPods' pioneering role in dependency management for Apple platforms, especially given the landscape before its existence.

• "Such a big piece of history and a de facto standard for managing dependencies for Apple platforms for years." - nazgu1
• "all modern-day package managers owe a debt to Cocoapods for the things it did right and the things that could have been better." - Cthulhu_
• "but it kickstarted the library package ecosystem on the Apple platforms, where there was nothing like it before." - jurip
• "it was an indispensable tool for many years. This is evident by its massive popularity." - K0nserv
• "it highlighted an issue that apple never really addressed" - secretsatan

Mixed Opinions on CocoaPods' "Superiority" and User Experience

While some acknowledge its innovation, others strongly criticize CocoaPods for its usability issues, performance, and the way it modified project structure. The term "superior" is debated, with some seeing it as euphemism for "newer" or "different" rather than objectively better.

• "Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic." - cnnlives65
• "Open source superior just means newer, even if it comes with less features and more bugs" - nikanj
• "Superior means it does 5 new things that the 5 maintainers wanted, but nobody else uses." - exe34
• "OP here, luckily in this case, it means a more supported and vertically integrated alternative. Which does have less features, but actually gets bugs fixed and keeps up to date with the platform - so it's a net win overall IMO" - orta
• "No pods are an absolute misery and at best a concrete example of what not to do. So at least there's that." - weego
• "I never enjoyed it. I preferred Carthage and jumped over SPM the moment it became available." - tomashubelbauer
• "I don't think I'm amenable to moving it forwards, but within reason there's space for backwards." - stevage
• "Finally!! I never liked CocoaPods due to how it “takes over” your Xcode project." - einsteinx2
• "I didn't like it at all how it took over projects (you have to use a workspace)." - ardit33
• "I didn't like the way that it rewrote my project structure." - ChrisMarshallNY
• "I've found it gets the job done and the fact that it’s both run off a simple Swift file and git tags and has official support from Apple is great. Kind of reminds me of Carthage for the modern age, in a good way." - einsteinx2

The "Product of Its Time" Argument and Contextualizing Decisions

Several users defend CocoaPods by emphasizing the historical context of iOS development and the constraints developers worked under, highlighting that its decisions (like using Ruby) were practical given the tools and knowledge available at the time.

• "You have to understand where we came from. Development for iOS and macOS (then MacOS) meant you had to pluck source files from random places on the internet and weave them into your Xcode build. Xcode and xcodebuild didn't really shine in the department of extensibility." - Manfred
• "Eloy designed CocoaPods to be the absolute minimum we needed to deal with dependencies for the projects we were working on. So that meant: Rely on GitHub for hosting... Use Git and existing project tools on GitHub... Use Ruby for scripting because that was what people used most at that time. Use Ruby for pod definitions for flexibility and reduced development time..." - Manfred
• "All of those decision obviously have downsides, even more obvious now you have to power of hindsight given years of incremental improvements on speed and security of dependency managers." - Manfred
• "It was a product of it’s time, it highlighted an issue that apple never really addressed" - secretsatan

Transition to Swift Package Manager (SPM) and its Imperfections

The discussion frequently contrasts CocoaPods with Swift Package Manager (SPM). While SPM is generally seen as the future and often preferred, users point out its own set of issues, including incomplete feature sets, bugs within Xcode, and performance concerns related to repository storage.

• "I preferred Carthage and jumped over SPM the moment it became available. I understand SPM didn't or even still doesn't meet the needs of many professional iOS developers, but for my hobby needs, it was the simplest and easiest to use." - tomashubelbauer
• "From my experience, about 20-30% of the packages are not working with swiftpm, either because they don't have a Package.swift file, or because it is not compatible with up-to-date developer tools. On many projects, I had to fork a few repositories just to add or fix the swiftpm integration..." - gregoriol
• "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." - gregoriol
• "Its restrictions on compiler flags is also problematic." - meisel
• "SwiftPM been little trouble for me, with the most complex project involving a number of external packages and a couple of local ones. No crashes or anything like that. It’s been way, way less trouble than CocoaPods was before I switched several years ago." - cosmic_cheese
• "SwiftPM 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!" - einsteinx2
• "I also forgot the intermediate step I took between git submodules and SPM where I did exactly what you did with manually adding deps to the project. Git submodules is it’s own frustrating hell lol… More recently though the lack of maintenance of the CDN causing lots of problems not only publishing but even just pod installs failing was really frustrating..." - einsteinx2
• "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." - pbd
• "Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though)." - armadsen

Gratitude for Maintainers and a Shift in Development Philosophy

There's a consistent thread of appreciation for the hard work and dedication of the CocoaPods maintainers, coupled with a sentiment of moving forward and building on past efforts without discarding them entirely.

• "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" - nazgu1
• "I am going to start sounding like a dinosaur but I really hate this dev tendency to trash the old way as soon as the new way comes out. I am seeing it with all the devs advocating for mise over asdf, and a year ago they were all singing asdf’s praises. I think we can advocate for better while still thanking those we are building upon. Long winded way of saying: thanks to the cocoapods maintainers, you made iOS dev better for a lot of people." - mrbombastic
• "Thank you maintainers." - bingemaker
• "Great thanks to all of the Cocoapods maintainers over the years." - basisword
• "Sad, truly an end of an era. Big thanks to all maintainers!" - forgingahead

Broader Ecosystem Impact and Adoption

The discussion touches on how CocoaPods' deprecation will affect other cross-platform or hybrid frameworks like React Native, Flutter, and Unity, highlighting the challenges and ongoing work in migrating these ecosystems.

• "Does React Native depend on this very heavily for iOS?" - AJRF
• "It does, in recent react native versions they show a deprecation warning when running “pod install” directly which is probably a signal they are working on moving to other package managers, but not aware of what the plan is." - mrbombastic
• "Capacitor too, for hybrid mobile apps" - oulipo2
• "Flutter too..." - cthulberg
• "Unity also afaik." - everyone
• "Flutter has moved to Swift Package Manager, it’s just not enabled by default iirc" - arnath

Apple's Role and Ecosystem Control

Some users view CocoaPods' deprecation as a natural progression driven by Apple's own tooling and ecosystem development, suggesting that Apple "makes it painful to step too far off the path."

• "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." - seanalltogether
• "Or, 'Apple has always avoided spending dev cycles too far off the path, electing instead to make the path itself easier.'" - Terretta
• "and the fact that it’s both run off a simple Swift file and git tags and has official support from Apple is great. Kind of reminds me of Carthage for the modern age, in a good way." - einsteinx2