good news, react native and flutter piggyback on external deps need to stop
CocoaPods trunk read-only plan
21–30 of 116 posts
Re: CocoaPods trunk read-only plan
#22This 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…
Tuist
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/
Re: CocoaPods trunk read-only plan
#23Doesn't React Native depend on this very heavily for iOS?
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)
Re: CocoaPods trunk read-only plan
#24Sad, truly an end of an era. Big thanks to all maintainers!
Re: CocoaPods trunk read-only plan
#25End of an era.
Was it a good era?
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 GitHub for hosting so nobody would get bankrupted running the repo, with the option to switch over to self-hosted in case that ever became necessary. * Use Git and existing project tools on GitHub to deal with external contributions for pods. * 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 (ie. so CocoaPods didn't need a parser).
For a long time this was a one-person effort.
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.
I think Eloy did a great job in general and the popularity gained speaks for itself.
Re: CocoaPods trunk read-only plan
#26Re: CocoaPods trunk read-only plan
#27Re: CocoaPods trunk read-only plan
#28End of an era.
Was it a good era?
As a very occasional iOS developer, I never enjoyed it. 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.
Re: CocoaPods trunk read-only plan
#29This 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…
I don’t know, I’ve never had those problems and my codebases reach 600k+ LOC. I’ve certainly had plenty of errors to deal with Cocoapods and obsolete frameworks though, though those projects also tend to use pretty much every third-party lib that gets attention on Medium.
Modularizing an Xcode project with local Swift packages has been the best productivity gain in my experience. Doing something similar with Cocoapods is a headache.
Re: CocoaPods trunk read-only plan
#30Isnt this a old news? I'm thinking of Swift Package manager for all the stuff new.
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... while their Pod integration has always been working well.
That is the cost of using third party libraries, hardly the fault of either SPM or Cocoapods.