So it seems the NetworkFramework is still not able to support Broastcast Mode am I correct? As soon as I switch broadcast mode to On in my game I receive console messages instead of receiving data. nw_path_evaluator_create_flow_inner failed NECP_CLIENT_ACTION_ADD_FLOW (null) evaluator parameters: udp, definite, server, attribution: developer, reuse local address, context: Default Network Context (private), proc: 2702288D-96FB-37DD-8610-A68CC526EA0F, local address: 0.0.0.0:20778 nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 1FB68D7E-7C9B-47B2-B6AC-E5710CD9C9CD [17: File exists] nw_endpoint_flow_setup_channel [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] failed to request add nexus flow nw_endpoint_flow_failed_with_error [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] already failing, returning nw_endpoint_handler_create_from_protocol_listener [C2 192.168.178.221:52716 failed channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] nw_endpoint_flow_pre_attach_protocols nw_connection_create_from_protocol_on_nw_queue [C2] Failed to create connection from listener nw_ip_channel_inbox_handle_new_flow nw_connection_create_from_protocol_on_nw_queue failed I won't be able to receive data which is a real shame, so I guess I am stuck with the lower level code: // Enable broadcast var enableBroadcast: Int32 = 1 if setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, &enableBroadcast, socklen_t(MemoryLayout<Int32>.size)) == -1 { let errorMessage = String(cString: strerror(errno)) throw UDPSocketError.cannotEnableBroadcast(errorMessage) }

I'm using NETransparentProxyProvider to intercept udp sockets using the method handleNewUDPFlow. An application may create a UDP socket and set the DONTFRAG using setsockopt method setsockopt(s, IPPROTO_IP, IP_DONTFRAG, &val, sizeof(val)) In this case, do I have option in this case, to get the connection settings inside the callback (void)handleNewUDPFlow:(NEAppProxyUDPFlow *)flow initialRemoteEndpoint:(NWEndpoint *)remoteEndpoint; So in this case, I would be able to create the outgoing socket with the exact same characteristics, after the original app socket got intercepted by my proxy provider ?

Sometimes when adding a VPN configuration, it just redirects to the Settings app and doesn’t continue with the rest of the configuration process like prompting for passcode. But it proceeds as normal after the 2nd or 3rd try. This issue is occurring on iOS 18.5 build 22F5068a but it has been a problem over several versions now. Feedback ID: FB17458055

Hello, Since the release of iOS 26.0, we are seeing DNS traffic being blocked from within our NEPacketTunnelExtension on some devices. We have not isolated exact reproduction steps, but DNS resolves successfully for a period of time after enabling "iCloud Private Relay" (varying from 1-day to 2-weeks), until it then fails as MDNSResponder then returns: mDNSResponder [Q37046] DetermineUnicastQuerySuppression: Query suppressed for <mask.hash: 'REDACTED'> Addr (blocked by policy) DNS resolution continues to fail for all domains with the above until the device is rebooted. The Packet Tunnel intentionally does not have a DNS server set and this occurs for traffic from the Extension yet off-tunnel, which needs resolution from the system DNS server (and this configuration works perfectly for a period of time before being "blocked by policy"). The following do not resolve the issue once DNS queries are being "blocked by policy" on affected devices: disconnecting then reconnecting the vpn; toggling airplane mode for 10+ seconds; switching connection between WiFi & cellular data; disabling iCloud Private Relay. We have currently only seen this on unmanaged devices running iOS 26.0 or 26.1 beta and with iCloud Private Relay enabled. We did not see this issue on iOS 16,17 nor 18. We also have not yet seen this when iCloud Private Relay is disabled nor on iOS 26.0.1, however we cannot confirm whether they too are also affected. Is there a known a bug with iOS 26.0 & 26.1 Beta 1 that could cause this? How can we prevent DNS requests from NEPacketTunnelExtension being sporadically "blocked by policy" until the device is rebooted? Many thanks in advance.

when i set the flag false to the usesClassicLoadingMode, then the application is getting crashed Ex: let config = URLSessionConfiguration.default if #available(iOS 18.4, *) { config.usesClassicLoadingMode = false } Crash log : *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x1f655c390' *** First throw call stack: (0x188ae52ec 0x185f69a7c 0x188b4f67c 0x1889fcb84 0x1889fc4f0 0x191393bc8 0x1889ec8a0 0x1889ec6e4 0x191393ad0 0x191344dac 0x191344b58 0x107cfa064 0x107ce36d0 0x191343fcc 0x1891b3b18 0x1892dae58 0x189235c60 0x18921e270 0x18921d77c 0x18921a8ac 0x107ce0584 0x107cfa064 0x107ce891c 0x107ce95d8 0x107ceabcc 0x107cf5894 0x107cf4eb0 0x212f51660 0x212f4e9f8) terminating due to uncaught exception of type NSException

I was exploring the scenarios where an NWListener or NWConnection can be invalidated or reclaimed by the OS itself. I came across the document TN2277: Networking and Multitasking, which discusses situations where iOS can reclaim the underlying socket descriptor. The document states: while the app is suspended the system may choose to reclaim resources out from underneath a network socket used by the app, thereby closing the network connection represented by that socket. From this, I understand that when the app is in a suspended state, the OS may reclaim the socket descriptor. My questions are: In what scenarios does the OS not reclaim the socket descriptor while the app is suspended, and in which cases does it reclaim it? When reclamation occurs, does the OS reclaim 'a' single NWListener/NWConnection, or does it reclaim 'all' NWListener/NWConnections opened by the application? Thanks.

I'm using Network framework for communication between devices. The first time I instantiate an NWBrowser, it will prompt the user with a popup that says: Allow &lt;app name&gt; to find devices on local networks? The problem is, once I upgraded from Xcode 15.4 to Xcode 16.4, the popup doesn't appear; it says in the debug window: nw_browser_fail_on_dns_error_locked [B1] nw_browser_dns_service_browse_callback failed: PolicyDenied(18,446,744,073,709,486,046) I do have the info.plist keys Privacy-Local Network Usage Description (NSLocalNetworkUsageDescription) and Bonjour Services (NSBonjourServices) so it's not that. Also, It still works on a real device. I think something changed with Xcode 16 that tightened the security on a simulator, or maybe disabled Network framework entirely. It's not the firewall on my computer because that is turned off. I'm using an M1 MacBook Pro.

We have a VPN application and we were required by the review team to change the text in the "Add VPN Configuration" dialog due to guideline 5.4.0 Legal: VPN Apps: make it clear to the user what data is being collected and how it will be used in the permission request. It appears that showing that information in the view preceding the VPN configuration adding attempt is no longer enough. However we haven't found any changes in the API allowing to change the text in the mentioned dialog. Is there a technical possibility to change the text in the add VPN configuration dialog? Thank you

I have an accessory which uses both Bluetooth and WiFi to communicate with the app. I am trying to migrate to Accessory Setup Kit. However, the API expects both the bluetooth identifiers and WIFI SSID or SSID prefix in the ASDiscoveryDescriptor. The problem is we only have the WIFI SSID after BLE pairing. Our current flow looks like this: Pair via BLE Connect via BLE Send a BLE command to request WIFI settings (SSID and password) (Each device has a different SSID and password) Connect to WI-FI hotspot by calling NEHotspotConfigurationManager applyConfiguration with the retrieved credentials. Is there a way to set the Wi-Fi SSID of an ASAccessory object after the initial setup? To use Accessory Setup Kit we would need something like this: Call Accessory Setup Kit with bluetooth identifiers in the descriptor, finish the setup and get ASAccessory object. Connect via BLE Send a BLE command to request WIFI settings (SSID and password) Set the SSID of the ASAccessory to the retrieved value. Connect to WI-FI hotspot by calling `NEHotspotConfigurationManager joinAccessoryHotspot. Thanks!

Hi, I observed some unexpected behavior and hope that someone can enlighten me as to what this is about: mDNSResponder prepends IP / network based default search domains that are checked before any other search domain. E.g. 0.1.168.192.in-addr.arpa. would be used for an interface with an address in the the 192.168.1.0/24 subnet. This is done for any configured non-link-local IP address. I tried to find any mention of an approach like this in RFCs but couldn't spot anything. Please note that this is indeed a search domain and different from reverse-DNS lookups. Example output of tcpdump for ping devtest: 10:02:13.850802 IP (tos 0x0, ttl 64, id 43461, offset 0, flags [none], proto UDP (17), length 92) 192.168.1.2.52319 &gt; 192.168.1.1.53: 54890+ [1au] A? devtest.0.1.168.192.in-addr.arpa. (64) I was able to identify the code that adds those default IP subnet based search domains but failed to spot any indication as to what this is about: https://github.com/apple-oss-distributions/mDNSResponder/blob/d5029b5/mDNSMacOSX/mDNSMacOSX.c#L4171-L4211 Does anyone here have an ideas as to what this might be about?

We have a requirement to create a production quality application that also acts as HTTPS server for certain communication. The preference is for the server to support HTTP/1.1, HTTP/2 and HTTP/3 communication asynchronously, though not mandatory to support all the HTTP versions. Wanted to get the guidance, on which stack should be used, that is most reliable and that gives the maximum long term compatibility, sustainability and reliability. What is the recommended 'in-built' or 'available by default' stack on Apple Platform ? For HTTPS on HTTP/1.1 with synchronous mode operations ? For HTTPS on HTTP/1.1 with asynchronous mode operations ? For HTTPS on HTTP/2 with synchronous mode operations ? For HTTPS on HTTP/2 with asynchronous mode operations ? For HTTPS on HTTP/3 with asynchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 with synchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 with asynchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 + HTTP/3 with asynchronous mode operations ? What the generally recommended server stack that a typical application uses whether 'in-built' or 'available by default on Apple ' or 'not-available by default on Apple' stack. From the available stacks , we tried to evaluate the below stacks: https://opensource.apple.com/projects/swiftnio/ : We understand that while it’s not preinstalled as part of Apple's OSes, it is an official Swift package supported by Apple and can easily be added to your project. At the moment it supports HTTP/1.1 and HTTP/2. The link https://github.com/apple/swift-nio/issues/1730says that HTTP/3 will get added in the future. Is there any other HTTPS stack (built-in or third-party) that is recommended to the used on Apple's platform ? Our application is expected to be working on macOS, iOS, iPadOS, tvOS and watchOS. We understand that macOS also includes Apache HTTPD server. As our application is not primarily a Web Server (and also supports other protocols both in client and server mode), it looks integrating HTTPS directly into the application using a lightweight HTTP library with SSL/TLS support is a better option, in place of Apache HTTPD. From the document we know that swift-nio uses BoringSSL (swift-nio-ssl) which is prepackaged along with the swift-nio library, and it does not use the default Secure Transport. What is the reason being not using Secure Transport ? Now does it become the responsibility of the application using swift-nio to take care of updating BoringSSL with the patches.

Macbook OS Version: macOS 14.7.3 (23H417) Mobile OS: iOS Mobile OS Version: iOS 18.6.2 Mobile Manufacturer: Apple Mobile Model: iPhone 12 Pro Max Page Type: vue vue Version: vue2 Packaging Method: Cloud Packaging Project Creation Method: HBuilderX Steps: The backend server is deployed on AWS in Japan with a Japanese IP. Packaging the APP in HBuilderX and publishing it to the Apple App Store were both successful. In a subsequent version, we planned to add a push notification feature and selected uniPush V2. Due to the separation of frontend and backend, the frontend APP implements functions such as registration, login, password change, page content display, and product lists through the server's RESTful APIs. Test colleagues reported that the APP could not load pages when used in Japan; however, it worked normally in China. In China: Pinging the server IP and domain from a MacBook was successful. Testing the API with Postman on a MacBook was successful. In Japan: Pinging the server IP and domain from a MacBook was successful. Testing the API with Postman on a MacBook failed with the error: HandshakeException: Connection terminated during handshake This appears to be an SSL communication failure. We tested the SSL certificate using www.ssllabs.com/ssltest and received an A+ rating. The certificate should not be an issue. we deselected uniPush V2, repackaged the APP, and uploaded it to TestFlight. The result remained the same: the APP content failed to load in Japan, while it worked normally in China. Expected Result: Access to the Japanese server APIs should work normally both in China and Japan. Actual Result: The APP content fails to load when used in Japan, but works normally in China.

Hi~ I implemented network filtering on iOS using NEFilterControlProvider and NEFilterDataProvider. However, I found that their usage is restricted when distributing through the App Store. Does ADEP-based distribution allow the use of NEFilterControlProvider and NEFilterDataProvider? In TN3134, it states that NEPacketTunnelProvider requires MDM. Should I assume that NEFilterControlProvider and NEFilterDataProvider also require MDM in the same way? Thanks

Hi, I’m trying to download a remote file in the background, but I keep getting a strange behaviour where URLSession download my file indefinitely during a few minutes, without calling urlSession(_:downloadTask:didFinishDownloadingTo:) until the download eventually times out. To find out that it’s looping, I’ve observed the total bytes written on disk by implementing urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:). Note that I can't know the size of the file. The server is not able to calculate the size. Below is my implementation. I create an instance of URLSession like this: private lazy var session: URLSession = { let configuration = URLSessionConfiguration.background(withIdentifier: backgroundIdentifier) configuration.isDiscretionary = false configuration.sessionSendsLaunchEvents = true return URLSession(configuration: configuration, delegate: self, delegateQueue: nil) }() My service is using async/await so I have implemented an AsyncThrowingStream : private var downloadTask: URLSessionDownloadTask? private var continuation: AsyncThrowingStream&lt;(URL, URLResponse), Error&gt;.Continuation? private var stream: AsyncThrowingStream&lt;(URL, URLResponse), Error&gt; { AsyncThrowingStream&lt;(URL, URLResponse), Error&gt; { continuation in self.continuation = continuation self.continuation?.onTermination = { @Sendable [weak self] data in self?.downloadTask?.cancel() } downloadTask?.resume() } } Then to start the download, I do : private func download(with request: URLRequest) async throws -&gt; (URL, URLResponse) { do { downloadTask = session.downloadTask(with: request) for try await (url, response) in stream { return (url, response) } throw NetworkingError.couldNotBuildRequest } catch { throw error } } Then in the delegate : public func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) { guard let response = downloadTask.response, downloadTask.error == nil, (response as? HTTPURLResponse)?.statusCode == 200 else { continuation?.finish(throwing: downloadTask.error) return } do { let documentsURL = try FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false) let savedURL = documentsURL.appendingPathComponent(location.lastPathComponent) try FileManager.default.moveItem(at: location, to: savedURL) continuation?.yield((savedURL, response)) continuation?.finish() } catch { continuation?.finish(throwing: error) } } I also tried to replace let configuration = URLSessionConfiguration.background(withIdentifier: backgroundIdentifier) by let configuration = URLSessionConfiguration.default and this time I get a different error at the end of the download: Task &lt;0457F755-9C52-4CFB-BDB2-F378D0C94912&gt;.&lt;1&gt; failed strict content length check - expected: 0, received: 530692, received (uncompressed): 0 Task &lt;0457F755-9C52-4CFB-BDB2-F378D0C94912&gt;.&lt;1&gt; finished with error [-1005] Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https:/&lt;host&gt;:8190/proxy?Func=downloadVideoByUrl&amp;SessionId=slufzwrMadvyJad8Lkmi9RUNAeqeq, NSErrorFailingURLKey=https://&lt;host&gt;:8190/proxy?Func=downloadVideoByUrl&amp;SessionId=slufzwrMadvyJad8Lkmi9RUNAeqeq, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDownloadTask &lt;0457F755-9C52-4CFB-BDB2-F378D0C94912&gt;.&lt;1&gt;" ), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDownloadTask &lt;0457F755-9C52-4CFB-BDB2-F378D0C94912&gt;.&lt;1&gt;, NSUnderlyingError=0x300d9a7c0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=&lt;CFData 0x302139db0 [0x1fcb1f598]&gt;{length = 16, capacity = 16, bytes = 0x10021ffe91e227500000000000000000}}}} The log "failed strict content length check” made me look into the response header, which has the following: content-length: 0 Content-Type: application/force-download Transfer-encoding: chunked Connection: KEEP-ALIVE Content-Transfer-Encoding: binary So it should be fine the way I setup my URLSession. The download works fine in Chrome/Safari/Chrome or Postman. My code used to work a couple of weeks before, so I expect something has changed on the server side, but I can’t find what, and I don’t get much help from the guys on the server side. Has anyone an idea of what’s going on?

Hi Everyone, I have a query regarding capturing an NWConnection instance inside the receive closure, which gets invoked whenever some raw bytes are received. I want to know whether this will create a strong retain cycle or not. My understanding is that NWConnection holds a reference to the closure, and if I capture the NWConnection instance inside the closure, the closure will have a reference back to the connection, which, according to my understanding, creates a strong reference cycle. Is my understanding correct? If so, how can we break the strong reference cycle — using a capture list, or is there any other way as well? Thanks

I’m developing an app designed for hospital environments, where public internet access may not be available. The app includes two components: the main app and a Local Connectivity Extension. Both rely on persistent TCP socket connections to communicate with a local server. We’re observing a recurring issue where the extension’s socket becomes unresponsive every 1–3 hours, but only when the device is on the lock screen, even if the main app remains in the foreground. When the screen is not locked, the connection is stable and no disconnections occur. ❗ Issue Details: • What’s going on: The extension sends a keep-alive ping packet every second, and the server replies with a pong and a system time packet. • The bug: The server stops receiving keep alive packets from the extension.  • On the server, we detect about 30 second gap on the server, a gap that shows no packets were received by the extension. This was confirmed via server logs and Wireshark).  • On the extension, from our logs there was no gap in sending packets. From it’s perspective, all packets were sent with no error.  • Because no packet are being received by the server, no packets will be sent to the extension. Eventually the server closes the connection due to keep-alive timeout.  • FYI we log when the NEAppPushProvider subclass sleeps and it did NOT go to sleep while we were debugging. 🧾 Example Logs: Extension log: 2025-03-24 18:34:48.808 sendKeepAliveRequest() 2025-03-24 18:34:49.717 sendKeepAliveRequest() 2025-03-24 18:34:50.692 sendKeepAliveRequest() ... // continuous sending of the ping packet to the server, no problems here 2025-03-24 18:35:55.063 sendKeepAliveRequest() 2025-03-24 18:35:55.063 keepAliveTimer IS TIME OUT... in CoreService. // this is triggered because we did not receive any packets from the server 2025-03-24 18:34:16.298 No keep-alive received for 16 seconds... connection ID=95b3... // this shows that there has been no packets being received by the extension ... 2025-03-24 18:34:30.298 Connection timed out on keep-alive. connection ID=95b3... // eventually closes due to no packets being received 2025-03-24 18:34:30.298 Remote Subsystem Disconnected {name=iPhone|Replica-Ext|...} ✅ Observations: • The extension process continues running and logging keep-alive attempts. • However, network traffic stops reaching the server, and no inbound packets are received by the extension. • It looks like the socket becomes silently suspended or frozen, without being properly closed or throwing an error. ❓Questions: • Do you know why this might happen within a Local Connectivity Extension, especially under foreground conditions and locked ? • Is there any known system behavior that might cause the socket to be suspended or blocked in this way after running for a few hours? Any insights or recommendations would be greatly appreciated. Thank you!

Hi Everyone, I’m working on a communication system for my app using NWConnection with the UDP protocol. The connection is registered to a custom serial dispatch queue. However, I’m trying to understand what the behavior will be in a scenario where the connection is canceled while there are still pending receive operations in progress. Scenario Overview: The sender is transmitting n = 100 packets to the receiver, out of which 40 packets have already been sent (i.e., delivered to the Receiver). The receiver has posted m = 20 pending receive operations, where each receive operation is responsible for handling one packet. The receiver has already successfully processed x = 10 packets. At the time of cancellation, the receiver’s buffer still holds m = 20 packets that are pending for processing, and k = 10 pending receive callbacks are in the dispatch queue, waiting to be executed. At same time when the 10th packet was processed another thread triggers .cancel() on this accepted NWConnection (on the receiver side), I need to understand the impact on the pending receive operations and their associated callbacks. My Questions: What happens to the k = 10 pending receive callbacks that are in the dispatch queue waiting to be triggered when the connection is canceled? Will these callbacks complete successfully and process the data? Or, because the connection is canceled, will they complete with failure? What happens to the remaining pending receive operations that were initiated but have not yet been scheduled in the dispatch queue? For the pending receive operations that were already initiated (i.e., the network stack is waiting to receive the data, but the callback hasn’t been scheduled yet), will they fail immediately when the connection is canceled? Or is there any chance that the framework might still process these receives before the cancellation fully takes effect?

I am running a full-tunnel VPN using a Packet Tunnel Provider. During VPN setup, we configure DNS setting with specific DNS servers for all domains to be used by the tunnel. However, our project requires DNS resolution for every domain from both the VPN-provided DNS servers and the ISP’s DNS servers. When I attempt to use c-ares or other third-party libraries to resolve domains via the ISP DNS servers, these libraries only detect and use the VPN DNS servers instead. As a result, all queries fail. Is there a way on iOS to programmatically determine the ISP DNS servers while a full-tunnel VPN is active, or a system API that allows DNS queries to be explicitly resolved using the ISP’s DNS servers?

I develop a terminal app with c++. Everything was fin until i upgraded to Sequoia. If i debug my program with Xcode, all requests to a local network like MQTT fails. How can i grant XCODE the privilege to access the local network?

I’m developing a iOS VPN app, and I need to execute a task in the main app even when it’s in the background or killed state. I know the Network Extension continues running during those times. Is there a way for the extension to immediately notify the app or trigger a task on the app side?