Live data from Hacker News

CocoaPods trunk read-only plan

blog.cocoapods.org

31–40 of 116 posts

Re: CocoaPods trunk read-only plan

#31

Earlier quoted context omitted.

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/

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

Re: CocoaPods trunk read-only plan

#32
post #4

Earlier quoted context omitted.

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.

I preferred Carthage in theory, but every time I tried using it in anger I hit enormous stumbling blocks with projects not actually living up to its exacting standards, then spent hours faffing about before going back to CocoaPods.

I'm happy to see the back of CocoaPods, but it kickstarted the library package ecosystem on the Apple platforms, where there was nothing like it before.

Re: CocoaPods trunk read-only plan

#34

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…

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.

Re: CocoaPods trunk read-only plan

#35

good news, react native and flutter piggyback on external deps need to stop

https://docs.flutter.dev/packages-and-plugins/swift-package-...

https://docs.flutter.dev/packages-and-plugins/swift-package-...

no idea if google will nix flutter tomorrow or not but it is extremely well run and seems to stay ahead of things pretty well, even though i'd rather write Swift than Dart (or Kotlin, for that matter)

Re: CocoaPods trunk read-only plan

#36

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, I’ve hit many pain points over the years with SwiftPM. Its restrictions on compiler flags is also problematic.

Re: CocoaPods trunk read-only plan

#38

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.

Post reply on HN