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.

Device: iPhone model + iOS 27 beta build number Mac: Mac model + macOS version Issue: Mac connects to iPhone Personal Hotspot successfully, but after several minutes the hotspot disconnects automatically. Expected: Mac should remain connected while hotspot is enabled and devices are nearby. Actual: Wi-Fi disconnects and Mac loses internet. Workarounds tried: Maximum Compatibility, restarting Wi-Fi, disabling VPN/Shadowrocket, USB tethering. Frequency: happens repeatedly / every X minutes.

Since macOS 26 (Tahoe), getaddrinfo() with AF_UNSPEC for a hostname whose DNS answer contains only A records (no AAAA) fails in forked child processes when the parent performed DNS resolution, or otherwise initialized os_log, before forking. This is a regression: the same code works on macOS 15.x and earlier. The child crashes with EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) inside the NAT64 synthesis path: _os_log_preferences_refresh (libsystem_trace.dylib) <- faulting frame os_log_type_enabled (libsystem_trace.dylib) nw_path_access_agent_cache (Network) _nw_path_update_is_viableTm / nw_path_snapshot_path / nw_path_evaluator_evaluate nw_nat64_v4_address_requires_synthesis _gai_nat64_second_pass (libsystem_info.dylib) si_addrinfo -> getaddrinfo Runtimes that install a SIGSEGV handler (Ruby, Python) do not die; instead the DNS helper thread spins at 100% CPU and the process hangs. We have also captured a parent-side variant where a later fork() deadlocks in the atfork prepare path itself: libSystem_atfork_prepare -> nw_path_prepare_fork -> _os_unfair_lock_lock_slow. Minimal trigger in C: os_log_t log = os_log_create("com.example.repro", "repro"); os_log(log, "init"); struct addrinfo hints = { .ai_family = AF_UNSPEC, .ai_socktype = SOCK_STREAM }, *res; getaddrinfo("api.stripe.com", "443", &hints, &res); // parent: IPv4-only host if (fork() == 0) { getaddrinfo("api.stripe.com", "443", &hints, &res); // child: crashes in _os_log_preferences_refresh _exit(0); } Observed behavior and boundaries: Reproduces on 26.1 through 26.5.1 (25F80). Not reproducible on macOS 15.x. Only AF_UNSPEC lookups of IPv4-only hostnames are affected. AF_INET hints, IPv6-capable hostnames (for example google.com), numeric literals, and localhost are all immune. AF_INET6-only lookups neither trigger nor prevent it. The failure is all-or-nothing per parent process: once a parent is in the affected state, every forked child fails. On 26.5.1 it reproduces most reliably when the process was exec'd over a prior os_log-using image (for example Ruby launched via bundle exec, where the bundler Ruby execs the target Ruby in the same process), and intermittently from a bare shell. On 26.1 even bare runs reproduced readily. This is consistent with per-process logging state surviving exec and then being inherited invalid across fork. I understand that officially only async-signal-safe calls are supported between fork and exec. But this worked through macOS 15, and it breaks the pre-forking worker model used by major Ruby and Python frameworks (Resque, Unicorn, multiprocessing) on developer machines. Filed as FB21364061 in December 2025, no response so far. Is this a known issue, and is a fix present or planned in macOS 26.6 or the macOS 27 beta?

Hello, We have a security solution which intercepts network traffic for inspection using a combination of Transparent Proxy Provider and Content filter. Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel: panic(cpu 0 caller 0xfffffe003bb68224): skmem_slab_free_locked: attempt to free invalid or already-freed obj 0xf2fffe29e15f2400 on skm 0xf6fffe2518aaa200 @skmem_slab.c:646 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25D2128 Kernel version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:38 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6050 Additionally, from further log inspection, before panics we find some weird kernel messages which seem to be related to some DMA operations gone wrong in the network driver on some machines: 2026-03-30 14:11:21.779124+0300 0x30f2 Default 0x0 873 0 Arc: (Network) [com.apple.network:connection] [C9.1.1.1 IPv4#e5b4bb04:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi, flow divert agg: 1, LQM: good)] event: flow:start_connect @0.075s 2026-03-30 14:11:21.780015+0300 0x1894 Default 0x0 0 0 kernel: (402262746): No more valid control units, disabling flow divert 2026-03-30 14:11:21.780017+0300 0x1894 Default 0x0 0 0 kernel: (402262746): Skipped all flow divert services, disabling flow divert 2026-03-30 14:11:21.780102+0300 0x1894 Default 0x0 0 0 kernel: SK[2]: flow_entry_alloc fe "0 proc kernel_task(0)Arc nx_port 1 flow_uuid D46E230E-B826-4E0A-8C59-4C4C8BF6AA60 flags 0x14120<CONNECTED,QOS_MARKING,EXT_PORT,EXT_FLOWID> ipver=4,src=<IPv4-redacted>.49703,dst=<IPv4-redacted>.443,proto=0x06 mask=0x0000003f,hash=0x04e0a750 tp_proto=0x06" 2026-03-30 14:11:21.780194+0300 0x1894 Default 0x0 0 0 kernel: tcp connect outgoing: [<IPv4-redacted>:49703<-><IPv4-redacted>:443] interface: en0 (skipped: 0) so_gencnt: 14634 t_state: SYN_SENT process: Arc:873 SYN in/out: 0/1 bytes in/out: 0/0 pkts in/out: 0/0 rtt: 0.0 ms rttvar: 250.0 ms base_rtt: 0 ms error: 0 so_error: 0 svc/tc: 0 flow: 0x9878386f 2026-03-30 14:11:21.934431+0300 0xed Default 0x0 0 0 kernel: Hit error condition (not panicking as we're in error handler): t8110dart <private> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2 2026-03-30 14:11:21.934432+0300 0xed Default 0x0 0 0 kernel: [ 73.511690]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.511696]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569033]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569038]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.577453]: arm_cpu_init(): cpu 7 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586328]: arm_cpu_init(): cpu 5 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586332]: arm_cpu_init(): cpu 8 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.621392]: (dart-apcie0) AppleT8110DART::_fatalException: dart-apcie0 (<ptr>): DART DART SID exception ERROR_SID_SUMMARY 0x00003000 ERROR_ADDRESS 0x0000000000009800 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: [ 73.621397]: Hit error condition (not panicking as we're in error handler): 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: t8110dart <ptr> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934452+0300 0xed Default 0x0 0 0 kernel: Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934456+0300 0xed Default 0x0 0 0 kernel: (AppleEmbeddedPCIE) apcie[0:centauri-control]::_dartErrorHandler() InvalidPTE caused by read from address 0x9800 by SID 2 (RID 2:0:1/useCount 1/device <private>) 2026-03-30 14:11:21.934469+0300 0xed Default 0x0 0 0 kernel: (AppleT8110DART) Ignored dart-apcie0 (0xfbfffe18820b0000): DART(DART) error: SID 2 PTE invalid exception on read of DVA 0x9800 (SEG 0 PTE 0x2) ERROR_SID_SUMMARY 0x00003000 TIME 0x11242d43fd TTE 0xffffffffffffffff AXI_ID 0 We do not have any correlation between machines, usage pattern or installed applications. Uninstalling the network protection features seem to largely fix the issues, even though we have heard of crashes happening even in safe mode or with our network extension disabled from system settings. We weren't able to reproduce internally and it seems to happen completely random on client machines, but often enough to be disrupting. Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down? Thanks.

When entering the following command in macOS 27 beta: lvbojie@Mac ~ % netstat -I nan0 1 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll nan0* 1500 <Link#25> 66:31:00:4c:3c:b5 0 0 41 0 0 nan0* 1500 fe80::6431: fe80:19::6431:ff: 0 - 41 - - liushicong@Mac ~ % netstat -I nan0 1 The nan0 network interface is displayed. Does this indicate that macOS will support Wi-Fi Aware in the near future?

I have a swift app which I'm running via a LaunchAgent. It sends a video feed via multicast UDP. While it works if I manually allow via Privacy & Security - Local Network (allowing the app to find devices on local network), I cannot get AllowedEthernetLocalNetworkAddresses to work. I have attempted to do so with my app and with ffmpeg (installed via homebrew). Neither seems to respect the AllowedEthernetLocalNetworkAddresses setting outlined in TN3179: Understanding local network privacy | Apple Developer Documentation. I have attempted allowing 239.0.0.0/8, 224.0.0.0/4, 239.255.0.0/16, 239.255.1.1/32. I see no change after a reboot with any of these values in the array: sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "239.0.0.0/8" This is on macOS 26.5.1, and I am only connected via ethernet. Am I missing a configuration piece? Thanks!

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

Hello, We recently moved to the NWPath.Status implementation for reachability, is that the same reachability that powers URLSessionConfiguration.waitsForConnectivity? Or does the NWPath implementation rely on a specific network path such as cell only or wifi only? Is using NWPath still the best way to measure if the network is reachable? Thank you!

We have observed a per-process limitation on the number of simultaneous nw_connection_t objects in certain macOS environments. On some systems, this limit does not appear to apply, but on others the limitation is reproducible. When a process attempts to establish a large number of connections (e.g. 512+), some connections enter the nw_connection_state_waiting state and report the POSIX error “Cannot allocate memory”. These connections remain stuck indefinitely, even after other connections are deallocated and resources should theoretically be available again. This behavior severely impacts use cases such as transparent proxies implemented via the NetworkExtension framework, which intercept system-wide traffic and must open connections on behalf of all client processes. In this scenario, a per-process limit effectively becomes a system-wide limit, leading to unexpected and hard-to-diagnose network failures in client applications. Can we expect a relaxation of these restrictions for network extensions in the future? Could you please suggest some workarounds to bypass the restriction? By the way, now we have to fallback to BSD socket implementation of the outgoing connections, possibly braking the chain of TransparentProxies as the second proxy in the chain can’t get the originator of the intercepted flow (it sees the first proxy instead).

A performance bottleneck we often hit is that we seem to be constrained by issuing a single sys call per packet. On platforms where vectored IO is supported, we can unlock 5x performance gains. Whilst we can read arrays of packets via the network extension API, the memory and concurrency model of that API seems to not be well documented, and I am not aware of any way to do vectored I/O on a UDP socket. Will we see an FFI friendly API for vectorised networking anytime soon? As an addendum - we are aware of sendmsg_x and recvmsg_x but we dare not ship an iOS app using those functions directly.

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

I have an iOS app that now cannot connet to websocket servers when building with new SDKs. The app that i have deployed in appstore can connect to the existing websocket servers we use but when i build the same code with the new SDKs (Nex XCode) the app connects to the websocket server and then disconnect right after that so no messages are received and no messages are sent. What has changed and what do i need to change in the app? Or do i need to change somehing else somewhere else?

We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced. iOS → iOS 26 Networking → URLSession / Network.framework

Hello, it seems Multipeer Connectivity is deprecated. We are looking to connect multiple Vision Pros together that are in the same physical space but in unknown network setups (That might block P2P communication and Multicasting). We are building an app with unity and already have networking solution that we are looking to extend to work with something like multipeer connectivty? Am I reading the docs right that "Apple peer-to-wifi" is the replacement. And that by using the "includePeerToPeer" property this will work. Would it be possible in this way that the Vision Pros discover and communicate with each other even if not connected to an AP?

We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection. Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies. Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies. This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely. Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag). Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy). Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client. Questions: Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)? If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?

wifip2pd leaks file descriptors during repeated Wi-Fi Aware NDP cycles → EMFILE → Wi-Fi Aware permanently broken Summary Under repeated Wi-Fi Aware (NAN) datapath connect/teardown cycles, wifip2pd leaks file descriptors until it hits the per-process limit (EMFILE, "Too many open files"). After that, wifip2pd can no longer create the socket needed to configure the nan0 interface, so updating the nan0 IPv6 link-local address fails with Apple80211Error Bad file descriptor. From the app's side, the NDP datapath is established but the NetworkConnection never gets a local IPv6 address and stays stuck in .preparing. The condition does not self-heal and is not cleared by restarting the app — only a reboot (or wifip2pd restart) recovers Wi-Fi Aware. Configuration iPhone 16 Pro Max, iOS 26.5 Network framework (new Swift NetworkConnection / NetworkBrowser Wi-Fi Aware API) System component: wifip2pd Where the problem is The leak and the failure are entirely inside wifip2pd (the per-process descriptor table fills up). The chain is: fd leak in wifip2pd → EMFILE ("Too many open files", errno 24) → socket() fails → cannot set nan0 IPv6 link-local address (Apple80211 ioctl on invalid fd → EBADF) → app NWConnection NWPath = satisfied but localEndpoint = nil → NetworkConnection stuck in .preparing, times out Abnormal console logs (the evidence) The smoking-gun lines from the unified log / Console (process wifip2pd): wifip2pd <Error> Failed to create socket: Too many open files wifip2pd <Error> Failed to update nan0 IPv6 address to [fe80::30c1:22ff:fe97:fefb] (from [fe80::e8a0:9bff:fe25:4d5c]) because <Apple80211Error Bad file descriptor> wifip2pd <Error> nw_path_shared_necp_fd necp_open failed [24: Too many open files] # errno 24 = EMFILE wifip2pd(Network) <Error> File descriptor is bad, could not create socket Counts over one ~11.5-minute failing capture: wifip2pd "Too many open files": 45 occurrences (a healthy capture has 0). nan0 IPv6 address update: 2 success / 13 fail (the 2 successes are before exhaustion; everything after fails with "Bad file descriptor"). Healthy device, for contrast — the IPv6 update succeeds on every NAN MAC rotation, and the app connection then works: wifip2pd Successfully updated nan0 IPv6 address to [fe80::f4c4:14ff:fe28:784a] # → app NWPath: status=satisfied, local=fe80::f4c4:14ff:fe28:784a%nan0 → NetworkConnection .ready Two facts that localize the bug: The leak is in wifip2pd, not the app. wifip2pd is one persistent daemon (constant pid) whose fd count only grows; the client app was restarted multiple times during the test and that did not release the descriptors. All "Too many open files" lines are emitted by wifip2pd. The NDP datapath itself still succeeds — only socket/interface-address configuration fails: kernel nan0: handleDataPathEstablished: NAN-DP Data path ESTABLISHED ... encrypt 1, EstDPs 1 wifip2pd #### Data Confirmed With Peer: ... port: 9004 Application-layer symptom (developer-facing) The same client code works before exhaustion and fails after: Before: NetworkConnection<UDP> reaches .ready; NWPath.localEndpoint = fe80::…%nan0. After: NetworkConnection<UDP> stays .preparing; every onPathUpdate reports status=satisfied, interfaces=["nan0"], local=nil; it times out and retries forever. The decisive developer-visible signal is NWPath.status == .satisfied together with localEndpoint == nil on nan0. Correlating timestamps confirms the contradiction: the console shows Data Confirmed With Peer ... port 9004 ~9–10 s before the app's NetworkConnection gives up, while the matching nan0 IPv6 update fails with "Bad file descriptor". The datapath is up at L2, but the connection is unusable because no local address was ever assigned. Steps to Reproduce Pair an iPhone with a Wi-Fi Aware peer that publishes a datapath service (_media-sync._udp, paired device, NCS-SK-CCM-128). Repeatedly establish and tear down the NDP datapath. In our case the peer device repeatedly powers off/on; each cycle forces a fresh browse + re-pair + NDP establish (the peer's NAN MAC is randomized each boot). Loop this; wifip2pd is never restarted, so the leak accumulates (failure appeared by ~the 9th iteration). Expected vs Actual Expected: wifip2pd releases the descriptors of each completed/torn-down browse/subscribe/datapath session; fd count stays bounded; nan0 IPv6 updates keep succeeding; NetworkConnection reaches .ready. Actual: wifip2pd fd count grows until EMFILE; nan0 IPv6 update then fails permanently; NetworkConnection is stuck .preparing for the rest of the wifip2pd process lifetime. Impact Any app using Wi-Fi Aware NDP datapaths under frequent connect/teardown eventually loses all Wi-Fi Aware connectivity. The failure is sticky for the wifip2pd lifetime and is invisible to / unrecoverable by the client app. Workaround Reboot the device (resets wifip2pd). The client can only slow the leak (fewer reconnects, prompt release of NetworkConnection), not prevent it, since the descriptors leak inside wifip2pd. To confirm / fix A sysdiagnose captured during the reproduction should show wifip2pd's open-fd count growing monotonically per connect/teardown cycle (which descriptor type leaks per browse/subscribe/datapath). Repro signature to grep in the logs: wifip2pd emitting Failed to create socket: Too many open files, necp_open failed [24: Too many open files], and Failed to update nan0 IPv6 address ... Apple80211Error Bad file descriptor.

As shown in the image, Apple's Wi-Fi Aware framework mentions support for Mac 26.0+

This is a bit complicated to explain so bare with me. I am working on building an app that allows you to send real time video/camera captures from one Apple device to another. I am using a custom UDP protocol built on top of NWListener, NWBrowser, and NWConnection APIs. It works fine, but there are a few issues that seems to all be related to awdl: When transmitting via WiFi over the router (not using peer-to-peer), there are periodic interruptions when the wireless card on the device changes channels for awdl polling. This is resolved by changing the 5GHz WiFi channel on the router to channel 149 (or disabling AWDL altogether which is not really feasible). In order to work around number 1, I decided to build in an option to toggle/prefer peer-to-peer transmission in the app thinking that if everything goes over a peer-to-peer connection the jitter caused from the channel switching should go away. This also works, but with an important caveat. The default transmission is extremely choppy until you take an OS action that “elevates” the AWDL connection into “realtime” mode. I am using includePeerToPeer on the listener, browser, and connection as well as serviceClass interactiveVideo. For number 1, you can understand that asking users to change the channel on their router is not a great user experience, but the problem is the peer-to-peer connection workaround is also not great by default. For number 2, as an example of the behavior, I can send a stream from my Mac to my iPad over a peer-to-peer connection and it works but the video is very choppy until I move my cursor from my Mac to my iPad to trigger Universal Control. I captured the OS logs while doing this and can confirm that something happens to trigger “realtime” mode on the AWDL connection. After that, the streaming is totally smooth with zero latency. Some log samples: 2026-03-19 12:42:01.277968-0400 0x1ae294c Default 0x0 495 3 rapportd: (CoreUtils) [com.apple.rapport:CLinkD] Update client from UniversalControl:697 2026-03-19 12:42:01.278031-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Connect start: 'CLink-ed3b9618b4e0._companion-link._tcp.local.%13' 2026-03-19 12:42:01.278149-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Querying SRV CLink-ed3b9618b4e0._companion-link._tcp.local.%13 2026-03-19 12:42:01.279454-0400 0x1ae253a Info 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] Created AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52> 2026-03-19 12:42:01.279498-0400 0x1ae294c Default 0x0 495 0 rapportd: (CoreUtils) [com.apple.CoreUtils:AsyncCnx] CLinkCnx-6089: Resolving DNS f970afcc-1f1c-47af-a3f3-0236c9f9bbb0.local.%13 2026-03-19 12:42:01.279588-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:datapathInitiator] AWDLDatapathInitiator clink-ed3b9618b4e0._companion-link._tcp.local <To: 2e:f2:5a:15:76:52> was started 2026-03-19 12:42:01.282537-0400 0x1ae294c Default 0x0 495 0 rapportd: (Network) [com.apple.network:path] nw_path_evaluator_start [5C54D967-624D-4269-B080-6C7AE63218C7 IPv6#1e905043%awdl0.49154 generic, attribution: developer] path: satisfied (Path is satisfied), interface: awdl0[802.11], dns, uses wifi 2026-03-19 12:42:01.596450-0400 0x1ae253a Debug 0x0 382 0 wifip2pd: [com.apple.awdl:driver] Received event realtimeMode 2026-03-19 12:42:01.596589-0400 0x1ae253a Default 0x0 382 0 wifip2pd: [com.apple.awdl:interface] Realtime mode updated true I noticed that on iOS 26 and iPadOS 26 a realtime mode was added specifically to the Wi-Fi Aware API which I assume does what I want: https://developer.apple.com/documentation/wifiaware/waperformancemode/realtime, but I am looking for a solution that works with the existing network API and also on previous OS versions. I have already tried a lot of things, but is there any way to programmatically trigger “realtime” mode? For additional context, the goal here is to have extremely low latency that also works for gaming. The actual latency introduced in 1 is approximately 30-50ms around once a second… adding a buffer to the stream makes the video completely smooth, but the extra delay on the receiver end is not acceptable for this use case. Any help or ideas would be appreciated. I can’t easily share a reproduce case right now, and even if I could, getting multiple devices into the exact state along with the router configuration in order to reproduce is going to be pretty difficult anyway.

Hello, I am working on a DLP (Data Leak Prevention) agent which must programmatically install our custom Root CA certificate into the System Keychain with the "Always Trust" policy. This is required for our network inspection module. The installation process is currently handled by a LaunchDaemon. I am using the following command: security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain The certificate is successfully added to the System Keychain, but the "Always Trust" policy is completely ignored. The certificate remains untrusted until the user manually opens System Settings and explicitly changes the trust settings. Our DLP agent is specifically designed for environment where MDM is not present and we can not rely on MDM to push profiles. Is it officially possible to set "Always Trust" for certificate programmatically from a LaunchDaemon? Thank you in advance!

I need to programmatically configure TLSv1.3 control parameters like cipher suites, Named Groups Signature Scheme I can see in the apple development documentation, there is a option to configure cipher suites but no way to configure Named Groups and Signature Scheme. Does anyone know a way to configure "Named Groups" & "Signature Schemes" also ? or If it is not possible in iOS then also Do we have anywhere written in documentation (evidence) ?