SwiftNIO is dropping support for CocoaPods

Related Projects SwiftNIO
1

Hi NIO users,

The next set of NIO releases will be the final set for which we publish
CocoaPods.

The final version of each package supporting CocoaPods will be:

  • SwiftNIO 2.40.0
  • SwiftNIO HTTP/2 1.21.0
  • SwiftNIO SSL 2.19.0
  • SwiftNIO Transport Services 1.12.0
  • SwiftNIO Extras 1.11.0

We strongly urge users of CocoaPods to switch to Swift Package Manager (SPM)
as no further CocoaPods will be published. This includes security updates.

Supporting CocoaPods alongside SPM has been worthwhile to-date in that it has
allowed adopters to use either package manager as SPM has matured and its
adoption has grown.

However, supporting it comes with additional maintenance cost: each release
requires the SwiftNIO team to publish 40+ Podspecs over the various SwiftNIO
repositories. While this is semi-automated, it is still a time consuming task
which is prone to failure. Users have also run into compile time issues which
are specific to CocoaPods for which the team is not always well placed to debug.

We believe that SPM has wide enough adoption at this point that libraries in
the ecosystem do not need to support both. Indeed some new packages have already
declined to support CocoaPods at all.

If you have any questions or concerns, please ask away in this thread.

26 Likes
2

I'm sorry, but this doesn't really seem like an acceptable change for a minor release. Not only do you vastly underestimate the ease with which users can switch from CocoaPods to SPM, there are also specific use cases where SPM just doesn't work. Not to mention the sub-par Xcode UX and frequent bugs. And in general, refusing security updates mid release cycle just seems bad for the community.

This just isn't true. I can't think of any library which doesn't support CocoaPods that did it based off some statistic. Instead, it's usually just a matter of policy, like the various swift-x libraries refusal to support CocoaPods from day one. Additionally, since many of these frameworks are foundational, it essentially forces any library which adopts them not to support CocoaPods, whether they want to or not. So the fact that some libraries only support SPM isn't evidence of anything by itself. It was only in the last two years that SPM surpassed CocoaPods for personal usage and CocoaPods still leads for corporate usage (likely due to SPM's missing features and corporate inertia).

So obviously I think this is a bad idea. However, if you insist on dropping support, can you at least archive all of the podspecs into a single place so people can fork and maintain them on their own?

15 Likes
3

We need more SPM use cases and articles. Using SPM is still difficult.

4

I disagree; it does not break the public API.

However absolutely empathise with your viewpoint: it will be an inconvenient and no doubt frustrating change for some adopters.

We may reconsider our position here.

I did not mean to imply that those packages have made the decision based off some statistic, only that adoption of SPM has grown and that there are packages which have declined to support Cocoapods. "Indeed" was a poor choice of word and I apologise for that.

The SwiftNIO repositories contain scripts for generating podspecs:

I should add that while the community is welcome to maintain them we do intend to adopt swift-atomics and swift-collections.

3 Likes
5

SPM has a forums area (Package Manager - Swift Forums) which is a good place to get help if you have problems using it.

4 Likes
6

Additionally I'll note that the podspecs are public and part of the cocoapods repository.

1 Like
7

What about creating a new repository (let's just say github.com/swift-server-community/swift-nio-podpecs for the sake of the argument) and publishing the latest podspecs there? That way the community can view & iterate on them easily if there's enough interest?

The repo and the podspecs could then clearly be annotated that they're not officially supported by the SwiftNIO project or so.

3 Likes
8

I think this is a good idea.

Are there any community members willing to take ownership of this? We can facilitate getting this setup.

2 Likes
9

There's a related discussion around Swift-Log on GitHub here.

I don't have enough experience with the Swift ecosystem to judge whether SwiftPM adoption is wide enough now (more than a year from the original post), but I certainly feel that way.

I'm happy to help cleanup SSWG projects systematically, and add any necessary documentation and tutorials to boost SwiftPM adoption, and clarify whether we support cocoapods, and what version of each project is available.

How do things look now? Should I start with a bit or research and a full list of project and their current state on cocoapods?

10

I'd be surprised if any SSWG supported Cocoapods. The only way to build with Linux is SwiftPM

11

Many of those projects also make sense on the client side, most importantly SwiftNIO. There is a reason why transport services exist.
(that is true for pretty much any protocol implementation)