Networking Q&A

We are developing a network extension that utilises the NEPacketTunnelProvider. We have noticed when the extension is running, and the phone screen is off, after about 10 seconds the device goes to system sleep (as evidenced by messages like “suspended timer for imminent system sleep” in the console logs) and the network extension simply won’t run any code during this time, therefore stopping traffic flow. When the device wakes up from sleep, such as when the screen comes on the network extension resumes executing code and runs normally. The use case is relaying traffic from a device on the same Wi-Fi network to our server via the iPhone's cell socket. As such, we need it to work reliably when the screen is off and not freeze the network extension. Is there any way to prevent the device from sleeping and freezing our extension when the screen is off? Also, if sleep causes the extension to pause code execution, then how would system services like APNS or includeAllNetworks (which forces all traffic through the tunnel) even work?

Hello, We have a Network extension transparent proxy (NETransparentProxyProvider) that receives browser TCP flows as NEAppProxyTCPFlow. For each flow we create an NWConnection to the flow's original destination and set NEParameters.preferNoProxies = true - expecting the outbound connection to bypass the user's HTTP/HTTPS proxy and PAC so it goes to the destination server directly. However, in practice we see connections still being redirected to local proxy after being evaluated against the PAC rules using the destination IP and port. Our questions are: Could we expect preferNoProxies to be respected when a PAC exist on the endpoint and supersede the PAC rule decision? If yes, what would be the best way to file a bug and what information do you need? If not, is there any other way of making sure that the outbound NWConnection created by the transparent proxy is not redirected to a proxy and goes directly to the destination? One other way of avoiding our NWConnection being redirected to the proxy is to use hostname instead of destination IP. Would there be a reliable way of getting hostname for the NEAppProxyTCPFlow so that PAC can correctly filter all NWConnection based on rules? We have explored remoteHostname but it's generally not available for connections from browsers other than Safari.

Hi, I was wondering about eSIM on iOS devices. If they are older iOS devices, would they work the same as newer devices? Recently, there was a need to setup an iOS device and we opted for an eSIM with the carrier. The next day, it was having some issues with activation and had to resort to a physical SIM. Would this be fixed in the next version of iOS or is it a hardware related issue? Thank you

Is there any current documentation of Wide-Area Bonjour support in macOS? While the system-level defaults still seem to be the same, in the past there were bugs in the various HMAC and other authentication mechanisms for dynamic updates. Is there a source for current documentation?

There doesn't seem to be a What's New in Networking or What's New in Foundation talk this year, and nothing mentioned in the various Release Notes, so can you summarize the overall changes across platforms, or point to a document that does so?

iPad mini 6 with A15 supports WiFi6, but in a company's wifi environment, whose wireless infrastructure are WiFi7 AP's and enabled WPA3, iPad always stick to one AP even if I walked away, no matter how weak the signal is. Even if the AP kicked it off to let it roam to a new one because of low RSSI, it still reconnect the last AP, and being kicked again and again. For user experience, the kicking loop means an incountinous Internet experience. Forgetting the SSID and rejoining is the only solution, and there is still a chance that it tries to connect the weak AP after rejoined.

Will it continue to be the case that Wi-Fi details such as signal strength are only available via the 'Get Network Details' shortcut. Are there any changes here in iOS 27? Also, despite console logs showing that calls to Get Network Details produces a lot more details, only a restricted amount are exposed in the shortcut. In particular there is no channel bandwidth provided - is that purposeful or are there ways to access this detail.

There are cases where our VPN app would like to be able to send traffic inside the tunnel. It seems that when includeAllNetworks is set to true, there is no way to create a network socket (regardless of API, we've tried the unix socket API, Network framework by specifying the network interface and the deprecated Network Extension famework createTCPConnectionThroughTunnel) that works. Are there any plans to relieve us from having to ship a user space networking stack just to send some packets inside the tunnel from the packet tunnel process?

It was mentioned in the keynote that there are changes/improvements in the switching between Wi-Fi and cellular. Where can I find more details about the expected changes?

I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

Hello, We recently moved to the NWPath.Status implementation for reachability, is that the same reachability that powers URLSessionConfiguration.waitsForConnectivity? Or does the NWPath implementation rely on a specific network path such as cell only or wifi only? Is using NWPath still the best way to measure if the network is reachable? Thank you!

We have observed a per-process limitation on the number of simultaneous nw_connection_t objects in certain macOS environments. On some systems, this limit does not appear to apply, but on others the limitation is reproducible. When a process attempts to establish a large number of connections (e.g. 512+), some connections enter the nw_connection_state_waiting state and report the POSIX error “Cannot allocate memory”. These connections remain stuck indefinitely, even after other connections are deallocated and resources should theoretically be available again. This behavior severely impacts use cases such as transparent proxies implemented via the NetworkExtension framework, which intercept system-wide traffic and must open connections on behalf of all client processes. In this scenario, a per-process limit effectively becomes a system-wide limit, leading to unexpected and hard-to-diagnose network failures in client applications. Can we expect a relaxation of these restrictions for network extensions in the future? Could you please suggest some workarounds to bypass the restriction? By the way, now we have to fallback to BSD socket implementation of the outgoing connections, possibly braking the chain of TransparentProxies as the second proxy in the chain can’t get the originator of the intercepted flow (it sees the first proxy instead).

In iOS 27, there was mention of improved seamless WiFi/cell switching. Is my understanding correct that the phone is now more likely to switch to cellular when the signal from the WiFi access point is poor? Clarification on how this works would be appreciated.

Given the details are undocumented "feature" of VPN/networking (but shared by an engineer in a 1:1 lab at WWDC24) I'm not including details here. That said, it seems surprising that VPNs can suddenly disconnect overnight with no warning. Can this bug fix be prioritized during the iOS 27 cycle?

Thanks for being here! What is the behavior of this flag? The documentation is scant, to say the least.

When enforceRoutes = YES is set on a split tunnel VPN configuration containing only excluded routes, all traffic matching the included routes is silently dropped — no packets reach the VPN tunnel. Only the excluded routes route correctly via the physical adapter. Setting enforceRoutes = NO with an identical configuration restores full connectivity immediately, confirming the issue is specific to the combination of enforceRoutes = YES and a non-empty excludedRoutes. This has been verified on iPadOS 26. Test Environment Device: iPad pro 4th gen OS Version: iPadOS 26.0 VPN Type: NEPacketTunnelProvider VPN Configuration (NEPacketTunnelNetworkSettings) tunnelRemoteAddress = 103.135.123.108 DNSSettings = { protocol = cleartext server = (10.34.250.51) } IPv4Settings = { configMethod = manual addresses = (10.34.247.235) subnetMasks = (255.255.255.255) includedRoutes = ( { destinationAddress = 0.0.0.0 destinationSubnetMask = 0.0.0.0 } ) excludedRoutes = ( { destinationAddress = 10.168.10.182 destinationSubnetMask = 255.255.255.255 } ) overridePrimary = NO } MTU = 1400 enforceRoutes = YES includeAllNetworks = NO Reproduction Steps Configure NEPacketTunnelProvider with the settings above Set protocolConfiguration.enforceRoutes = YES Set protocolConfiguration.includeAllNetworks = NO Establish VPN connection and wait for Connected status Attempt to access any internet resource Observed Behavior Excluded route (10.168.10.182) correctly routes via physical adapter — confirmed in Wireshark Included routes (0.0.0.0/0) — zero packets visible in Wireshark on any interface, traffic completely dropped Internet fully inaccessible — no DNS responses, no TCP connections established Setting enforceRoutes = NO with an identical route configuration and all other settings unchanged restores full internet connectivity immediately. No other change is made.

We are investigating bridged Wi-Fi DHCP behavior on recent macOS releases and would appreciate some clarification regarding the net.link.bridge.use_dhcp_xid sysctl. We observed that with the default setting, DHCP packets transmitted from a virtual machine through a bridged Wi-Fi interface may have their DHCP client identity modified (chaddr). In our testing, setting: net.link.bridge.use_dhcp_xid=0 prevents this behavior and restores the DHCP packet format observed on older macOS versions. We would like to better understand the intended purpose of this sysctl: What functionality does net.link.bridge.use_dhcp_xid control internally? Besides DHCP chaddr rewriting, what other bridge or DHCP processing behavior is affected by this setting? Is this sysctl related to DHCP snooping, anti-spoofing protection, Wi-Fi bridging compatibility, or another mechanism? Is the current default behavior (use_dhcp_xid=1) a recent change introduced in macOS 26.4.x? Is the modified DHCP behavior considered expected and supported, or is it intended as an implementation detail? For additional context, we previously submitted feedback regarding DHCP handling for virtual machines using Virtualization Framework. Since packet modification is restricted from user space, we are wondering whether this sysctl is related to DHCP processing implemented by the bridge subsystem to address DHCP spoofing, client identification, or Wi-Fi bridging limitations. One concern we have is that net.link.bridge.use_dhcp_xid appears to be a system-wide setting. In our use case, DHCP handling requirements may differ between virtual machines, networks, and environments. As a result, changing a global bridge behavior for the entire host system is not always desirable. If this sysctl is intended to control DHCP processing for bridged virtual machines, would it be possible to expose similar functionality on a per-interface, per-bridge, or per-VM basis rather than as a host-wide setting? This would allow virtualization products to adapt DHCP behavior to specific network environments without affecting all bridged networking on the host. One additional question: Apple suggested making this setting persistent via /etc/sysctl.conf. However, this file does not exist by default on our macOS 26.4.x systems. Is /etc/sysctl.conf still a supported mechanism for persistent sysctl configuration, or is there a preferred modern alternative? Any documentation or implementation details that can be shared would be greatly appreciated.

Hello, Our app makes a lot of requests and we are starting to wrangle them into a priority queue style structure for ordered execution. As we get further into that work, is there guidance on how many requests URLSession will queue and does that change based on connectivity or network quality? Thank you!

Moin! Can you comment if anything of the happy eyeballs version 3 IETF draft ( https://datatracker.ietf.org/doc/draft-ietf-happy-happyeyeballs-v3/ ) is in the 27 version of OSes? So long -Ralf

A performance bottleneck we often hit is that we seem to be constrained by issuing a single sys call per packet. On platforms where vectored IO is supported, we can unlock 5x performance gains. Whilst we can read arrays of packets via the network extension API, the memory and concurrency model of that API seems to not be well documented, and I am not aware of any way to do vectored I/O on a UDP socket. Will we see an FFI friendly API for vectorised networking anytime soon? As an addendum - we are aware of sendmsg_x and recvmsg_x but we dare not ship an iOS app using those functions directly.