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

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?

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?

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?

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.

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.

Is the system default for this still false as of the OS 27 releases? When would you recommend setting it to true?

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.

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.

I created an App using PeerNetworking to connect two iOS-Devices without existing wifi-infrastructure. In general the solution works fine but when there are many other smart devices nearby connection gets unstable and breaks, devices have to be closer together or dont connect at all. In "Lab"-conditions everything works fine. What could I do to get the connection more stable and reliable?

I'd imagine that RCS messaging is part of the package of excluded services when excludeCellularServices is set to true. Is that accurate? Documentation

With iOS 27's improvements to seamless Wi-Fi/cellular transitions, is there guidance for apps and frameworks doing background network requests on how to handle a transition mid-request? Do in-flight URLSession tasks survive a network path change automatically, or should apps build their own retry logic?

When my URLSessionDelegate receives a server trust challenge (NSURLAuthenticationMethodServerTrust) and I respond with .useCredential for an enterprise self-signed cert, does the decision get cached for subsequent requests on the same URLSession, or is the delegate called again on every connection to the same host?

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, I filed feedback 22592307 around crashes my team and I are seeing in libquic now that we have adopted HTTP/3 for a large portion of our network usage. During the state of the union it was stated that libquic has been fully re-written in Swift by the WebKit team. Is that swift version the new implementation of libquic in iOS 27? If not, what will be the best way to adopt it without leaving the URLSession ecosystem?

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

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 2nd Gen 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

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

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?