Swift networking is heading in a much more ambitious direction than “one API over URLSession and AsyncHTTPClient.” The Swift Networking Workgroup’s latest meeting notes say there was strong consensus to prioritize a native, top-to-bottom Swift networking stack. Why build another stack? Control. A native implementation can give Swift direct control over performance, behavior, allocations and code size instead of treating platform networking libraries as black boxes. The interesting part is that they are not ignoring today’s reality. The immediate direction is to design an abstract HTTP API that can work with existing backends, but shape it so a future high-performance native implementation is not constrained by those backends. They are also discussing contribution standards that track allocations, instructions and code-size regressions from the start. Nothing here is a shipped API yet. But it is a meaningful architectural direction for cross-platform Swift: networking as Swift infrastructure, not just a wrapper around whatever each platform already provides. #SwiftLang #SwiftNetworking forums.swift.org/t/networkin…