Live data from Hacker News

CocoaPods trunk read-only plan

blog.cocoapods.org

61–70 of 116 posts

Re: CocoaPods trunk read-only plan

#61
post #51

Earlier quoted context omitted.

> 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

Superior means it does 5 new things that the 5 maintainers wanted, but nobody else uses.

Re: CocoaPods trunk read-only plan

#62
post #60

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…

Haha I really don’t, but I do get why others liked it, it was just never for me. 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, and as an SDK/framework maintainer just having to support multiple package managers was a huge pain in the ass. Especially with React Native requiring CocoaPods and having its own weird problems we have to solve in the pod file.

But yeah glad to see it being sunset now that there’s an officially sanctioned package manager. I know some people will complain that SPM isn’t as full featured as CocoaPods but I’ve found it gets the job done and the fact 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.

Re: CocoaPods trunk read-only plan

#63

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…

My biggest criticism with SPM is that there doesn't seem to be a way to use it with git worktree since the package cache is centralized as opposed to being at the directory/project/workspace level.

Re: CocoaPods trunk read-only plan

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

Re: CocoaPods trunk read-only plan

#65

Earlier quoted context omitted.

In spite of search engines being a thing, this comment could have done with a bit more information. I assume you're talking about this: https://docs.tuist.dev/en/

Yes. There's no ambiguity, no other project uses the name

It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)

Re: CocoaPods trunk read-only plan

#66
post #51

Earlier quoted context omitted.

> 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

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

Re: CocoaPods trunk read-only plan

#67
post #44

Earlier quoted context omitted.

As someone with no direct love of CocoaPods... Is there a way to use SPM for mixed ObjC and Swift projects? I'd love to know if I have options :)

Yes, you can use SPM to package up Objective-C code.

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

Re: CocoaPods trunk read-only plan

#68
post #23

Earlier quoted context omitted.

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

rn is open source so I don’t personally see it as working for free for facebook but rather working for free for the dev community

Re: CocoaPods trunk read-only plan

#69

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…

It was a product of it’s time, it highlighted an issue that apple never really addressed, i have much more confidence in the future of SPM because at least it seems to be moving in tandem with Swift

Re: CocoaPods trunk read-only plan

#70
post #25

Earlier quoted context omitted.

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

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 be…

> and a year ago they were all singing asdf’s praises.

This can't be true, many people recognized all the deficiencies contemporaneously and even complained about them publicly?

Post reply on HN