Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.

Hello, QQ for the Wi-Fi/Accessories team. Is the expectation that Wi-Fi Aware will work properly when the iPhone has Wi-Fi off either in settings or control center? I am able to reproduce errors where it does not work properly if the Wi-Fi on the phone is turned off. Please let me know best practices Using iPhone 17 pro on iOS 26.6

Development environment Xcode 26.0 Beta 6 iOS 26 Simulator macOS 15.6.1 To verify TLS 1.3 session resumption behavior in URLSession, I configured URLSessionConfiguration as follows and sent an HTTP GET request: let config = URLSessionConfiguration.ephemeral config.tlsMinimumSupportedProtocolVersion = .TLSv13 config.tlsMaximumSupportedProtocolVersion = .TLSv13 config.httpMaximumConnectionsPerHost = 1 config.httpAdditionalHeaders = ["Connection": "close"] config.enablesEarlyData = true let session = URLSession(configuration: config, delegate: nil, delegateQueue: nil) let url = URL(string: "https://www.google.com")! var request = URLRequest(url: url) request.assumesHTTP3Capable = true request.httpMethod = "GET" let task = session.dataTask(with: request) { data, response, error in if let error = error { print("Error during URLSession data task: \(error)") return } if let data = data, let responseString = String(data: data, encoding: .utf8) { print("Received data via URLSession: \(responseString)") } else { print("No data received or data is not UTF-8 encoded") } } task.resume() However, after capturing the packets, I found that the ClientHello packet did not include the early_data extension. It seems that enablesEarlyData on URLSessionConfiguration is not being applied. How can I make this work properly?

General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post URL filter: WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension URL filters documentation Filtering traffic by URL sample code Setting up a PIR server for URL filtering sample code Using the Bloom filter tool to configure a URL filter sample code PIR Service Example open source server sample and specifically its documentation Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Subject: Clarification Request – Private Relay and Silent Network Verification (SNV) Hello, Context: our app uses Silent Network Verification (SNV), the standard carrier method where the network recognizes a subscriber's connection to verify their identity without needing an SMS code. When a user has iCloud Private Relay enabled, the request path changes in a way that breaks this recognition, and the user falls back to OTP instead. We're evaluating an approach where the app would handle DNS resolution itself for this specific verification request, so the request stays on a path our network can recognize — without the user having to turn Private Relay off. Before we go further with this, we'd like clarity on two things: Would this kind of app-level DNS handling, used only for this verification step, be acceptable under the App Store Review Guidelines — or would it likely be treated as working around a user's privacy setting (for example under 2.5.1, 2.5.9, or 5.1.1)? If we added an explicit, transparent consent step in the app — telling the user we're bypassing Private Relay for this one request so they can be verified without an SMS code — would that change how this is viewed? We'd rather get this in writing from Apple than build against an assumption, and we'll need to share your response with our internal IT and compliance team, so a written reply would be genuinely helpful. Happy to provide more technical detail if useful. Thank you,

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

I want to know the right way/API/usage to use NWConnectionGroup to send both datagram and non-datagram stream. I am currently working on an P2P video streaming app. I want to leverage NWConnectionGroup over QUIC to handle both message channel (traditionally handled by a TCP connection) and media channel (traditionally handled by sth. over UDP) to transmit SRT packets back and forth. I created a NWConnectionGroup and it worked fine on non-datagram parts. The problems are with datagram part. I tried extracting a connection with datagram = true either from the group or from message, doesn't and in some cases it breaks other non-datagram connections. I currently send datagram directly using the NWConnectionGroup.send(content:completion). It kinda works but I keep seeing it canceled a lot of messages, which breaks SRT shortly after start. The warnings belong flooded my console. (Seems like want me to create a connection to transmit datagram, how?) nw_connection_create_with_connection [C1600] Original connection not yet connected nw_connection_group_create_connection_for_endpoint_and_parameters [G1] failed to create connection with parameters quic, local: fe80::439:68b4:6ec2:694%en0.60517, definite, attribution: developer, server I must use it in wrong way. What should I do to fix it?

model : iphone 17 ios version: 26.2 app used: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps Here is our observation when we tried to make wifi aware connection between iphone and our wifi device. note : we used iphone as subscriber ( view simulation) 1.pairing & bootstrapping was successfully done 2.Data path was successfully established between iphone and our device. after data path establishment ,within few seconds , DATA PATH TERMINATION was sent from iphone which leads to pairing verification with new NMI address. Same behaviour is noticed even when we try to establish connection between two iphone devices. Here we have few questions. Once we establish data path , Why iphone initiates data path termination instead using the same service for data path exchange. 2.Why do we go for PAIRING VERIFICATION everytime.

We have an iOS app (Alamofire 5.9+, backed by URLSession) that talks to a LAN dashcam: HTTP/1.1 TLS 1.2 The device runs an embedded C HTTPS server Responses commonly include Connection: close (a new TCP connection is opened for each request) From Wireshark, looking at Client Hello, we observe: First connection: full handshake; a Session ID is negotiated Next new TCP connection: Client Hello carries that Session ID and completes an abbreviated handshake (resumption succeeds) After that: the same Session ID is not reused again Questions we want to confirm For TLS 1.2 Session ID resumption (RFC 5246), does iOS / URLSession intentionally allow a cached session to be resumed at most once? Or can the same Session ID be resumed multiple times until it expires / is evicted from the cache? Without changing the overall LAN dashcam product model, how should the server be configured—e.g. moving to TLS 1.3 and/or HTTP/2—so that iOS clients can resume via Session Ticket and/or Session ID multiple times? What we have already ruled out / observed The client already uses a shared long-lived URLSession / Alamofire Session (we do not create a new session per request) The server often returns Connection: close, so each request uses a new TCP connection; we are discussing TLS session resumption across connections, not HTTP keep-alive We occasionally see TLS time of only ~10–20 ms, which suggests at least one successful session resumption has occurred

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) Sometimes we have observed that on starting the transparent proxy extension, the startProxy overridden delegate method(override func startProxy(options: [String : Any]?, completionHandler: @escaping (Error?) -> Void) {) in our AppProxyProvider class which is derived from NETransparentProxyProvider being called more than once for the same extension(pid). This leads to Over-resume of an object crash as we invoke setTunnelNetworkSettings inside the startProxy delegate. As this is controlled by the system, we are not sure why this delegate being called more than once sometimes even if we call the start TransparentProxy only once. Note that, this issue is seen only in Mac OS Tahoe. Apple Feedback ticket: FB21464147 (startProxy delegate for NETransparentProxyProvider class is being called twice for the same pid extension sometimes)

I've a iOT companion app, in which I'll connect to iOT's Wi-Fi and then communicate the device with APIs, for the above functionality we needed local network permission So we enabled neccessary keys in info.plist and at the time of App Launch we trigger local network permission using the following code info.plist <string>This app needs local network access permission to connect with your iOT device and customize its settings</string> <key>NSBonjourServices</key> <array> <string>_network-perm._tcp</string> <string>_network-perm._udp</string> </array> Network Permission Trigger Methods import Foundation import MultipeerConnectivity class NetworkPermissionManager: NSObject { static let shared = NetworkPermissionManager() private var session: MCSession? private var advertiser: MCNearbyServiceAdvertiser? private var browser: MCNearbyServiceBrowser? private var permissionCallback: ((String) -> Void)? func requestPermission(callback: @escaping (String) -> Void) { self.permissionCallback = callback do { let peerId = MCPeerID(displayName: UUID().uuidString) session = MCSession(peer: peerId, securityIdentity: nil, encryptionPreference: .required) session?.delegate = self advertiser = MCNearbyServiceAdvertiser( peer: peerId, discoveryInfo: nil, serviceType: "network-perm" ) advertiser?.delegate = self browser = MCNearbyServiceBrowser( peer: peerId, serviceType: "network-perm" ) browser?.delegate = self advertiser?.startAdvertisingPeer() browser?.startBrowsingForPeers() // Stop after delay DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { [weak self] in self?.stopAll() // If no error occurred until now, consider permission triggered self?.permissionCallback?("granted") self?.permissionCallback = nil } } catch { permissionCallback?("error: \(error.localizedDescription)") permissionCallback = nil } } func stopAll() { advertiser?.stopAdvertisingPeer() browser?.stopBrowsingForPeers() session?.disconnect() } } extension NetworkPermissionManager: MCSessionDelegate { func session(_: MCSession, peer _: MCPeerID, didChange _: MCSessionState) {} func session(_: MCSession, didReceive _: Data, fromPeer _: MCPeerID) {} func session(_: MCSession, didReceive _: InputStream, withName _: String, fromPeer _: MCPeerID) {} func session(_: MCSession, didStartReceivingResourceWithName _: String, fromPeer _: MCPeerID, with _: Progress) {} func session(_: MCSession, didFinishReceivingResourceWithName _: String, fromPeer _: MCPeerID, at _: URL?, withError _: Error?) {} } extension NetworkPermissionManager: MCNearbyServiceAdvertiserDelegate { func advertiser(_: MCNearbyServiceAdvertiser, didReceiveInvitationFromPeer _: MCPeerID, withContext _: Data?, invitationHandler: @escaping (Bool, MCSession?) -> Void) { invitationHandler(false, nil) } func advertiser(_: MCNearbyServiceAdvertiser, didNotStartAdvertisingPeer error: Error) { print("❌ Advertising failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } } extension NetworkPermissionManager: MCNearbyServiceBrowserDelegate { func browser(_: MCNearbyServiceBrowser, foundPeer _: MCPeerID, withDiscoveryInfo _: [String: String]?) {} func browser(_: MCNearbyServiceBrowser, lostPeer _: MCPeerID) {} func browser(_: MCNearbyServiceBrowser, didNotStartBrowsingForPeers error: Error) { print("❌ Browsing failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } }``` I want to satisfy this following cases but it's not working as expected # Case1 Working App launches --> trigger permission using above code --> user granted permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should return success response # Case2 Not working App launches --> trigger permission using above code --> user denied permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should throw an error I double checked the permission status in the app settings there also showing disabled state In my case case 2 is also return success, even though user denied the permission I got success response. I wonder why this happens the same above 2 cases working as expected in iOS 17.x versions

Hi, I’m using Network Framework to implement a UDP client via NWConnection, and I’m looking for clarification about the correct and fully safe shutdown procedure, especially regarding resource release. I have initiated some pending receive calls on the NWConnection (using receive). After calling connection.cancel(), do we need to wait for the cancellation of these pending receives? As mentioned in this thread, NWConnection retains references to the receive closures and releases them once they are called. If a receive closure holds a reference to the NWConnection itself, do we need to wait for these closures to be called to avoid memory leaks? Or, if there are no such retained references, we don't need to wait for the cancellation of the pending I/O and cancelled state for NWConnection?

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Hello Apple Developer Technical Support / Engineering Team, We are currently developing an iOS application that utilizes Wi-Fi Aware (NAN) for peer-to-peer data transfer between iOS devices. We are in the process of optimizing our data transmission performance and are evaluating the different data path configurations available. Specifically, we would like to understand the performance characteristics and throughput differences between the Real-Time mode and the Bulk mode in the iOS Wi-Fi Aware implementation. Could you please provide clarification on the following points? Maximum Throughput: Between Real-Time mode and Bulk mode, which one is designed to provide a higher maximum throughput for continuous data transfer?

Dear Apple: 1、We want to create a socket application using the C language interface on the WiFi Aware channel, utilizing native socket APIs such as socket, connect, bind, etc., to transmit data through the established WiFi Aware channel. However, we wrote a demo and tested it. On the iOS side, when initiating a socket connect, we received error code 65. We also used the IPv6 protocol. We would like to ask for help: Is it impossible to use native socket APIs for programming on the WiFi Aware channel? 2、If native sockets are not available, which interfaces are recommended for WiFi Aware communication on iOS? Thanks.

Filed as FB23904785 with pcaps, a mid-episode sysdiagnose, & a userspace test harness. Posting here because the behavior localizes to the receive-window computation in xnu & I'd value a sanity check from anyone who knows what changed in this area for 27. On 26A5378n (MacBook Air M2, RTL8156B 2.5GbE via the in-kernel AppleUSBNCM driver), TCP downloads on the wired interface intermittently drop to 6-10 Mbps for stretches of minutes to 40 minutes, then recover on their own. Wi-Fi on the same machine pulls 50-70 Mbps from the same servers in the same seconds. Packet captures show why: during these stretches the kernel advertises a 5,440-byte receive window from the first post-handshake ACK & doubles it on 1.000 s ± 0.01 s wall-clock boundaries, seven doublings in a row, in two separate connections started 6.5 minutes apart, while bytes-per-interval varied 16x. Byte-count triggers can't produce byte-rate-invariant timing; that's a clock. What I ruled out inside a live occurrence: SO_RCVBUF of 4 MB (getsockopt-verified; identical staircase, so it isn't autotuning), ECN on/off (three toggles, no change), both link_heuristics sysctls, the WAN (during one occurrence ICMP loss was WORSE on Wi-Fi, 20% vs 10%, yet Wi-Fi ran 5x faster), & the wire itself (0.1% retransmissions, ACK timestamp-echo p50 43 ms, zero zero-window advertisements). TCP_CONNECTION_INFO confirms the on-wire numbers: tcpi_rcv_wnd 10,880 at t=2 s against a 4 MB buffer that stays 97% empty, tcpi_srtt 41 ms. The throttled flow itself hit 32.7 Mbps at t=7 s once the staircase reached 347 KB, so path capacity was there the whole time. The signature resembles a receiver-side LEDBAT governor (RFC 9840 describes exposing a reduced window through the receive window; tcp_rledbat.c in published xnu clamps recwin for sockets flagged receive-background). Two things don't add up though. First, I ported the published tcp_rledbat.c to userspace & drove it with the exact packet timeline from my capture: no parameterization reproduces constant 2x steps on one-second boundaries, because every growth law in that file counts bytes or RTTs, not seconds. Second, kern.ipc.throttle_best_effort reads 1 on a clean boot of this beta with no sysctl.conf, no profiles, & no third-party launch items, while published xnu initializes it to 0. That switch arms the demotion of best-effort sockets to receive-background on interfaces that recently carried realtime-marked traffic. Questions: did the receive-window governor change in 27, & did the throttle_best_effort default flip intentionally? And is there a supported way to see which sockets carry SOF1_TRAFFIC_MGT_TCP_RECVBG at runtime, to pin down what's marking these flows? Happy to attach anything from the evidence set to the FB or run diagnostics on request; the fault reproduces several times a day here.

Version: MacOS 12.1 When I was using NETransparentProxyProvider, I overrive handleNewFlow, handleNewUDPFlow , and return true for some process, and then call - (void)openWithLocalEndpoint:(NWHostEndpoint *)localEndpoint completionHandler:(void (^)(NSError *error))completionHandler; at the beginning, work fine, buy sometime, when I visited qiye.163.com website, I often got an error when I do code below: - (void)writeData:(NSData *)data withCompletionHandler:(void (^)(NSError *error))completionHandler; Error Domain=NEAppProxyFlowErrorDomain Code=1 "The operation could not be completed because the flow is not connected" UserInfo={NSLocalizedDescription=The operation could not be completed because the flow is not connected , and the whole computer could not access the Internet , handleNewFlow and handleNewUDPFlow both are no longer called, unless I turn off the VPN. Turn off VPN and then Internet can be access

I'm building a HomeKit app that discovers Thread devices and visualizes the mesh topology. I can detect device roles (Router vs End Device via characteristic 0x0703) and identify Border Routers (via _meshcop._udp), but I cannot determine which Router is the parent of a given End Device. Any Thread device can act as a Router (a Nanoleaf bulb, an Eve plug, not just HomePods), and End Devices attach to these Routers as children. That parent-child relationship is what I'm trying to map, but there's no RLOC16, neighbor table, or parent identifier exposed through any available API. I've tested every path I can find. Here's what I've tried on a network with 44 Thread devices and 6 Border Routers: What works (partially) HAP Thread Management Service (0x0701) gives me the device role from characteristic 0x0703, the OpenThread version from 0x0706, and node capabilities from 0x0702. That's the complete set of characteristics on that service. None of them contain RLOC16, parent Router, or neighbor data. This service also only exists on HAP-native Thread devices. My 20 Matter-over-Thread devices (Aqara, Eve Door, SmartWings, Onvis S4) don't have it at all. MeshCoP Bonjour (_meshcop._udp) identifies Border Routers and the network name/Extended PAN ID. No topology data about other mesh nodes. What doesn't work ThreadNetwork framework (THClient) - retrieveAllCredentials() returns error Code 3 because the app can't access credentials stored by Apple Home. Even if it worked, THCredentials only contains network config (name, PAN ID, channel), not topology. Direct CoAP queries - Border Routers don't route traffic from WiFi to Thread management ports. Mesh-local addresses aren't reachable. No Thread NWInterface in Network.framework. Network.framework - No visibility into the Thread mesh from the WiFi side. The only remaining path I can see (but it's not practical) Matter cluster 0x0035 (Thread Network Diagnostics) appears to have exactly what I need: RLOC16, NeighborTable with isChild boolean, RouteTable. I haven't implemented this because it requires commissioning each device individually onto my app's own Matter fabric via Multi-Admin. That's 21 separate user-initiated pairing actions on my network. I can't ask end users to do that. The core issue Every Thread Router (whether it's a HomePod acting as a Border Router or a Nanoleaf bulb acting as a mesh Router) knows its own children and neighbors. The Border Routers also maintain route tables covering the mesh backbone. This data exists on the user's own devices but none of it is exposed to third-party apps. Even something minimal would help. HMAccessory already exposes matterNodeID as a cross-protocol identifier. Exposing RLOC16 the same way would be enough, since parent-child relationships are encoded in the address itself (ParentRLOC = ChildRLOC & 0xFC00). Has anyone found another approach I'm missing? Thanks in advance for any pointers.

We are using a Content Filter Network Extension to perform telemetry over the network activity of enterprise iOS devices. The filter itself is not blocking any connection. We encountered an issue where our Content Filter got stuck in a deadlock in the startFilter method of the NEFilterControlProvider. This resulted in a crash report where we see 64 threads stuck in the startFilter call. While the content filter was stuck in a deadlock, the device network connectivity was lost. We solved the deadlock issue coming from our logger, however, we would like to get a better understanding on the following points: What are the critical paths where a Content Filter can have a device wide impact on network connectivity? What is the behavior of the OS when the Content Filter is unresponsive (e.g. in startFilter, handle(Report), handleNewFlow)? Will it try to start the filter again? Force kill it ? We saw that startFilter was called multiple times in our crash reports whereas we expected it to be called only on vendor configuration changes. What is the lifecycle of the filter control provider and filter data provider ? When are the different methods like startFilter called ? We would like our Content Filter to never cause disruptions and implement a circuit breaker behavior in case any issue occurs. Do you have any recommendation on how to achieve this ?

Hi everyone, I'm experiencing a very unusual difference in WebRTC ICE behavior between an application installed directly from Xcode and the exact same application distributed through TestFlight. Environment iOS application using Google's official WebRTC framework Same iPhone/iPad Same iOS version Same cellular network Same TURN server Xcode Run configuration: Release Archive configuration: Release Configuration The following configuration works perfectly when the application is installed directly from Xcode: config.iceTransportPolicy = .all config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turn:turn.example.com:443?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "turns:turn.example.com:5349?transport=tcp" ], username: "username", credential: "<hidden>" ), RTCIceServer( urlStrings: [ "stun:stun.l.google.com:19302" ] ) ] Calls connect quickly on both Wi-Fi and cellular networks. Problem After uploading exactly the same application to TestFlight, behavior changes significantly on cellular networks. ICE gathering appears to spend a long time generating host/server-reflexive candidates before a usable relay candidate becomes available. As a result, connection establishment becomes much slower than the same Release build installed directly from Xcode. Temporary workaround The only configuration that currently behaves reliably in TestFlight is forcing relay-only with a single TURN UDP server: config.iceTransportPolicy = .relay config.continualGatheringPolicy = .gatherContinually config.iceCandidatePoolSize = 2 config.iceServers = [ RTCIceServer( urlStrings: [ "turn:turn.example.com:3478?transport=udp" ], username: "username", credential: "" ) ] This connects quickly and reliably on both Wi-Fi and cellular networks. My question Has anyone experienced different ICE gathering or candidate selection behavior between: a Release build installed directly from Xcode the same Release build distributed through TestFlight on the same device and network? Are there any known differences in networking, ICE gathering, or runtime behavior that could explain this? I'd appreciate any suggestions or similar experiences. Thanks!