We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

I haven’t been able to get this to work at any level! I’m running into multiple issues, any light shed on any of these would be nice: I can’t implement a bloom filter that produces the same output as can be found in the SimpleURLFilter sample project, after following the textual description of it that’s available in the documentation. No clue what my implementation is doing wrong, and because of the nature of hashing, there is no way to know. Specifically: The web is full of implementations of FNV-1a and MurmurHash3, and they all produce different hashes for the same input. Can we get the proper hashes for some sample strings, so we know which is the “correct” one? Similarly, different implementations use different encodings for the strings to hash. Which should we use here? The formulas for numberOfBits and numberOfHashes give Doubles and assign them to Ints. It seems we should do this conversing by rounding them, is this correct? Can we get a sample correct value for the combined hash, so we can verify our implementations against it? Or ignoring all of the above, can we have the actual code instead of a textual description of it? 😓 I managed to get Settings to register my first attempt at this extension in beta 1. Now, in beta 2, any other project (including the sample code) will redirect to Settings, show the Allow/Deny message box, I tap Allow, and then nothing happens. This must be a bug, right? Whenever I try to enable the only extension that Settings accepted (by setting its isEnabled to true), its status goes to .stopped and the error is, of course, .unknown. How do I debug this? While the extension is .stopped, ALL URL LOADS are blocked on the device. Is this to be expected? (shouldFailClosed is set to false) Is there any way to manually reload the bloom filter? My app ships blocklist updates with background push, so it would be wasteful to fetch the filter at a fixed interval. If so, can we opt out of the periodic fetch altogether? I initially believed the API to be near useless because I didn’t know of its “fuzzy matching” capabilities, which I’ve discovered by accident in a forum post. It’d be nice if those were documented somewhere! Thanks!!

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?

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

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?

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