CocoaPods trunk read-only plan • Hacker News Board

Re: CocoaPods trunk read-only plan

#51

Post by nikanj » Mon, Sep 01, 2025, 2:24 PM UTC

cnnlives65 wrote: post #46

nazgu1 wrote: post #2

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

> superior solutions Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.

Open source superior just means newer, even if it comes with less features and more bugs

Re: CocoaPods trunk read-only plan

#52

Post by basisword » Mon, Sep 01, 2025, 2:29 PM UTC

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

Re: CocoaPods trunk read-only plan

#53

Post by wahnfrieden » Mon, Sep 01, 2025, 2:46 PM UTC

myko wrote: post #34

wahnfrieden wrote: post #15

Earlier quoted context omitted.

Tuist

I will never start another Apple platform application without Tuist. If I start work on one I will do my best to get buy-in to switch.

It is also the only good way to use LLMs to manage projects/workspaces

You can use it for non-Apple platforms btw. Swift on Linux, Android, Windows, WASM. Projects like https://swiftcrossui.dev (with major contribution from Miguel de Icaza recently) and https://skip.tools for instance make this all the more productive

Re: CocoaPods trunk read-only plan

#54

Post by secretsatan » Mon, Sep 01, 2025, 2:46 PM UTC

gregoriol wrote: post #8

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…

Yeah, no, cocoapods was a nightmare compared to SPM, every ios update supplied a new unsolved issue in one pod or another that required dark incantations.

Managing a local pods caused issues so great engineers quit

Re: CocoaPods trunk read-only plan

#55

Post by gwbennett » Mon, Sep 01, 2025, 2:47 PM UTC

secretsatan wrote: post #54

gregoriol wrote: post #8

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…

Yeah, no, cocoapods was a nightmare compared to SPM, every ios update supplied a new unsolved issue in one pod or another that required dark incantations. Managing a local pods caused issues so great engineers quit

100% agree!

Re: CocoaPods trunk read-only plan

#56

Post by adithyassekhar » Mon, Sep 01, 2025, 2:48 PM UTC

AJRF wrote: post #23

oefrha wrote: post #17

Earlier quoted context omitted.

Yeah, and according to https://expo.dev/blog/precompiled-react-native-for-ios and linked https://github.com/react-native-community/discussions-and-pr... , it seems moving off CocoaPods has barely moved past planning stage. Latest update from two weeks ago links to https://github.com/facebook/react-native/pull/52909 and says it’s very very experimental. Just great…

Gosh, that is a worry. Maybe I can help out here (I imagine the politics of a project this large will frustrate me though)

Why would you work for free for Facebook

Re: CocoaPods trunk read-only plan

#57

Post by jamil7 » Mon, Sep 01, 2025, 2:50 PM UTC

Terretta wrote: post #38

seanalltogether wrote: post #13

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.

> Apple has always made it painful to step too far off the path Or, "Apple has always avoided spending dev cycles too far off the path, electing instead to make the path itself easier." xCode with built-in live rebuild preview simulator plus xCode Cloud with Testflight which auto-builds on git push is a remarkable value for $8.33 a month.

> xCode with built-in live rebuild preview simulator

You couldn't have picked a slower, more buggy, opaque feature to highlight here. Its useful for UI work when it works properly but I feel like I have to mentally prepare myself everytime I switch the canvas on to avoid throwing the computer out the window.

I'll agree on Xcode Cloud though, integrated CI, signing and TestFlight builds with minimal hassle is very nice.

Re: CocoaPods trunk read-only plan

#58

Post by stevage » Mon, Sep 01, 2025, 2:50 PM UTC

>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.

Re: CocoaPods trunk read-only plan

#59

Post by einsteinx2 » Mon, Sep 01, 2025, 2:55 PM UTC

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!

Re: CocoaPods trunk read-only plan

#60

Post by ardit33 » Mon, Sep 01, 2025, 3:09 PM UTC

einsteinx2 wrote: post #59

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…

lol... you really don't like it, do you. I used it for a couple of my projects, and I kinda agree with you. I didn't like it at all how it took over projects (you have to use a workspace).

For my small personal projects, eventually I ended up into reverting to just downloading the dependencies myself into a lib folder. A bit more work upfront, but simpler builds and you know what's going into your project.

I think it had its use and time, and it is good for the maintainers to mark it deprecated and time to move on.