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
> 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
OP here, luckily in this case, it means a more supported and vertically integrated alternative. Which does have less features, but actually gets bugs fixed and keeps up to date with the platform - so it's a net win overall IMO
This happens in proprietary software too.
Superior means it does 5 new things that the 5 maintainers wanted, but nobody else uses.
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.
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.
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.
> It really feels like Apple's teams are not using any of SwiftPM themselves.
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.
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.
Yeah, I’ve hit many pain points over the years with SwiftPM. Its restrictions on compiler flags is also problematic.
If you're looking for an outdated command, maybe this works for you? https://github.com/kiliankoe/swift-outdated/
Disclaimer: I wrote this (a while back)
My biggest criticism with SPM is that there doesn't seem to be a way to use it with git worktree since the package cache is centralized as opposed to being at the directory/project/workspace level.
Can you elaborate on the use case? I've started putting my local package dependencies into Vendor/ submodules in the repo I'm using them. I can't use worktrees with this setup?
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
100% agree!
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
It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)
Glad we've cleared it up
> I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)
That is on you, though.
Another non-iOS developer here. It was absolutely not clear what you meant with a single word reply, and one that honestly looked like a typo or some kind of insult (short + -ist) I didn’t get.
What I meant is that people who are non-ableist, non-racist, etc. do not have racism et al. popped up in their mind.
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.
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, it’s the kind of thing that the mind naturally develops habits to avoid, in much the same way that you might start to walk differently through a city after getting mugged. It is indeed tiring for everyone, but the solution is not to blame people for doing what they feel like they need to do to protect themselves.
Of course I do, but we are talking about a project's name.
That’s the whole point. If you know we are talking about a project name (for instance by using the word in a sentence) then it makes perfect sense, but with no context one is left to try to use etymology like one might do with any unknown word.
I completely agree with you that if I had wanted to I could have put in the effort to decipher the meaning of the post. However, the post left me with absolutely no desire to decipher it's meaning, so I did not. If instead the author had written simply "I use tuist for that" the meaning would have been immediately clear for someone like me, and I would have been much more likely to look up the product.
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.
We are talking about a project's name. Why did racism (and friends) came up in your mind, or an insult? Why is this the default norm, now? People are free to down-vote me, but they cannot deny there is no truth to what I am saying. I would have never thought that a project's name was intended to be racist or cause any sort of harm. Why did you?
> We are talking about a project's name. Why did racism (and friends) came up in your mind, or an insult?
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.
Because it was a single word ending in -ist, the common English suffix for a prejudice or preference? There was no context indicating that it was the name of a project.
And you resort to either it being an insult or something about ableist, racism, etc.? That was not something I thought of until I got reminded.
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.
Have you worked with Bazel before? Do you have a comparison to Tuist?
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
Neat, I may check that out.
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.
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!
It was a product of it’s time, it highlighted an issue that apple never really addressed, i have much more confidence in the future of SPM because at least it seems to be moving in tandem with Swift
I agree entirely. I feel like CocoaPods should have done this shortly after iOS 8 was released when dynamic frameworks were added. It was a terrible solution to a problem that way outlived its usefulness and because of that has absolutely polluted the ecosystem.
Finally someone sane.
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.
Haha I really don’t, but I do get why others liked it, it was just never for me. I also forgot the intermediate step I took between git submodules and SPM where I did exactly what you did with manually adding deps to the project. Git submodules is it’s own frustrating hell lol…
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.
The reasoning is here, from 2024
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.
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.
> 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.
Doesn'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…
It's not actually that concerning. RN's pods are vended via npm not trunk so trunk going read-only will not have an outsized impact on RN.
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 think the most concerning part is all the third party libraries already on life support or already abandoned a few years ago will all die during the switch.
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
rn is open source so I don’t personally see it as working for free for facebook but rather working for free for the dev community
Flutter has moved to Swift Package Manager, it’s just not enabled by default iirc
From the official docs it sounds more like experimental support that's still under development.
Already has complete support for SPM.
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.
Capacitor too, for hybrid mobile apps
Unity also afaik.
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.
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 :)
As long as the Obj-C and Swift are in separate source or binary targets, SPM supports them being in the same 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...
Yes, you can use SPM to package up Objective-C code.
Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though).
You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.
Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher.
My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)
Oh gotcha, yeah they’re absolutely usable as any maintainer mixing the languages and providing SPM support will handle the binary release part. If anything it’s nicer for the consumer (binary releases in general) as it cuts down on full app rebuild times.
I'm not sure. I suspect so, but I haven't used ObjC since 2014.
Isnt 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.
Thoroughly enjoyed while it lasted! Thank you maintainers.
The interesting question is what happens to the ~100k+ pods that never migrated to SPM. There's probably a lot of useful but abandoned code that smaller projects still depend on. This creates a bifurcation where legacy projects get stuck on older toolchains.
> The interesting question is what happens to the ~100k+ pods that never migrated to SPM.
> abandoned code that smaller projects still depend on
You'll still be able to use those - the CocoaPods repo will not go away any time soon. If someone wants to provide updates for those, it has to be migrated to SwiftPM. And in the meantime you may have to use both SwiftPM and CocoaPods, or fork & migrate those yourself.
>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.
End 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.
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.
> and a year ago they were all singing asdf’s praises.
This can't be true, many people recognized all the deficiencies contemporaneously and even complained about them publicly?
Not sure what you mean exactly, but what I assume happens is someone finds the new thing and the old things deficiencies become more apparent because they are both called out by creators of the new thing and probably a major reason the new thing exists. The devs that found new thing start advocating for it while bashing the old thing. Like I said I think it is fine and healthy to advocate for and want to improve tooling, it just bugs me when it is done while bashing what was likely a fairly thankless labor of love.
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.
No pods are an absolute misery and at best a concrete example of what not to do. So at least there's that.
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.
It may not have been great, but it was certainly better than the likely alternative (no package management at all for iOS development).
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.
Better than the "current" future
No.
Absolutely No.
No.
And this, kids, is why you should always vendorize your dependencies
There may be good reasons to do that, but this isn't one. Any project using CocoaPods will still remain working for the foreseeable future - you'll just not get new updates to dependencies at some point. And at that point you can migrate to SwiftPM or vendored dependencies, without losing anything.
Good idea let's punt it to 20 years from now when the CocoaPods server goes down. By then the startup will have been acquired and we will be long gone, so it's the parent company's problem not ours.
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)
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)?
React native support for SPM is non-existent for the most part. There's some work on porting to SPM but it's gonna be a while before anything becomes stable. It's going to break a huge amount of 3rd party packages. A bit of shame this wasn't done earlier as the RN ecosystem just went (or, is still going) through a migration to the "new architecture" that required most 3rd party packages that use native code to be "ported" over. Could have been a two-for-one kinda thing!
React-Native is blocked by SwiftPM not supporting mixed ObjC and Swift packages. It needs that to support both the Old Architecture and the New Architecture at the same time.
Sad, truly an end of an era. Big thanks to all maintainers!