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
CocoaPods trunk read-only plan
61–70 of 116 posts
Re: CocoaPods trunk read-only plan
#62Finally!! 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…
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
#63This 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…
Re: CocoaPods trunk read-only plan
#64Re: CocoaPods trunk read-only plan
#65Earlier 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
Re: CocoaPods trunk read-only plan
#66Earlier 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
Re: CocoaPods trunk read-only plan
#67Earlier 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.
Re: CocoaPods trunk read-only plan
#68Earlier 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
Re: CocoaPods trunk read-only plan
#69Finally!! 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…
Re: CocoaPods trunk read-only plan
#70Earlier 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…
This can't be true, many people recognized all the deficiencies contemporaneously and even complained about them publicly?