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 TCP and UDP ports used by Apple software products support article 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 Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation 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. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography 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. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. 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 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.

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

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?

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.

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

Hi Team, I'm trying to understand the behavior of the following API: HTTPCookieStorage.shared.setCookies(_:for:mainDocumentURL:) Specifically, does this API persist cookies synchronously, or does it perform the storage asynchronously in the background? Our use case is storing FCAP (frequency capping) cookies so they persist across app sessions. We call setCookies(_:for:mainDocumentURL:) and want to know whether the cookies are guaranteed to be written before the method returns, or if the actual persistence happens asynchronously. I couldn't find documentation describing the persistence semantics of this API, so I'd appreciate any clarification or guidance from Apple or anyone familiar with its implementation. 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.

Hello! Users of my app observed behaviour that some apps stopped working after update to 15.7.8 via Beta channel with transparent proxy network extension on. The app receives Protocol not available error, and I see setsockopt SO_FLOW_DIVERT_TOKEN failed [42: Protocol not available] error in Console. To reproduce, create two rules in basic NETransparentProxyProvider: [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolTCP], [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolUDP], You may even return NO in handleNewFlow, it does not matter. After that, Safari won't open some sites, and Weather app will work unreliably. Do anyone knows any workaround for this problem? I've also create a relevant FB23788740.

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

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'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!

Has anyone successfully requested an OHTTP Relay for URL filtering and got it approved? I first applied for a relay about a month ago, and it was rejected in the first 24h, apparently the DNS TXT record doesn’t have to be setup at the apex domain but at the PIR subdomain (or at least that’s my assumption because Apple doesn’t tell you). After correction the issue and resubmitting the request I haven’t heard back, it’s been in review for many weeks already. Has anyone experienced this kind of delay or has anyone gotten the relay approved?

Using rvictl with iOS 27 beta3 doesn't work anymore. RVICTL reports a successful creation of the remote virtual interface, but the interface rvi0 fails to spawn. rvictl -s Starting device [SUCCEEDED] with interface rvi0 rvictl -l Could not get list of devices iPhone 16 pro iOS 27 Beta3 macOS 27 Xcode 27 beta Confirmed that the command still works on iOS 26.6 on an iPhone 15 Pro.

Hi all, I've run into a kernel deadlock issue involving content filter + VPN system/network extension on macOS 26, and would really appreciate any insights. A user reported that their mac is occasionally assigened a 169.254.0.0/16 address and can't reach any website after connecting Wi-Fi. Disabling our content filter restores network connectivity immediately. They're running the following software on the mac: macOS 26 (issue reproduced on 25C56 and 25F71) NEFilterDataProvider-based content filter (our extension) VPN network extension A spindump taken while the system had lost network connectivity shows the content filter's process stuck while delivering an "allow" verdict to the kernel. All subsequent flow decisions for the extensions are blocked behind it, which would explain why new DHCP request can't complete and the interface stays on a self-assigned address. Based on the "last ran" and timestamp in the spindump, the underlying deadlock appears to have occurred while the computer wasn't connected to any Wi-Fi network, so there was no visible symptom at the time. The user only noticed something was wrong once they tried to reconnect and saw the bad IP address; they did not realize the content filter was already stuck. This issue may be identified by searching for keyword "sofreelastref" in the spindump (see comment below). Has anyone else seen a content filter + VPN hang like this on macOS 26? Any guidance or pointers would be greatly appreciated. Thanks in advance! For Developer Technical Support staffs: FB23720745 Shay

Hello, I am a tech guy. I have a site-to-site IPsec tunnel connection two gateways. Behind one of them is my Mac. I found iCloud private relay still send me packets larger than expected. For instance, according to my testing via Scapy, my TCP packets can have a MTU of 1280, given IPsec tunnel is activated. Also, ICMP showed a maximum payload of 1252. I have tried to reduce my Mac's MTU from 1500 to 1280. But still, iCloud private relay servers send me packets larger than 1280, according to tcpdump captured data. Therefore, I wonder, are there any ways to make both iCloud private relay and IPsec work at the same time. Thanks.