General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals TN3111 iOS Wi-Fi API overview Wi-Fi Aware framework documentation Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post WirelessInsights framework documentation iOS Network Signal Strength forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

I would like to test running some Thread Networking code on my MacOS machine: import ThreadNetwork let client = THClient() let bIsPreferredAvailable = await client.isPreferredAvailable() but I get some errors when trying to create an instance of the THClient class: Client: -[THClient connectToXPCService]_block_invoke - CTCS XPC Client is interrupted. Client: -[THClient getConnectionEntitlementValidity]_block_invoke - clientProxyWithErrorHandler Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ThreadNetwork.xpc" UserInfo={NSDebugDescription=connection to service named com.apple.ThreadNetwork.xpc} Client: -[THClient init] - XPC Client Init Failed Invalidating XPC connection. Client: -[THClient getConnectionEntitlementValidity]_block_invoke - clientProxyWithErrorHandler Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ThreadNetwork.xpc" UserInfo={NSDebugDescription=connection to service named com.apple.ThreadNetwork.xpc} How can I get the code to run?

IMPORTANT The resume rate limiter is now covered by the official documentation. See Use background sessions efficiently within Downloading files in the background. So, the following is here purely for historical perspective. NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background. It works as follows: nsurlsessiond (the daemon that does all the background session work) maintains a delay value for your app. It doubles that delay every time it resumes (or relaunches) your app. It resets that delay to 0 when the user brings your app to the front. It also resets the delay to 0 if the delay period elapses without it having resumed your app. When your app creates a new task while it is in the background, the task does not start until that delay has expired. To understand the impact of this, consider what happens when you download 10 resources. If you pass them to the background session all at once, you see something like this: Your app creates tasks 1 through 10 in the background session. nsurlsessiond starts working on the first few tasks. As tasks complete, nsurlsessiond starts working on subsequent ones. Eventually all the tasks complete and nsurlsessiond resumes your app. Now consider what happens if you only schedule one task at a time: Your app creates task 1. nsurlsessiond starts working on it. When it completes, nsurlsessiond resumes your app. Your app creates task 2. nsurlsessiond delays the start of task 2 a little bit. nsurlsessiond starts working on task 2. When it completes, nsurlsessiond resumes your app. Your app creates task 3. nsurlsessiond delays the start of task 3 by double the previous amount. nsurlsessiond starts working on task 3. When it completes, nsurlsessiond resumes your app. Steps 8 through 11 repeat, and each time the delay doubles. Eventually the delay gets so large that it looks like your app has stopped making progress. If you have a lot of tasks to run then you can mitigate this problem by starting tasks in batches. That is, rather than start just one task in step 1, you would start 100. This only helps up to a point. If you have thousands of tasks to run, you will eventually start seeing serious delays. In that case it’s much better to change your design to use fewer, larger transfers. Note All of the above applies to iOS 8 and later. Things worked differently in iOS 7. There’s a post on DevForums that explains the older approach. Finally, keep in mind that there may be other reasons for your task not starting. Specifically, if the task is flagged as discretionary (because you set the discretionary flag when creating the task’s session or because the task was started while your app was in the background), the task may be delayed for other reasons (low power, lack of Wi-Fi, and so on). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" (r. 22323366)

Hi there, We are facing some issues regarding TLS connectivity: Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour. We have not found a workaround for this problem. We've tryied those solutions without success: Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc. Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail. Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData. Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates" The most critical part seems to be the line sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does. I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled: func startConnection(host: String, port: UInt16) { self.queue = DispatchQueue(label: "socketQueue") let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) let parameters = NWParameters(tls: tlsOptions) self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters) self.nwConnection.stateUpdateHandler = { [weak self] state in switch state { case .setup: break case .waiting(let error): self?.connectionDidFail(error: error) case .preparing: break case .ready: self?.didConnectSubject.onNext(Void()) case .failed(let error): self?.connectionDidFail(error: error) case .cancelled: self?.didDisconnectSubject.onNext(nil) @unknown default: break } } self.setupReceive() self.nwConnection.start(queue: queue) } These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode: 🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP 🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821 nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel 🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.

I have an issue that causes multiple instances of the push provider to be initialized. And I'd like to ask you what could trigger the instantiation NEAppPushProvider subclass. It seems like it's being triggered excessively. If there's documentation that I have overlooked then just show it to me and I'll be on my way. Here's the details. But really all I want to know is why is my subclass for NEAppPushProvider keeps getting initialized. If you can answer me that than maybe all these details don't really matter but here they are. Here's why I believe there's multiple push provider. I see logs for my push provider initializing but I don't see it de-initializing. I also see redundant logs showing multiple instances trying to log into my server. Each time it initializes, an additional log is added for trying to log into my server. In the app, the system saves it's configuration shortly after initialization, after saving and loading the push configuration, the app doesn't touch config. Meanwhile in the extension, after 8 or so hours, the extension starts creating a new instance of the push provider. Then a few hours later it does it again. And again. Until the watch dog kills us for wasting too much CPU. Normally on a fresh install, I'll observe turning off the wifi to call stop on the push provider and later have the push provider de-initialize. The extension maintains a socket connection to the server, the server can send it messages to display push notifications. The software runs on hospital networks, which will not have access to the internet. It seems like the connection to the server is stable from the logs. I don't detect any disconnections. I'll check with the server to confirm. In the app I call removeFromPreferences to clear out any extensions before logging in/saving push configurations. And I call saveToPreferences on the NEAppPushManager. I do this to make sure I don't have more than one push configuration saved at one time. I also have many logs looking out for this. I used the sample code from apple as the basis of the my own Push Manager. I can post code if you deem it necessary. Hope to here from you soon. Thank you.

In order to create a Message Filter Extension it is necessary to set up Shared Web Credentials. I'd like to form an understanding of what role SWC plays when the OS is making request to the associated network service (when the extension has called deferQueryRequestToNetwork()) and how this differs from when an app directly uses Shared Web Credentials itself. When an app is making direct use of SWC, it makes a request to obtain the user's credentials from the web site. However in the case of a Message Filter Extension, there aren't any individual user credentials, so what is happening behind the scenes when the OS makes a server request on behalf of a Message Filtering Extension? A more general question - the documentation for Shared Web Credentials says "Associated domains establish a secure association between domains and your app.". Thank you

This issue has cropped up many times here on DevForums. Someone recently opened a DTS tech support incident about it, and I used that as an opportunity to post a definitive response here. If you have questions or comments about this, start a new thread and tag it with Network so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" iOS Network Signal Strength The iOS SDK has no general-purpose API that returns Wi-Fi or cellular signal strength in real time. Given that this has been the case for more than 10 years, it’s safe to assume that it’s not an accidental omission but a deliberate design choice. For information about the Wi-Fi APIs that are available on iOS, see TN3111 iOS Wi-Fi API overview. Network performance Most folks who ask about this are trying to use the signal strength to estimate network performance. This is a technique that I specifically recommend against. That’s because it produces both false positives and false negatives: The network signal might be weak and yet your app has excellent connectivity. For example, an iOS device on stage at WWDC might have terrible WWAN and Wi-Fi signal but that doesn’t matter because it’s connected to the Ethernet. The network signal might be strong and yet your app has very poor connectivity. For example, if you’re on a train, Wi-Fi signal might be strong in each carriage but the overall connection to the Internet is poor because it’s provided by a single over-stretched WWAN. The only good way to determine whether connectivity is good is to run a network request and see how it performs. If you’re issuing a lot of requests, use the performance of those requests to build a running estimate of how well the network is doing. Indeed, Apple practices what we preach here: This is exactly how HTTP Live Streaming works. Remember that network performance can change from moment to moment. The user’s train might enter or leave a tunnel, the user might step into a lift, and so on. If you build code to estimate the network performance, make sure it reacts to such changes. Keeping all of the above in mind, iOS 26 beta has two new APIs related to this issue: Network framework now offers a linkQuality property. See this post for my take on how to use this effectively. The WirelessInsights framework can notify you of anticipated WWAN condition changes. But what about this code I found on the ’net? Over the years various folks have used various unsupported techniques to get around this limitation. If you find code on the ’net that, say, uses KVC to read undocumented properties, or grovels through system logs, or walks the view hierarchy of the status bar, don’t use it. Such techniques are unsupported and, assuming they haven’t broken yet, are likely to break in the future. But what about Hotspot Helper? Hotspot Helper does have an API to read Wi-Fi signal strength, namely, the signalStrength property. However, this is not a general-purpose API. Like the rest of Hotspot Helper, this is tied to the specific use case for which it was designed. This value only updates in real time for networks that your hotspot helper is managing, as indicated by the isChosenHelper property. But what about MetricKit? MetricKit is so cool. Amongst other things, it supports the MXCellularConditionMetric payload, which holds a summary of the cellular conditions while your app was running. However, this is not a real-time signal strength value. But what if I’m working for a carrier? This post is about APIs in the iOS SDK. If you’re working for a carrier, discuss your requirements with your carrier’s contact at Apple. Revision History 2025-07-02 Updated to cover new features in the iOS 16 beta. Made other minor editorial changes. 2022-12-01 First posted.

Continuing with my investigations of several issues that we have been noticing in our testing of the JDK with macosx 15.x, I have now narrowed down at least 2 separate problems for which I need help. For a quick background, starting with macosx 15.x several networking related tests within the JDK have started failing in very odd and hard to debug ways in our internal lab. Reading through the macos docs and with help from others in these forums, I have come to understand that a lot of these failures are to do with the new restrictions that have been placed for "Local Network" operations. I have read through https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy and I think I understand the necessary background about these restrictions. There's more than one issue in this area that I will need help with, so I'll split them out into separate topics in this forum. That above doc states: macOS 15.1 fixed a number of local network privacy bugs. If you encounter local network privacy problems on macOS 15.0, retest on macOS 15.1 or later. We did have (and continue to have) 15.0 and 15.1 macos instances within our lab which are impacted by these changes. They too show several networking related failures. However, I have decided not to look into those systems and instead focus only on 15.3.1. People might see unexpected behavior in System Settings > Privacy & Security if they have multiple versions of the same app installed (FB15568200). This feedback assistant issue and several others linked in these documentations are inaccessible (even when I login with my existing account). I think it would be good to have some facility in the feedback assistant tool/site to make such issues visible (even if read-only) to be able to watch for updates to those issues. So now coming to the issue. Several of the networking tests in the JDK do mulicasting testing (through BSD sockets API) in order to test the Java SE multicasting socket API implementations. One repeated failure we have been seeing in our labs is an exception with the message "No route to host". It shows up as: Process id: 58700 ... java.net.NoRouteToHostException: No route to host at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method) at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798) at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857) at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178) at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593) (this is just one example stacktrace from java program) That "send0" is implemented by the JDK by invoking the sendto() system call. In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application. The forum text editor doesn't allow me to post long text, so I'm going to post the rest of this investigation and logs as a reply.

My external device can generate a fixed Wi-Fi network. When I connect to this Wi-Fi using my iPhone 17 Pro Max (iOS version 26.0.1), and my app tries to establish a connection using the following method, this method returns -1 int connect(int, const struct sockaddr *, socklen_t) __DARWIN_ALIAS_C(connect); However, when I use other phones, such as iPhone 12, iPhone 8, iPhone 11, etc., to connect to this external device, the above method always returns successfully, with the parameters passed to the method remaining the same. I also tried resetting the network settings on the iPhone 17 Pro Max (iOS version 26.0.1), but it still cannot establish a connection.

Hello, I'm working on a Transparent Proxy and when the proxy is being stopped, I'm stopping all the flows by calling flow.closeWriteWithError(POSIXError(.ECANCELED)) flow.closeReadWithError(POSIXError(.ECANCELED)) Then all the flows are deallocated. When deallocating the flow the crash occurs: OS Version: macOS 14.1.2 (23B92) Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000018c2ef704 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [553] Thread 32 Crashed:: Dispatch queue: <my dispatch queue> 0 CoreFoundation 0x18c2ef704 CF_IS_OBJC + 76 1 CoreFoundation 0x18c23f61c CFErrorGetDomain + 32 2 libnetworkextension.dylib 0x19fe56a00 flow_error_to_errno + 28 3 libnetworkextension.dylib 0x19fe56920 flow_handle_pending_write_requests + 216 4 libnetworkextension.dylib 0x19fe5667c __NEFlowDeallocate + 380 5 CoreFoundation 0x18c2efe28 _CFRelease + 292 6 NetworkExtension 0x19d208390 -[NEAppProxyFlow dealloc] + 36 Is there any way to debug what is happening and if it's related to closing the flow with POSIXError? Thank you

Hi, We're hoping someone can help us determine why we're running into some odd behavior where a simple HTTP request is intermittently failing with error code NSURLErrorTimedOut (-1001) Background: HTTP request details: The request is sent from a PacketTunnelProvider and is meant to be a Captive Portal check. The request is insecure (HTTP, instead of HTTPS) but we have configured App Transport Security (ATS) to allow insecure HTTP loads from this hostname. See info.plist excerpt below. The request is sent using NSMutableURLRequest/NSURLSessionDataTask using an Ephemeral session configuration. We only modify 2 properties on NSMutableURLRequest The timeoutInterval property is set to 5 seconds. The allowsCellularAccess property is set to NO. No headers or other configuration are modified. NSURLSessionDataTask completionHandler receives an NSError: We checked the NSError's userInfo dictionary for an underlying error (NSUnderlyingErrorKey). The underlying error shows the same code NSURLErrorTimedOut (-1001). We haven't seen any underlying errors with code NSURLErrorAppTransportSecurityRequiresSecureConnection (-1022) . On a laptop, we confirmed that the Captive portal check site is accessible and loads correctly. Laptop and iOS device are on the same Wi-fi. I've witnessed the error in the debugger, and been able to load the site on my laptop at the same time. So, we don't have any reason to believe this is server related. The PacketTunnelProvider is configured to only handle DNS queries and is not intercepting/routing the HTTP traffic. The DNS query for the Captive portal request is handled correctly. In fact, outside of the PacketTunnelProvider, all sites load in Mobile Safari. So, we're not breaking internet on this device. In other words, we have no reason to believe our DNS handling is interfering with the HTTP request since other HTTP requests are working as expected. We setup CFNetwork Diagnostic Logging (https://developer.apple.com/documentation/network/debugging-https-problems-with-cfnetwork-diagnostic-logging) In console.app, we are able to find some logging on the Timeout See excerpt from Console.app's log below. We confirmed that the nscurl tool did not flag the request (https://developer.apple.com/documentation/security/identifying-the-source-of-blocked-connections) All ATS tests run with nscurl were successful. See nscurl command used below. Questions: What are next steps to debug this intermittent timeout? What should we look for in the CFNetwork Diagnostic Logging to help debug the issue further? Thanks in advance for your help! ATS configuration setup in both the UI and the PacketTunnel's info.plist file: <key>NSAppTransportSecurity</key> <dict> <key>NSExceptionDomains</key> <dict> <key>subdomain.subdomain.example.com</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> Excerpt from Console.app's log: CFNetwork Example PacketTunnel 10836 Diagnostics default 11:30:33.029032-0700 CFNetwork Diagnostics [3:834] 11:30:32.946 { Did Timeout: (null) Loader: request GET http://subdomain.subdomain.example.com/content/cpcheck.txt HTTP/1.1 Timeout Interval: 5.000 seconds init to origin load: 0.000592947s total time: 5.00607s total bytes: 0 } [3:834] nscurl command $ /usr/bin/nscurl --ats-diagnostics --verbose http://subdomain.subdomain.example.com/content/cpcheck.txt

General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code 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 Wi-Fi management: Wi-Fi Fundamentals forums post TN3111 iOS Wi-Fi API overview technote How to modernize your captive network developer news post iOS Network Signal Strength forums post See also Networking Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm using NERelayManager to set Relay configuration which all works perfectly fine. I then do a curl with the included domain and while I see QUIC connection succeeds with relay server and H3 request goes to the server, the connection gets abruptly closed by the client with "Software caused connection abort". Console has this information: default 09:43:04.459517-0700 curl nw_flow_connected [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] Transport protocol connected (quic) default 09:43:04.459901-0700 curl [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:finish_transport @0.131s default 09:43:04.460745-0700 curl nw_flow_connected [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] Joined protocol connected (http3) default 09:43:04.461049-0700 curl [C1.1.1 192.168.4.197:4433 in_progress socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:finish_transport @0.133s default 09:43:04.465115-0700 curl [C2 E47A3A0C-7275-4F6B-AEDF-59077ABAE34B 192.168.4.197:4433 quic, multipath service: 1, tls, definite, attribution: developer] cancel default 09:43:04.465238-0700 curl [C2 E47A3A0C-7275-4F6B-AEDF-59077ABAE34B 192.168.4.197:4433 quic, multipath service: 1, tls, definite, attribution: developer] cancelled [C2 FCB1CFD1-4BF9-4E37-810E-81265D141087 192.168.4.139:53898<->192.168.4.197:4433] Connected Path: satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi Duration: 0.121s, QUIC @0.000s took 0.000s, TLS 1.3 took 0.111s bytes in/out: 2880/4322, packets in/out: 4/8, rtt: 0.074s, retransmitted bytes: 0, out-of-order bytes: 0 ecn packets sent/acked/marked/lost: 3/1/0/0 default 09:43:04.465975-0700 curl nw_flow_disconnected [C2 192.168.4.197:4433 cancelled multipath-socket-flow ((null))] Output protocol disconnected default 09:43:04.469189-0700 curl nw_endpoint_proxy_receive_report [C1.1 IPv4#124bdc4d:80 in_progress proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, proxy, uses wifi)] Privacy proxy failed with error 53 ([C1.1.1] masque Proxy: http://192.168.4.197:4433) default 09:43:04.469289-0700 curl [C1.1.1 192.168.4.197:4433 failed socket-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] event: flow:failed_connect @0.141s, error Software caused connection abort Relay server otherwise works fine with our QUIC MASQUE clients but not with built-in macOS MASQUE client. Anything I'm missing?

Transport Layer Security (TLS) is the most important security protocol on the Internet today. Most notably, TLS puts the S into HTTPS, adding security to the otherwise insecure HTTP protocol. IMPORTANT TLS is the successor to the Secure Sockets Layer (SSL) protocol. SSL is no longer considered secure and it’s now rarely used in practice, although many folks still say SSL when they mean TLS. TLS is a complex protocol. Much of that complexity is hidden from app developers but there are places where it’s important to understand specific details of the protocol in order to meet your requirements. This post explains the fundamentals of TLS, concentrating on the issues that most often confuse app developers. Note The focus of this is TLS-PKI, where PKI stands for public key infrastructure. This is the standard TLS as deployed on the wider Internet. There’s another flavour of TLS, TLS-PSK, where PSK stands for pre-shared key. This has a variety of uses, but an Apple platforms we most commonly see it with local traffic, for example, to talk to a Wi-Fi based accessory. For more on how to use TLS, both TLS-PKI and TLS-PSK, in a local context, see TLS For Accessory Developers. Server Certificates For standard TLS to work the server must have a digital identity, that is, the combination of a certificate and the private key matching the public key embedded in that certificate. TLS Crypto Magic™ ensures that: The client gets a copy of the server’s certificate. The client knows that the server holds the private key matching the public key in that certificate. In a typical TLS handshake the server passes the client a list of certificates, where item 0 is the server’s certificate (the leaf certificate), item N is (optionally) the certificate of the certificate authority that ultimately issued that certificate (the root certificate), and items 1 through N-1 are any intermediate certificates required to build a cryptographic chain of trust from 0 to N. Note The cryptographic chain of trust is established by means of digital signatures. Certificate X in the chain is issued by certificate X+1. The owner of certificate X+1 uses their private key to digitally sign certificate X. The client verifies this signature using the public key embedded in certificate X+1. Eventually this chain terminates in a trusted anchor, that is, a certificate that the client trusts by default. Typically this anchor is a self-signed root certificate from a certificate authority. Note Item N is optional for reasons I’ll explain below. Also, the list of intermediate certificates may be empty (in the case where the root certificate directly issued the leaf certificate) but that’s uncommon for servers in the real world. Once the client gets the server’s certificate, it evaluates trust on that certificate to confirm that it’s talking to the right server. There are three levels of trust evaluation here: Basic X.509 trust evaluation checks that there’s a cryptographic chain of trust from the leaf through the intermediates to a trusted root certificate. The client has a set of trusted root certificates built in (these are from well-known certificate authorities, or CAs), and a site admin can add more via a configuration profile. This step also checks that none of the certificates have expired, and various other more technical criteria (like the Basic Constraints extension). Note This explains why the server does not have to include the root certificate in the list of certificates it passes to the client; the client has to have the root certificate installed if trust evaluation is to succeed. In addition, TLS trust evaluation (per RFC 2818) checks that the DNS name that you connected to matches the DNS name in the certificate. Specifically, the DNS name must be listed in the Subject Alternative Name extension. Note The Subject Alternative Name extension can also contain IP addresses, although that’s a much less well-trodden path. Also, historically it was common to accept DNS names in the Common Name element of the Subject but that is no longer the case on Apple platforms. App Transport Security (ATS) adds its own security checks. Basic X.509 and TLS trust evaluation are done for all TLS connections. ATS is only done on TLS connections made by URLSession and things layered on top URLSession (like WKWebView). In many situations you can override trust evaluation; for details, see Technote 2232 HTTPS Server Trust Evaluation). Such overrides can either tighten or loosen security. For example: You might tighten security by checking that the server certificate was issued by a specific CA. That way, if someone manages to convince a poorly-managed CA to issue them a certificate for your server, you can detect that and fail. You might loosen security by adding your own CA’s root certificate as a trusted anchor. IMPORTANT If you rely on loosened security you have to disable ATS. If you leave ATS enabled, it requires that the default server trust evaluation succeeds regardless of any customisations you do. Mutual TLS The previous section discusses server trust evaluation, which is required for all standard TLS connections. That process describes how the client decides whether to trust the server. Mutual TLS (mTLS) is the opposite of that, that is, it’s the process by which the server decides whether to trust the client. Note mTLS is commonly called client certificate authentication. I avoid that term because of the ongoing industry-wide confusion between certificates and digital identities. While it’s true that, in mTLS, the server authenticates the client certificate, to set this up on the client you need a digital identity, not a certificate. mTLS authentication is optional. The server must request a certificate from the client and the client may choose to supply one or not (although if the server requests a certificate and the client doesn’t supply one it’s likely that the server will then fail the connection). At the TLS protocol level this works much like it does with the server certificate. For the client to provide this certificate it must apply a digital identity, known as the client identity, to the connection. TLS Crypto Magic™ assures the server that, if it gets a certificate from the client, the client holds the private key associated with that certificate. Where things diverge is in trust evaluation. Trust evaluation of the client certificate is done on the server, and the server uses its own rules to decided whether to trust a specific client certificate. For example: Some servers do basic X.509 trust evaluation and then check that the chain of trust leads to one specific root certificate; that is, a client is trusted if it holds a digital identity whose certificate was issued by a specific CA. Some servers just check the certificate against a list of known trusted client certificates. When the client sends its certificate to the server it actually sends a list of certificates, much as I’ve described above for the server’s certificates. In many cases the client only needs to send item 0, that is, its leaf certificate. That’s because: The server already has the intermediate certificates required to build a chain of trust from that leaf to its root. There’s no point sending the root, as I discussed above in the context of server trust evaluation. However, there are no hard and fast rules here; the server does its client trust evaluation using its own internal logic, and it’s possible that this logic might require the client to present intermediates, or indeed present the root certificate even though it’s typically redundant. If you have problems with this, you’ll have to ask the folks running the server to explain its requirements. Note If you need to send additional certificates to the server, pass them to the certificates parameter of the method you use to create your URLCredential (typically init(identity:certificates:persistence:)). One thing that bears repeating is that trust evaluation of the client certificate is done on the server, not the client. The client doesn’t care whether the client certificate is trusted or not. Rather, it simply passes that certificate the server and it’s up to the server to make that decision. When a server requests a certificate from the client, it may supply a list of acceptable certificate authorities [1]. Safari uses this to filter the list of client identities it presents to the user. If you are building an HTTPS server and find that Safari doesn’t show the expected client identity, make sure you have this configured correctly. If you’re building an iOS app and want to implement a filter like Safari’s, get this list using: The distinguishedNames property, if you’re using URLSession The sec_protocol_metadata_access_distinguished_names routine, if you’re using Network framework [1] See the certificate_authorities field in Section 7.4.4 of RFC 5246, and equivalent features in other TLS versions. Self-Signed Certificates Self-signed certificates are an ongoing source of problems with TLS. There’s only one unequivocally correct place to use a self-signed certificate: the trusted anchor provided by a certificate authority. One place where a self-signed certificate might make sense is in a local environment, that is, securing a connection between peers without any centralised infrastructure. However, depending on the specific circumstances there may be a better option. TLS For Accessory Developers discusses this topic in detail. Finally, it’s common for folks to use self-signed certificates for testing. I’m not a fan of that approach. Rather, I recommend the approach described in QA1948 HTTPS and Test Servers. For advice on how to set that up using just your Mac, see TN2326 Creating Certificates for TLS Testing. TLS Standards RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 (historic) RFC 2246 The TLS Protocol Version 1.0 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 RFC 4347 Datagram Transport Layer Security RFC 6347 Datagram Transport Layer Security Version 1.2 RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History: 2025-11-21 Clearly defined the terms TLS-PKI and TLS-PSK. 2024-03-19 Adopted the term mutual TLS in preference to client certificate authentication throughout, because the latter feeds into the ongoing certificate versus digital identity confusion. Defined the term client identity. Added the Self-Signed Certificates section. Made other minor editorial changes. 2023-02-28 Added an explanation mTLS acceptable certificate authorities. 2022-12-02 Added links to the DTLS RFCs. 2022-08-24 Added links to the TLS RFCs. Made other minor editorial changes. 2022-06-03 Added a link to TLS For Accessory Developers. 2021-02-26 Fixed the formatting. Clarified that ATS only applies to URLSession. Minor editorial changes. 2020-04-17 Updated the discussion of Subject Alternative Name to account for changes in the 2019 OS releases. Minor editorial updates. 2018-10-29 Minor editorial updates. 2016-11-11 First posted.

Our application uses NEFilterPacketProvider to filter network traffic and we sometimes get a wired crash when removing/updating the network extension. It only happens on MacOS 11-12 . The crashing thread is always this one and it shows up after I call the completionHandler from the stopFilter func Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object Thread 6 Crashed:: Dispatch queue: com.apple.network.connections 0 libdispatch.dylib 0x00007fff2039cc35 _dispatch_queue_xref_dispose.cold.1 + 24 1 libdispatch.dylib 0x00007fff20373808 _dispatch_queue_xref_dispose + 50 2 libdispatch.dylib 0x00007fff2036e2eb -[OS_dispatch_source _xref_dispose] + 17 3 libnetwork.dylib 0x00007fff242b5999 __nw_queue_context_create_source_block_invoke + 41 4 libdispatch.dylib 0x00007fff2036d623 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff2036e806 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff203711b0 _dispatch_continuation_pop + 423 7 libdispatch.dylib 0x00007fff203811f4 _dispatch_source_invoke + 1181 8 libdispatch.dylib 0x00007fff20376318 _dispatch_workloop_invoke + 1784 9 libdispatch.dylib 0x00007fff2037ec0d _dispatch_workloop_worker_thread + 811 10 libsystem_pthread.dylib 0x00007fff2051545d _pthread_wqthread + 314 11 libsystem_pthread.dylib 0x00007fff2051442f start_wqthread + 15 I do have a DispatchSourceTimer but I cancel it in the stop func. Any ideas on how to tackle this?

I am currently developing a custom-protocol VPN application for iOS using PacketTunnelProvider. I have also integrated an HTTP proxy service, which is launched via a dylib. The overall flow is as follows: App -> VPN TUN -> Local HTTP Proxy -> External Network I have a question: I am capturing all traffic, and normally, requests sent out by the HTTP proxy are also captured again by the VPN. However, when I send requests using createUdpSession in my code, they are not being captured by the virtual interface (TUN). What could be the reason for this? override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let tunnelNetworkSettings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "192.168.18.0") tunnelNetworkSettings.mtu=1400 let ipv4Settings = NEIPv4Settings(addresses: ["192.169.10.10"], subnetMasks: ["255.255.255.0"]) ipv4Settings.includedRoutes=[NEIPv4Route.default()] ipv4Settings.excludedRoutes = [NEIPv4Route(destinationAddress: "10.0.0.0", subnetMask: "255.0.0.0"), NEIPv4Route(destinationAddress: "172.16.0.0", subnetMask: "255.240.0.0"), NEIPv4Route(destinationAddress: "192.168.0.0", subnetMask: "255.255.0.0"), NEIPv4Route(destinationAddress:"127.0.0.0", subnetMask: "255.0.0.0"), ] tunnelNetworkSettings.ipv4Settings = ipv4Settings // Configure proxy settings let proxySettings = NEProxySettings() proxySettings.httpEnabled = true proxySettings.httpServer = NEProxyServer(address: "127.0.0.1", port: 7890) proxySettings.httpsEnabled = true proxySettings.httpsServer = NEProxyServer(address: "127.0.0.1", port: 7890) proxySettings.excludeSimpleHostnames = true proxySettings.exceptionList=["localhost","127.0.0.1"] tunnelNetworkSettings.proxySettings = proxySettings setTunnelNetworkSettings(tunnelNetworkSettings) { [weak self] error in if error != nil { completionHandler(error) return } completionHandler(nil) let stack = TUNInterface(packetFlow: self!.packetFlow) RawScoketFactory.TunnelProvider=self stack.register(stack: UDPDirectStack()) stack.register(stack: TCPDirectStack()) stack.start() } } NWUdpSession.swift // // NWUDPSocket.swift // supervpn // // Created by TobbyQuinn on 2025/2/3. // import Foundation import NetworkExtension import CocoaLumberjack public protocol NWUDPSocketDelegate: AnyObject{ func didReceive(data:Data,from:NWUDPSocket) func didCancel(socket:NWUDPSocket) } public class NWUDPSocket:NSObject{ private let session:NWUDPSession private let timeout:Int private var pendingWriteData: [Data] = [] private var writing = false private let queue:DispatchQueue=QueueFactory.getQueue() public weak var delegate:NWUDPSocketDelegate? public init?(host:String,port:UInt16,timeout:Int=Opt.UDPSocketActiveTimeout){ guard let udpSession = RawScoketFactory.TunnelProvider?.createUDPSession(to: NWHostEndpoint(hostname: host, port: "\(port)"), from: nil) else{ return nil } session = udpSession self.timeout=timeout super.init() session.addObserver(self, forKeyPath: #keyPath(NWUDPSession.state),options: [.new], context: nil) session.setReadHandler({ dataArray, error in self.queueCall{ guard error == nil, let dataArray = dataArray else { print("Error when reading from remote server or connection reset") return } for data in dataArray{ self.delegate?.didReceive(data: data, from: self) } } }, maxDatagrams: 32) } /** Send data to remote. - parameter data: The data to send. */ public func write(data: Data) { pendingWriteData.append(data) checkWrite() } public func disconnect() { session.cancel() } public override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) { guard keyPath == "state" else { return } switch session.state { case .cancelled: queueCall { self.delegate?.didCancel(socket: self) } case .ready: checkWrite() default: break } } private func checkWrite() { guard session.state == .ready else { return } guard !writing else { return } guard pendingWriteData.count > 0 else { return } writing = true session.writeMultipleDatagrams(self.pendingWriteData) {_ in self.queueCall { self.writing = false self.checkWrite() } } self.pendingWriteData.removeAll(keepingCapacity: true) } private func queueCall(block:@escaping ()->Void){ queue.async { block() } } deinit{ session.removeObserver(self, forKeyPath: #keyPath(NWUDPSession.state)) } }

Hi there, We have been trying to set up URL filtering for our app but have run into a wall with generating the bloom filter. Firstly, some context about our set up: OHTTP handlers Uses pre-warmed lambdas to expose the gateway and the configs endpoints using the javascript libary referenced here - https://developers.cloudflare.com/privacy-gateway/get-started/#resources Status = untested We have not yet got access to Apples relay servers PIR service We run the PIR service through AWS ECS behind an ALB The container clones the following repo https://github.com/apple/swift-homomorphic-encryption, outside of config changes, we do not have any custom functionality Status = working From the logs, everything seems to be working here because it is responding to queries when they are sent, and never blocking anything it shouldn’t Bloom filter generation We generate a bloom filter from the following url list: https://example.com http://example.com example.com Then we put the result into the url filtering example application from here - https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url The info generated from the above URLs is: { "bits": 44, "hashes": 11, "seed": 2538058380, "content": "m+yLyZ4O" } Status = broken We think this is broken because we are getting requests to our PIR server for every single website we visit We would have expected to only receive requests to the PIR server when going to example.com because it’s in our block list It’s possible that behind the scenes Apple runs sporadically makes requests regardless of the bloom filter result, but that isn’t what we’d expect We are generating our bloom filter in the following way: We double hash the URL using fnv1a for the first, and murmurhash3 for the second hashTwice(value: any, seed?: any): any { return { first: Number(fnv1a(value, { size: 32 })), second: murmurhash3(value, seed), }; } We calculate the index positions from the following function/formula , as seen in https://github.com/ameshkov/swift-bloom/blob/master/Sources/BloomFilter/BloomFilter.swift#L96 doubleHashing(n: number, hashA: number, hashB: number, size: number): number { return Math.abs((hashA + n * hashB) % size); } Questions: What hashing algorithms are used and can you link an implementation that you know is compatible with Apple’s? How are the index positions calculated from the iteration number, the size, and the hash results? There was mention of a tool for generating a bloom filter that could be used for Apple’s URL filtering implementation, when can we expect the release of this tool?

HI, I am currently developing an app that utilizes Wi-Fi Aware. According to the Wi-Fi Aware framework examples and the WWDC25 session on Wi-Fi Aware, discovery is handled using DevicePairingView and DevicePicker from the DeviceDiscoveryUI module. However, these SwiftUI views present their connection UI modally when tapped. My app's design requires the ability to control the presentation of this UI programmatically, rather than relying on a user tap. While inspecting the DeviceDiscoveryUI module, I found DDDevicePairingViewController and DDDevicePickerViewController, which appear to be the UIViewController counterparts to the SwiftUI views. The initializer for DDDevicePairingViewController accepts a ListenerProvider, so it seems I can pass the same ListenerProvider instance that is used with the DevicePairingView. However, the initializer for DDDevicePickerViewController requires an NWBrowser.Descriptor, which seems incompatible with the parameters used for the SwiftUI DevicePicker. I have two main questions: (1) Can DDDevicePairingViewController and DDDevicePickerViewController be officially used for Wi-Fi Aware pairing? (2) Are there any plans to provide more customization or programmatic control over the DevicePairingView and DevicePicker (for example, allowing us to trigger their modal presentation programmatically)? Thank you.

Getting -10985 error from urlSession while attempting to make a connection. Not sure why this is happening if anyone is aware please help

Hi everyone, I’m currently developing a macOS app that is distributed via a DMG file on our website. The app includes an App Extension (appex) for Network Extension functionality. I’m wondering if distributing via DMG on the web requires the app extension to be implemented as a System Extension instead of an App Extension. Is it necessary to migrate to System Extension for web-based DMG distribution, or can I continue using App Extension as is? Any insights or recommendations would be greatly appreciated. Thank you!