Such a big piece of history and a de facto standard for managing dependencies for Apple platforms for years.
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
cnnlives65 · 1h ago
> superior solutions
Superior includes actual state of being better. Differences could just be differences. Maybe it’s just homoplastic.
nikanj · 49m ago
Open source superior just means newer, even if it comes with less features and more bugs
gregoriol · 3h ago
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 that current developer tools won't read, ...), and worst of all, it stores the full repositories of all the dependencies with their full history on your machine and downloads them every time when you do CI properly, which often means GBs of data.
rTX5CMRXIfFG · 2h ago
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.
gregoriol · 1h ago
Local Swift packages are indeed improving the experience a little bit: better version management, less xcode crashes, slightly more explicit errors, but still highly troublesome. It really feels like Apple's teams are not using any of SwiftPM themselves.
cosmic_cheese · 1h ago
SwiftPM been little trouble for me, with the most complex project involving a number of external packages and a couple of local ones. No crashes or anything like that.
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.
meisel · 2h ago
Yeah, I’ve hit many pain points over the years with SwiftPM. Its restrictions on compiler flags is also problematic.
secretsatan · 27m ago
Yeah, no, cocoapods was a nightmare compared to SPM, every ios update supplied a new unsolved issue in one pod or another that required dark incantations.
Managing a local pods caused issues so great engineers quit
gwbennett · 26m ago
100% agree!
wahnfrieden · 3h ago
Tuist
richrichardsson · 2h ago
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/
wahnfrieden · 2h ago
Yes. There's no ambiguity, no other project uses the name
myko · 2h ago
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.
wahnfrieden · 27m ago
It is also the only good way to use LLMs to manage projects/workspaces
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
einsteinx2 · 18m ago
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 as pushing a git tag and maintaining a simple Swift file, while pushing to CocoaPods was rolling the dice how many times I’d get an error message. Good riddance!
ardit33 · 4m ago
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 had its use and time, and it is good for the maintainers to mark it deprecated and time to move on.
stevage · 23m ago
>I don't think I'm amenable to moving it forwards, but within reason there's space for backwards.
Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.
seanalltogether · 3h ago
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.
Terretta · 1h ago
> 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.
jamil7 · 23m ago
> xCode with built-in live rebuild preview simulator
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.
AJRF · 3h ago
Doesn't React Native depend on this very heavily for iOS?
Flutter has moved to Swift Package Manager, it’s just not enabled by default iirc
chairhairair · 1h ago
Already has complete support for SPM.
mrbombastic · 3h ago
It does, in recent react native versions they show a deprecation warning when running “pod install” directly which is probably a signal they are working on moving to other package managers, but not aware of what the plan is.
The timeline in the original article seems very reasonable to me. They go out of their way to avoid breakages.
ChrisMarshallNY · 1h ago
It was useful, but way too delicate.
I didn't like the way that it rewrote my project structure.
Once Swift Package Manager matured, I stopped using CocoaPods.
josteink · 1h ago
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 :)
kenshi · 1h ago
Yes, you can use SPM to package up Objective-C code.
ChrisMarshallNY · 1h ago
I'm not sure. I suspect so, but I haven't used ObjC since 2014.
aravindputrevu · 3h ago
Isnt this a old news? I'm thinking of Swift Package manager for all the stuff new.
gregoriol · 3h ago
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.
rTX5CMRXIfFG · 2h ago
That is the cost of using third party libraries, hardly the fault of either SPM or Cocoapods.
bingemaker · 3h ago
Thoroughly enjoyed while it lasted! Thank you maintainers.
sturza · 3h ago
End of an era.
deadbabe · 3h ago
Was it a good era?
Manfred · 2h ago
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.
mrbombastic · 1h ago
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 better for a lot of people.
K0nserv · 1h ago
Yes! I'm a little biased as someone who worked briefly on CocoaPods, but it was an indispensable tool for many years. This is evident by its massive popularity.
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.
weego · 3h ago
No pods are an absolute misery and at best a concrete example of what not to do. So at least there's that.
tomashubelbauer · 2h ago
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.
jurip · 2h ago
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.
swiftcoder · 2h ago
It may not have been great, but it was certainly better than the likely alternative (no package management at all for iOS development).
Cthulhu_ · 3h ago
Probably not, but all modern-day package managers owe a debt to Cocoapods for the things it did right and the things that could have been better.
gregoriol · 3h ago
Better than the "current" future
frizlab · 3h ago
No.
rvz · 2h ago
Absolutely No.
Copenjin · 2h ago
No.
tonyhart7 · 2h ago
good news, react native and flutter piggyback on external deps need to stop
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)
basisword · 44m ago
The end of an era! Goodbye xcworkspace. For most of my use cases SPM is now much easier to use and causes less issues but a great effort from all the Cocoapods maintainers over the years.
I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?
forgingahead · 2h ago
Sad, truly an end of an era. Big thanks to all maintainers!
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.
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.
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
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 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.
Side note: not everyone interprets "forwards" and "backwards" in the same way for statements like these. Saying "sooner" or "later" is clearer.
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.
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.
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 :)
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.
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'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.
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)
I wonder how interoperable SPM is though with non-Xcode build pipelines (e.g. Unity projects, ReactNative, Flutter, etc)?