Announcing the Networking Workgroup

Announcements
,
1

This was also posted on the Swift.org blog

The Swift Ecosystem Steering Group is excited to announce the creation of the Networking workgroup! Workgroups are community-led efforts, formally recognized by the project, to advance key areas of Swift.

The primary goal is to guide the evolution of networking libraries, protocols, and APIs in the Swift ecosystem, making networking in Swift excellent everywhere: high-level and safe by default, modular and interoperable, cross-platform, and observable.

Networking is one of the most common entry points for Swift developers, and the ecosystem has matured significantly over the years. Foundational libraries like SwiftNIO, AsyncHTTPClient, and swift-http-types, alongside platform stacks such as URLSession and Network.framework, power networking across apps, servers, and beyond. The workgroup will build upon these efforts and pursue the long-term directions outlined in the Networking vision, focusing on work to:

  • Define a unified networking stack with a coherent layered architecture, from shared I/O primitives at the foundation, through common protocol implementations, to ergonomic client and server APIs at the top.
  • Define currency types that let libraries interoperate without coupling to specific implementations, such as IP addresses, hostnames, ports, and HTTP requests and responses.
  • Evolve HTTP APIs by designing and guiding a modern, unified HTTP client and server API built on structured concurrency.
  • Guide the evolution of shared protocol implementations (TLS, HTTP/1.1, HTTP/2, HTTP/3, QUIC, WebSockets) so improvements benefit the entire ecosystem rather than being duplicated across libraries.

The new Networking workgroup joins a growing list of Swift workgroups, including the Android workgroup, Windows workgroup, and Build and Packaging workgroup, which were all added in the past year.

To learn more and get involved:

  • Discuss this announcement on the forums, and share ideas in the Networking category.
  • Learn more about the Networking workgroup by reading its charter.
  • The workgroup meets biweekly. A regular meeting time is being finalized and will be announced on the forums ahead of the first public meeting.
    • Workgroup membership and meetings are open to those who wish to participate, and contributors are welcome!
    • To receive an invite, send a message to @networking-workgroup on the Swift forums.
35 Likes
Can SwiftPM not default to low macOS versions?
2

Congratulations on the launch of the NWG! This is a fantastic step for the ecosystem.

As someone who has spent significant time in the networking stack—from fixing UDP in swift-nio-transport-services to contributing to DNSClient and building external signer support for swift-nio-ssh — I am incredibly excited to see this group form.

Regarding the goal of designing a common IP address type, I’d love to offer the work we’ve been doing with swift-cidr as a reference implementation for a suite of network currency types.

We’ve found that for robust infrastructure and control-plane software, the currency layer needs stable, first-class models for not just addresses, but networks, CIDR blocks, and multicast ranges. We’ve spent the last several months modeling these using compile-time traits for family safety and optimized the core logic for zero-dependency performance (benchmarked against system inet_pton/inet_ntop baselines).

I am very interested in actively contributing to the design and implementation of these common types. What is the best way to participate in the upcoming design sessions and technical reviews?

6 Likes
3

I'd also like to introduce swift-endpoint as a contender, like I've done before here in the swift forums:

  • swift-endpoint contains IPv4, IPv6, AnyIPAddress, CIDR, DomainName (w/ IDN) implementations.
  • In most cases it performs better or much-better than using the C-lib APIs, at least when called from Swift.
  • Provides what I think is a good API surface, alongside providing performant ways to convert the types to each-other (and String) where needed.
  • Has an exhaustive amount of tests. Has a good amount of benchmarks.
  • Has very low Apple platform requirements of macOS-10.15-and-friends which required a decent amount of work. I hope this is not even needed and we can just jump straight to macOS 26, but we'll have to see how realistic that is and if it doesn't block adoption of existing SwiftPM packages which follow SemVer 2.0, or such.

Knowing @camunro, I'd think either swift-cidr or swift-endpoint or a combination of both should be able to satisfy that one goal of the Networking work-group, which is a nice head-start for the Networking work-group to have, even before its inception :sweat_smile:.

5 Likes