Deep dive into standardizing common IP Address and Port types (25 min)
There's a requirements discussion underway covering cross-platform currency types for IP addresses and ports. We'd like to talk through open questions, discuss requirements, and explore prior art in more depth.
Community agenda items and open discussion (as time permits)
Wrap-up and action items (5 min)
Propose an agenda item
We'd love the agenda to reflect what the community wants to discuss. Please reply to this thread with topics you'd like to cover, ideally with a sentence or two of context and roughly how much time you think it needs. To keep the meeting focused, we'll include some agenda topics from the replies received for discussion as time permits and include anything else in the list of potential topics for future meetings.
A few notes so the meeting stays productive with a larger group:
Most decisions happen asynchronously on the forums, Slack, and GitHub. The meeting is for discussion and alignment, so you can participate fully asynchronously if you wish or cannot attend a particular timeslot.
We'll use a raised-hand queue and chat for questions and discussions. Please take note of your position in the queue and try to avoid collisions with others when speaking.
We'll post the notes from the meeting here on the forums afterwards. Note that we're piloting AI note-taking tools but won't be recording the meeting, and you can ask us to turn them off at any time.
We follow the Swift Code of Conduct. This is a public meeting, so please keep discussion to public, non-confidential topics.
Hello everyone, I’m really looking forward to taking part in the meeting!
I’d like to propose an agenda item on the WebTransport protocol. With the arrival of SwiftNIO QUIC and SwiftNIO HTTP/3, we can now start working on an implementation for the Swift ecosystem of the WebTransport protocol, which is a sort of new version of WebSocket for the QUIC era.
In September, I’ll be starting an internship at my university, also under the supervision of @0xTim, with the aim of developing a WebTransport client and an implementation of the server-side protocol in Swift. I’d love to present my project and perhaps get some feedback.
I’ve drawn up a project plan, but I haven’t written a single line of code yet, so I don’t think it’ll take me more than five minutes to go through it all.
Thank you in advance, and in any case, see you on Monday!
Following Requirements for IP address and port APIs - #8 by MahdiBM, an agenda item I'd like to propose is to settle on what platform requirements we'd like to have, and what platforms we'd like to exclude. Specifically about Apple platform requirements where new APIs can be tied to OS versions.
Do we want to support macOS 26 and above? 15 and above? 13 and above?
SwiftPM in Swift 6.4 assumes a minimum of macOS 12 by default so that's the lowest we should consider (not sure if you can or cannot write applications for e.g. macOS 10.15 in it).
Notable macOS requirements that I've noticed:
macOS 26:
InlineArray. Can sometimes be worked around with APIs which require closures, such as withUnsafeTemporaryAllocation which hands you a stack-allocated pointer.
UTF8Span (String.utf8Span). Can be worked around unless you need specific UTF8Span functionalities like checkNFC().
Even for checkNFC(), you could simply implement it yourself, just that it's a lot of trouble to do so manually. Requires unicode understanding and lookup tables.
Some other .span implementations like Array.span: All can be worked around by using existing value.withUnsafe*Pointer APIs and calling .span/.mutableSpan on the pointer.
macOS 15:
Mutex, Atomic (Synchronization module): Not a blocker since there are a lot of other impls (like swift-nio's NIOLock, or swift-atomics).
UInt128: Can be hard to work around, can need you to manually roll your own type backed by 2 UInt64s.
swift-endpoint contains its own UInt128 impl (UnsignedInteger128) for this reason.
macOS 14:
SerialExecutor: Not a blocker, can be worked around.
withDiscardingTaskGroup: Not a blocker, can be worked around.
macOS 13:
Clock, Duration: Generally required for proper networking, but swift-endpoint specifically doesn't need any of them.
macOS 11:
String(unsafeUninitializedCapacity:initializingUTF8With:): Required for performant initialization of Strings.
macOS 10.15 (or maybe 10.14 / lower):
Structured Concurrency APIs such as Task. Required for proper "modern" networking.
Backdeployed Span APIs. Pretty much required. (One could use UnsafePointers instead if they really want to).
Currency-type family constraints on IPAddress and Port — ~8 minutes
Within the IP address/port deep dive: can we identify adjacent semantic types and invariants that should constrain this foundation—e.g. address family, prefix length, canonical network/prefix, and endpoint—so endpoint, routing, policy, IPAM, and registry-facing libraries do not need incompatible second models?
Desired outcome: a small requirements matrix and a place to continue the work asynchronously, rather than an API decision during this meeting.
Here are the summarized notes. Corrections welcome, either as replies or via DM:
Swift Networking Workgroup Meeting Notes
Meeting Details
Date: August 3, 2026
Summary
The Swift Networking Workgroup reviewed its roadmap, focusing on the standardization of shared currency types like IP addresses and ports. Key discussions centered on balancing modern Swift features with backward platform compatibility and designing a progressively-disclosed API. The group also heard a proposal for a new community-led WebTransport implementation project and offered support.
Notes
1. Introduction & Roadmap Recap
The workgroup's primary goal is to unify efforts to improve networking in Swift. Key priorities were reviewed:
Evolving HTTP APIs: Modernizing client and server APIs for Swift concurrency, bridging existing implementations.
Shared Currency Types: Standardizing types like IP addresses and ports. The initial focus is on these types due to their foundational nature and the many areas of relevance in the ecosystem.
Unified Networking Stack: Long-term goal to define how data passes between layers in a Swift concurrency world, which depends on foundational abstractions like a byte buffer type.
2. Deep Dive: IP Address & Port Standardization
A significant portion of the meeting was dedicated to defining standard IP address and port types.
Platform & API Design: The main discussion centered on platform compatibility versus using modern language features.
A proposal was made to use modern features like inline arrays for address storage, which offers a more correct and performant representation than tuple-based approaches.
This creates a conflict with the need to support older OS versions, as libraries like SwiftNIO cannot easily adopt features that are not backward-compatible without a major version bump.
The team noted that Swift Package Manager's policy of treating minimum deployment target increases as a breaking change is a significant blocker.
A potential solution of using conditional compilation to provide different underlying implementations was discussed. This would allow new code to use modern features while maintaining a compatibility layer for older targets, though it adds complexity.
Scope of Currency Types: The discussion explored the appropriate scope for the initial effort.
The team acknowledged that concepts like subnets, CIDR, and prefix length are naturally pulled into any discussion of IP addresses.
The need to handle network interfaces and link-local scoped addresses was also identified as an unavoidable complexity that must be addressed in some way.
A key design principle of progressive disclosure was advocated: APIs should be simple for common use cases but scalable for advanced, low-level networking tasks.
The group agreed on the importance of gathering code examples of expected usage to inform a practical and developer-friendly API design.
Leveraging Prior Art: The team discussed how to learn from existing implementations.
The author of the swift-cidr library shared lessons learned, such as moving from structs to protocols to create a more extensible design that separates pure math operations from the context of their use (e.g., routing vs. interface addresses).
swift-endpoint and swift-network-evolution were also raised as prior art in this area with important learnings that should be captured.
3. Community Agenda: WebTransport Implementation
A community member presented a plan to implement the WebTransport protocol in Swift.
The project is planned as a university internship starting in September.
The implementation will depend on several building blocks from the ecosystem, including support for Extended CONNECT, Capsules, and HTTP Datagrams.
The team expressed support, noting that experts on the WebTransport specification and its implementation in Safari are available in the workgroup to compare notes and provide feedback.
The presenter was encouraged to share progress, learnings, and challenges on the forums and Slack to foster collaboration.
4. Wrap-up & Logistics
The meeting concluded with a thank you to participants for their engagement and a call for feedback on the meeting format to improve inclusivity and effectiveness.
Next Steps & Action Items
Tommy will post a recap of the IP address and port standardization discussion to the forums to engage the wider community.
The team will use the #networkingSlack channel and the forums for ongoing, real-time discussion and prototyping of IP address types.
The team will proceed with experimentation in separate repositories to explore different API designs and compatibility strategies for the new networking types.
Francesco will begin the WebTransport implementation project and will share progress and questions with the workgroup.
Eric will post the summarized meeting notes to the forums.