CocoaPods trunk read-only plan
blog.cocoapods.org
blog.cocoapods.org
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 includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.
That is on you, though.
I don't mean to imply that there is some sort of "should" to this. The author is not required to want their meaning to be understood, even though I'm not really sure what other purpose they would have for posting. But I do think that this class of miscommunication is both common and reasonably avoidable by building up a bit of a mental model of the intended audience. I was trying to provide anecdotal evidence to build up that mental model.
Please don’t take what I said as any kind of allegation that you were being insulting. Those associations were from trying to parse the word as English, which resulted in some unknown word from the family of words relating to prejudice presumably relating to textual user interfaces vs graphical. Context would have made it clear that it was a project name, in which case the word doesn’t need to be parsed.
Why does everything have to do with those things in people's minds? It is tiring, and I am starting to believe they are the racists.
It never crossed my mind based on the name of a project. It is ridiculous.
I did not, for a second, think, that an unknown word was intended to be racist, ableist, etc.
Why would you?
Also parent's reply:
> If you’re not familiar with the experience of browsing the internet and then suddenly having deeply-held parts of your identity deemed undeserving of respect [...] the solution is not to blame people for doing what they feel like they need to do to protect themselves.
It was a comment under a submission, FWIW.
Seriously though, just stop assuming everything is about race and friends. It is what is tiring. Ask first before making assumptions if it really is not a slur you know of, but an UNKNOWN WORD. If he were to say n***e* then yeah, have at it. That cannot be misunderstood.
And by my reply "That is on you" is down-voted for fuck-all, because people does not realize that the people preoccupied with racism are the ones first to believe it was a racist slur. I did not think it was a racist slur, because 1) it was an unknown word, 2) I am not preoccupied with such stuff, my mind is not filled with racism and such. Thus, the people who say "racist!" usually turn out to be the racists. I have seen it everywhere. Now I saw it on HN, too, which is just splendid. A single search would have sufficed. I do not deny that the person saying the word could have clarified what it is, but defaulting to believing it has to do with racism is one of the reasons for why we have racism. It did not cross my mind. Why did it cross yours, especially if you knew nothing but the unknown word?
I do not see race. Am I the racist one or the people thinking everything is about racism? Do not worry, I see race when it comes to a groups of people, except in that case it does not matter much, a group of people may always be trouble, regardless of race, so no, I did not abandon my self-preservation.
There is a lot to unpack here, my bad.
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
For my Swift backends running on Linux I have just been using SPM and when working on macOS open the manifest directly. I haven't really done anything with a non-web UI with Swift outside of blessed platforms.
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.
They probably never will, at least not for anything that ships with the OS. For Apple, binary size is very important, and it’s essential that they have only one of every library (“project”) installed on the device, and that they use dynamic linking everywhere.
SwiftPM uses static linking to the core, and if Apple were to use it, binary sizes would balloon (not to mention there would be potentially mutually incompatible versions of things.) You could fix this by ignoring version specs in the package file and building just one of every project/framework, and changing it to use dynamic linking everywhere… but at some point you’re just contorting swiftpm to become a big mono-build system, which only Apple would really be using as such.
It’s been way, way less trouble than CocoaPods was before I switched several years ago. CocoaPods was so bad about screwing itself up that I’d just check in its dependencies in a building state and avoid upgrading anything unless I absolutely had to, because inevitably when doing updates or even just resolving my project would somehow hit some number of the many edge cases that’d cause it to blow up.
In contrast with SwiftPM I keep most dependencies pretty close to current because it’s painless to do so.
In fact it’s been good enough to me that I wish it were possible to replace the awful mess that is Gradle with SwiftPM (or a 1:1 JVM counterpart) on the Android side. I need approximately none of Gradle’s flexibility and bells and whistles that make it such a pain in the rear, so something with SwiftPM’s simplicity would be a serious QoL improvement.
Managing a local pods caused issues so great engineers quit
Disclaimer: I wrote this (a while back)
1 take over the thing 2 succeed at it as a platform owner 3 not put in resources to do it well
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.
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.
https://blog.cocoapods.org/CocoaPods-Support-Plans/
The timeline in the original article seems very reasonable to me. They go out of their way to avoid breakages.
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.
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.
No there's not in fact it's actively frowned upon because if salaries are standardized no one will get to enjoy those huge faang pays. It'll be averages. That is not the capitalist way.
You're doing the work highly paid facebook and vercel employees are getting paid for.
The risk is that over time Cocoapods will no longer work to integrate dependencies with ways Xcode wants them to be.
Switching to SPM is a massive undertaking for a large project with many intertwined dependencies and configuration options. It's far less configurable than Cocoapods with basically no scripting options during install.
Their progress already is pretty decent!
I didn't like the way that it rewrote my project structure.
Once Swift Package Manager matured, I stopped using CocoaPods.
I'd love to know if I have options :)
My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)
For whoever comes after me... When ChatGPT suggests changing your Objective-C from this:
#import package.h
#import <package/package.h>
@import package;
There was a Swift Evolution proposal at one point to go all the way and bring in support for mixed Obj-C and Swift targets [1] but it was returned for revision. It talks about the multiple target workarounds:
> Distribute binary frameworks via binary targets. Drawbacks include that the package will be less portable as it can only support platforms that the binaries support, binary dependencies are only available on Apple platforms, customers cannot view or easily debug the source in their project workspace, and tooling is required to generate the binaries for release.
> Separate a target’s implementation into sub-targets based on language type, adding dependencies where necessary. For example, a target Foo may have Swift-only sources that can call into an underlying target FooObjc that contains Clang-only sources. Drawbacks include needing to depend on the public API surfaces between the targets, increasing the complexity of the package’s manifest and organization for both maintainers and clients, and preventing package developers from incrementally migrating internal implementation from one language to another (e.g. Objective-C to Swift) since there is still a separation across targets based on language.
The upshot is that SPM has a better interoperability story with Swift and C++ [2] and maybe that can serve as a foundation for getting to the same level of interop for Obj-C.
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
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.
This can't be true, many people recognized all the deficiencies contemporaneously and even complained about them publicly?
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.
Like with NPM, many people ran into issues ultimately rooted in not understanding the tool. CocoaPods had the extra constraint that correctly setting up a Ruby environment was hard. If you used Ruby with a fixed ruby version, bundler with a Gemfile.lock and then CocoaPods it worked well.
I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.
> The interesting question is what happens to the ~100k+ pods that never migrated to SPM.
> abandoned code that smaller projects still depend on
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)