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
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.
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.
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
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/
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.
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.
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.
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.
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.
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.
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.
Readit News
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.
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
Managing a local pods caused issues so great engineers quit
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.
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!
Deleted Comment
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 :)
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...
[2]: https://www.swift.org/documentation/cxx-interop/