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. WWDC 2025 Session 250 Use structured concurrency with Network framework — This is a great introduction to the new Network framework API introduced in appleOS 2026. 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 Building peer-to-peer apps sample code 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.

Summary Recent macOS release observed intermittent system-wide DNS failures after sleep/wake on multiple devices running Global Secure Access (GSA) with NETransparentProxyProvider. Previously successful DNS lookups time out after wake across applications, including browsers and GSA. Two captures contain failure-time evidence of the mDNSResponder resolver queue predominantly waiting in close()/kernel. Other captures show similar DNS failures, but a shared root cause has not been established. Call chain, from thread entry to kernel wait: start_wqthread + 8 _pthread_wqthread + 292 _dispatch_workloop_worker_thread + 720 _dispatch_root_queue_drain_deferred_wlh + 284 _dispatch_lane_invoke + 392 _dispatch_lane_serial_drain + 332 _dispatch_source_invoke + 920 _dispatch_source_cancel_callout + 208 _dispatch_continuation_pop + 596 _dispatch_client_callout + 16 close + 8 fleh_synchronous + 72 sleh_synchronous (sleh.c:1610) unix_syscall (systemcalls.c:181) fp_close_and_unlock_with_action (kern_descrip.c:1874) fg_drop (kern_descrip.c:287) soclose (uipc_socket.c:1345) soclose_locked (uipc_socket.c:1138) cfil_sock_close_wait (content_filter.c:5743) soflow_db_apply (socket_flows.c; line unavailable) cfil_filters_udp_attached_per_flow (content_filter.c:6675) _sleep (kern_synch.c:213) lck_mtx_sleep_deadline (locks.c:1583) thread_block_reason (sched_prim.c:4060) thread_invoke (sched_prim.c:3443) Steps to reproduce The issue is intermittent. These steps describe the observed sequence, not a deterministic minimal reproduction. Run the GSA client using NETransparentProxyProvider. The affected configurations also have Microsoft Defender network extensions active. Verify that a system DNS lookup succeeds for a known hostname. Allow the Mac to sleep, including maintenance DarkWake cycles. Wake the Mac and repeat system DNS lookups or use applications requiring hostname resolution. Observe repeated approximately 30-second lookup timeouts, sometimes longer. Observed results November 5, 2026 - UTC+05:30 capture User-reported impact: Recurrence of the same sleep/wake connectivity symptoms. OS: macOS 27.2 (26B123). Incident window: 20:38-20:41 IST / 15:08-15:11 UTC. The same Chrome client/name A lookup succeeds earlier in 12.984 ms but times out after wake in 29,999.705 ms. The DNS service/server route changed, so this is not a controlled identical-network comparison. The resolver records 1,007 timeout callbacks during the incident window, across browsers, Teams, GSA, Defender and other processes. The failure-time spindump at 20:40:21.009-20:40:31.013 IST shows the original mDNSResponder PID 78534 with 715/715 resolver-queue samples under dispatch-source cancellation → close() → kernel → lck_mtx_sleep_deadline. Source: spindump.txt:75998-76093. This establishes a sampled wait, not a permanent deadlock or proof of the same root cause as November 2. The file descriptor and kernel/filter wait owner remain unidentified. A later matching Chrome lookup returns an address at 20:43:18.191816 IST on the same resolver PID, without a recorded resolver restart. This establishes some recovery, not that every application or tunnel recovered. November 2, 2026 - UTC-08:00 capture User-reported impact: No network upon wake. This eventually resolves without a reboot, after approximately 5 to 15 minutes of waiting. OS: macOS 27.2 (26B123). Incident window: 09:40-09:45 PST / 17:40-17:45 UTC. The same Edge A lookup succeeds before sleep in 19.346 ms but times out after wake in 29,999.826 ms. The resolver records 1,403 timeout callbacks during the incident window. The failure-time spindump shows 770/777 resolver-queue samples under dispatch-source cancellation → close() → kernel; 769 include lck_mtx_sleep_deadline. This establishes a dominant sampled wait, not a permanent deadlock. The file descriptor and kernel/filter wait owner remain unidentified. November 3, 2026 - UTC-08:00 capture (Mihai) Evidence: mihai_gsa_error.tar.gz The following example records a failure resolving GSA’s own control-plane endpoint, whose DNS lookup is not intercepted by the GSA tunnel. Times in these excerpts are local (UTC-08:00). GSA error [2026-11-03 10:13:58.463] Network connection to the Global Secure Access Edge could not be established StreamId: ControlStream Hostname: <tenant>.auth.client.globalsecureaccess.microsoft.com:443 Error: hostname lookup error: Address lookup failed os_error: nodename nor servname provided, or not known syscall: getaddrinfo mDNSResponder records 10:13:19.663661 [R125367->DupQ50990->Q38408] Duplicate question <private> dn:04wpeA (Addr) 10:13:58.468519 [R125367] DNSServiceQueryRecord STOP -- name hash: dn:04wpeA, duration: 39s 10:13:59.078847 [R125340] QueryRecordOpCallback: Question <private> dn:04wpeA (Addr) timing out, InterfaceID 0x0 Additional observations The original resolver records 11 timeout callbacks across GSA, Defender, Spotify and the system time service. A GSA A-query returns a positive result in 1.282 ms earlier (cache-compatible, not a cold upstream baseline), then the same client/name/qtype/flags times out after 41.865784 wall-clock seconds; that interval includes sleep. The DNS service/server set changes, so this is not a controlled same-network comparison. At 09:40 PST the Wi-Fi interface becomes inactive and loses its IPv4 address, followed by no-dns-service results. The first native lookup errors precede this link loss; it does not explain the entire case. Four GSA A/AAAA timeout transactions have matching late UDP replies. For one A-query, the reply is logged 25.095999 seconds after its matching send and 7.197434 seconds after the API timeout, during shutdown. 48 acceptable UDP response records appear within 1.467 ms. The location of the delay is not identified.

Hello, Our iOS app has been rejected four times under Guideline 2.1(a) because sign-in fails on the review iPad. The latest rejection showed NSURLErrorDomain error -1001 (the request timed out) on an iPad Air 11-inch (M3) with iPadOS 27.0, on November 5, 2026, at about 11:54 UTC. The same happened on October 16, 2026. Setup: API: https://wp.pavilion.az, HTTPS on port 443, fixed DNS name DNS and proxy on Cloudflare (IPv4 and IPv6), publicly trusted certificate The app uses URLSession, with no custom certificate checks and no proxy settings What we checked: Neither our origin server nor Cloudflare logged any request from the review device on either day. Other clients were served normally during the same minutes. The domain resolves normally from many public DNS resolvers in the United States and Europe, over IPv4 and IPv6. The app signs in in under one second on an iPad simulator in a data center in Los Angeles, and on our own devices through TestFlight. This looks similar to https://developer.apple.com/forums/thread/773444, where a Cloudflare-hosted domain resolved to a wrong address inside Apple's network. Could someone from Apple check how wp.pavilion.az resolves, and whether it is reachable, from the App Review network? We have resubmitted a build that adds a short network check to the error message (the DNS result and which connection step fails), but each review cycle takes many days. Thank you.

On macOS, multiple NETransparentProxyManager (NEAppProxyProvider) configurations from different vendors can be enabled (isEnabled = true) and run simultaneously. However, we discovered that when one NETransparentProxyManager configuration calls saveToPreferencesWithCompletionHandler: with isOnDemandEnabled = true, /usr/libexec/nehelper (NEConfigurationManager) silently modifies any other enabled NETransparentProxyManager configuration in /Library/Preferences/com.apple.networkextension.plist and flips its OnDemandEnabled to false (and nesessionmanager logs Resetting VPN On Demand and marks the other session not-kernel-activated). Unlike NEVPNManager.isEnabled (which documents mutual exclusion for personal VPNs), NETransparentProxyManager is designed so multiple transparent proxies can coexist simultaneously, and neither NETransparentProxyManager.h nor NEVPNManager.h documents that isOnDemandEnabled is mutually exclusive across coexisting transparent proxy configurations. Root Cause Observed in NetworkExtension.framework When inspecting -[NEConfigurationManager saveConfigurationToDisk:updateSCPreferences:currentSignature:userUUID:notifyNow:isUpgrade:], when iterating over existing NEConfiguration objects of the same grade: If [[newConfig VPN] isEnabled] && [[otherConfig VPN] isEnabled] && [[newConfig VPN] isOnDemandEnabled] && [[otherConfig VPN] isOnDemandEnabled], NEConfigurationManager invokes: +[NEConfigurationManager disableConfiguration:otherConfig onDemandOnly:YES] disableConfiguration:onDemandOnly:YES calls [[otherConfig VPN] setOnDemandEnabled:NO], even when both configurations are NETransparentProxyManager (TunnelType == 2). Real-World Impact When two enterprise security products that both use NETransparentProxyManager are installed on the same Mac: Both configure isEnabled = true, onDemandRules = [NEOnDemandRuleConnect()], and isOnDemandEnabled = true. Whenever Proxy A saves its preferences, nehelper silently flips Proxy B's isOnDemandEnabled to false (and vice versa). After a reboot or network transition where Proxy B's initial startVPNTunnel fails while Wi-Fi is still associating and Proxy B relies on VPN On Demand (NEOnDemandRuleConnect) to start its NEAppProxyProvider once network connectivity comes up, macOS never starts Proxy B because its isOnDemandEnabled flag was cleared. Minimal Reproducer (Swift) Compile this minimal CLI inside an app bundle signed with the com.apple.developer.networking.networkextension = ["app-proxy-provider"] entitlement: import Foundation import NetworkExtension let args = CommandLine.arguments let name = args.count > 1 ? args[1] : "PocProxyA" let action = args.count > 2 ? args[2] : "status" DispatchQueue.main.async { NETransparentProxyManager.loadAllFromPreferences { managers, error in if let error = error { print("[\(name)] loadAllFromPreferences error: \(error)") exit(1) } let all = managers ?? [] let existing = all.first(where: { $0.localizedDescription == name }) if action == "status" { if let mgr = existing { print("[\(name)] -> isEnabled=\(mgr.isEnabled), isOnDemandEnabled=\(mgr.isOnDemandEnabled), rulesCount=\(mgr.onDemandRules?.count ?? 0)") } else { print("[\(name)] -> not found") } exit(0) } if action == "remove" { guard let mgr = existing else { exit(0) } mgr.removeFromPreferences { err in print("[\(name)] removed (err=\(String(describing: err)))") exit(0) } return } // action == "save" let mgr = existing ?? NETransparentProxyManager() let proto = (mgr.protocolConfiguration as? NETunnelProviderProtocol) ?? NETunnelProviderProtocol() proto.providerBundleIdentifier = "com.example.poc.extension" proto.serverAddress = "127.0.0.1" mgr.protocolConfiguration = proto mgr.localizedDescription = name mgr.isEnabled = true mgr.onDemandRules = [NEOnDemandRuleConnect()] mgr.isOnDemandEnabled = true print("[\(name)] Saving NETransparentProxyManager with isEnabled=true, isOnDemandEnabled=true...") mgr.saveToPreferences { err in if let err = err { print("[\(name)] saveToPreferences error: \(err)") exit(1) } print("[\(name)] saveToPreferences succeeded! isEnabled=\(mgr.isEnabled), isOnDemandEnabled=\(mgr.isOnDemandEnabled)") exit(0) } } } RunLoop.main.run()Reproduction Output Running save on PocProxyA, then save on PocProxyB, and checking status on both: === Step 1: PocProxyA saves isOnDemandEnabled = true === [PocProxyA] Saving NETransparentProxyManager with isEnabled=true, isOnDemandEnabled=true... [PocProxyA] saveToPreferences succeeded! isEnabled=true, isOnDemandEnabled=true [PocProxyA] -> isEnabled=true, isOnDemandEnabled=true, rulesCount=1 === Step 2: PocProxyB saves isOnDemandEnabled = true === [PocProxyB] Saving NETransparentProxyManager with isEnabled=true, isOnDemandEnabled=true... [PocProxyB] saveToPreferences succeeded! isEnabled=true, isOnDemandEnabled=true === Step 3: Check BOTH configurations after PocProxyB saved === [PocProxyA] -> isEnabled=true, isOnDemandEnabled=false, rulesCount=1 [PocProxyB] -> isEnabled=true, isOnDemandEnabled=true, rulesCount=1 === Step 4: PocProxyA saves isOnDemandEnabled = true again === [PocProxyA] Saving NETransparentProxyManager with isEnabled=true, isOnDemandEnabled=true... [PocProxyA] saveToPreferences succeeded! isEnabled=true, isOnDemandEnabled=true === Step 5: Check BOTH configurations after PocProxyA saved === [PocProxyA] -> isEnabled=true, isOnDemandEnabled=true, rulesCount=1 [PocProxyB] -> isEnabled=true, isOnDemandEnabled=false, rulesCount=1Questions Is disableConfiguration:onDemandOnly:YES stripping isOnDemandEnabled across coexisting NETransparentProxyManager (TunnelType = 2) configurations a bug in NEConfigurationManager, or an intentional limitation? Is there a recommended way for two coexisting NETransparentProxyManager configurations from different vendors to both use On-Demand without disabling each other's isOnDemandEnabled flag on saveToPreferences? Filed in Feedback Assistant as FB25463155.

Hello, Some context: DropBet is an app that helps people with gambling addiction stay off gambling sites and apps, using NEURLFilterManager/PIR to block a large list of known gambling domains system-wide. For a lot of our users this filter is a core part of their recovery > reliability really matters here. Since fixing an unrelated HPKE encryption bug (separate thread, now closed), the filter works end-to-end for the first time, but blocking is inconsistent per domain in a way I can't explain from my side: winamax.fr and the Winamax app: blocked reliably, every single time > clean "connection failed" style block, confirmed to load fine with protection off. unibet.fr and betclic.fr: never blocked, consistently > confirmed even after a full device reboot (rules out stale caching), and confirmed identical across both Safari and Chrome on iOS tested side-by-side (so not browser-specific). olybet.fr: flaps > the page reloads every 2-3 seconds with protection on, also identical across both browsers. Confirmed this only happens with the filter enabled (tested toggling protection off/on against the same page). unibet.fr auto-redirects into the native Unibet app via a Universal Link before the page loads, unlike betclic.fr which stays in the browser > different code path, possibly relevant. To rule out any issue on our end, I wrote a standalone test that queries our deployed PIR database shards directly - bypassing OHTTP, the app, and the device entirely - for all of the domains above plus their www. variants. All of them correctly return the blocked value, no exceptions, including unibet.fr and betclic.fr which never block on the actual device. So the database, the PIR protocol implementation, and the server are confirmed correct for every domain I've tested. This points at something in how NEURLFilterManager/ciphermld applies a correctly-received PIR verdict on-device - possibly related to query batching, an evaluation-key edge case, or Universal Link handling bypassing the filter before a web request is even made. Is there anything you can share about how the client applies results once decrypted, or known issues around any of this?

I am investigating an iOS Wi-Fi Aware issue in which wifip2pd accumulates netpolicy file descriptors until it reaches its 256-FD limit. After this point, new Wi-Fi Aware pairing / NDP setup attempts fail. Environment Device: iPhone 18 Pro Max OS: iOS 27.0 (24A8428) The issue was noticed during repeated Wi-Fi Aware pairing, NDP establishment, data transfer, and session release on November 3, 2026, around 18:34 (UTC+8). Observed descriptor counts A complete sysdiagnose captured during the failure at 19:54:44 (UTC+8) contains the following taskinfo entry: process: "wifip2pd" [285] file descriptors: 256 (vnode: 3, socket: 9, netpolicy: 243, nexus: 1)The old wifip2pd process terminated at 19:54:59, and a new instance started shortly afterward. A second complete sysdiagnose captured the following day, after that restart, shows: process: "wifip2pd" [20455] file descriptors: 27 (vnode: 3, socket: 9, netpolicy: 14, nexus: 1)The recovery coincided with the wifip2pd restart and Wi-Fi power transitions. The available logs do not isolate which user action triggered the restart, so I am not claiming a specific recovery procedure. Expected behavior Descriptors associated with completed sessions should be released or reused. Repeated Wi-Fi Aware session setup and teardown should not leave wifip2pd unable to allocate further descriptors. So far I have observed this only once and do not yet have a minimal or deterministic reproduction. I also cannot yet prove which API or session object retains the descriptors. I have privately filed Feedback FB25442154 with the original, complete sysdiagnose captures from the failure and recovery states. I am not attaching those archives to this public post. Could Apple Engineering please advise on: Whether there are known iOS 27.0 issues in which wifip2pd retains netpolicy descriptors after Wi-Fi Aware / NDP teardown, and which component owns their lifecycle? The recommended ordering for releasing NDP and Wi-Fi Aware session resources so that the system can clean up all associated state? Any supported application-side mitigation, and the most useful additional logging or state to capture if this recurs? I can provide further timing correlations or a focused reproduction privately through the Feedback if needed.

I see types like TCP or TLS include methods to change an option. These methods return Self. I want something similar for my protocol framer. Like the types above, the user-level object is a value type. The inards to work with Apple's code is a Framer<MyImplementation> property. I don't know from looking at the method descriptions if the returned Self is a copy/reference of the receiver, with the particular option mutated, or a clone with an independent option value. I tried the clone approach. I would copy the external value type, but the new values would contain a mutated clone of the internal reference type. But NWProtocolFramer.Options doesn't seem to have a clone initializer, and it doesn't conform to NSObjectProtocol, so I have to go with the copy/reference approach. So, I would return self, but mutate the internal Framer instance's Options dictionary first? Are there any subtlies to mutating the internal Options' property dictionary?

Our macOS NEFilterDataProvider sets shouldReport = true on flow verdicts and receives NEFilterReport.Event.flowClosed in handle(_:). In testing, we have observed close reports after the owning process exits or crashes, sometimes with a short delay. Is a flowClosed report guaranteed for every TCP and UDP flow in these cases? Does the behavior differ by protocol, and is there a documented upper bound on delivery time? We also set statisticsReportFrequency = .low. Does that setting affect only periodic .statistics reports, with no effect on flowClosed delivery?

On macOS 27 the File Provider extension of our app (Secure ShellFish, an SSH client) can't connect to any host on the local network, while the containing app connects to the same host on the same Mac without problems. Local Network is enabled for the app in System Settings, but every connection from the extension fails with "Local network prohibited". It did not happen on macOS 26 and still happens on macOS 27.2 (26B123). This is hitting end users of Secure ShellFish, not just my test setup, and it has been my number one support issue since macOS 27 was released. I filed this as FB24999927 with a sysdiagnose. I'm posting here to find out whether others with File Provider (or other) extensions see the same, and whether there is anything on our side that should make it work. Steps Install the app on a clean macOS 27 system and launch it. Choose Allow at the Local Network prompt. Add an SSH server on the local network (another Mac in my test) and open a terminal to it. This works. Open the same server in Finder (the File Provider domain under ~/Library/CloudStorage). The directory listing fails. What happens TN3179 says "In general, app extensions share the Local Network privilege state of their container app", so I expected the listing to load. Instead every connection from the extension to the LAN host is blocked, and the error depends on the networking API: CFStream: ENETDOWN (50) "Network is down" BSD socket connect(): EHOSTUNREACH (65) "No route to host" Network.framework (NWConnection, multipath TCP): waits with path unsatisfied (Local network prohibited) until our connect timeout, ETIMEDOUT (60) No Local Network prompt appears. Toggling the permission, rebooting, killing the extension process and reinstalling the app don't help. What I ruled out A stale extension process: freshly launched extension processes are blocked on their very first connection. A missing UUID cache: after installing a new build, nehelper populates the cache for the app with 14 UUIDs, including both slices of the extension's executable. The extension was blocked 23 seconds later. Shared executable UUIDs: the app and the extension have distinct Mach-O UUIDs. The sandbox: the extension has com.apple.security.network.client. A missing usage string: adding NSLocalNetworkUsageDescription to the extension's Info.plist changed nothing, with no prompt and no separate entry in System Settings. Networking in general: the extension reaches internet hosts and the Mac itself by its local name. Only other hosts on the local network are blocked. Log The blocked notification arrives with bundle_id: (null). UserEventAgent then maps the extension to the app by its UUID, nehelper answers that local network is allowed by preference, and the handler is called with the newly allowed state. Later connections from the same process are still blocked, so that state never takes effect for the extension. 09:19:37.575 UserEventAgent Got local network blocked notification: pid: 4297, uuid: 183484C2-8052-36AD-A81E-B02F15F875B3, bundle_id: (null) 09:19:37.575 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish.mac-provider by PID 09:19:37.575 ShellFish-Finder [C1.1.1 IPv6#dace0833.22 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] 09:19:37.576 UserEventAgent LocalNetwork: found bundle id com.appliedphasor.secure-shellfish by UUID 183484C2-8052-36AD-A81E-B02F15F875B3 09:19:37.597 nehelper UUID cache hit for com.appliedphasor.secure-shellfish 09:19:37.597 nehelper Local network allowed by preference for ShellFish (com.appliedphasor.secure-shellfish) 09:19:37.597 UserEventAgent App got response: 1 09:19:37.597 UserEventAgent Calling handler with newly allowed state: 1 09:19:44.795 fileproviderd populate-directory error: FP -1004 "Unable to list p5.local: Unable To Connect To P5.Local: Network Is Down."Questions Is this a known change in macOS 27? FB24035385 (helper and child processes no longer inherit Local Network access on macOS 27) sounds related, and other File Provider apps report the same, for example nextcloud/desktop#10885: https://github.com/nextcloud/desktop/issues/10885 Does an extension need anything on macOS 27 to share its container's Local Network privilege, such as an entitlement, an Info.plist key, or something the app must do first? If not, is there a supported workaround? The only one we see is to relay the extension's traffic through the main app over loopback, which only works while the app is running. For these users Finder integration is completely broken, because servers on the local network (Raspberry Pi, NAS, home servers) are the most common setup among them. Any pointers are much appreciated.

Hello ! following up from a related thread (account transfer issue, now resolved: https://developer.apple.com/forums/thread/843546?answerId=911820022), but this is a distinct, new issue so starting fresh as suggested. The extension launches fine, XPC handshake succeeds, and PIR registration completes successfully. But the subsequent NEPIRChecker status check fails every time (retried repeatedly over several minutes, same result each time): PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x677037cf0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}>Config being registered (confirmed from the logs): pirServerURL = https://pir.dropbet.app/ pirPrivacyPassIssuerURL = https://pir.dropbet.app/issueBoth endpoints are live and were already validated as part of the original NEURL Filter configuration approval. I've captured a sysdiagnose from the device right when this was happening, so I have that ready to attach to a bug report if useful — just let me know and I'll file one. Any idea what CipherML error 1100/1800 typically indicates?

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

Background We are developing Share&Share, an offline device-to-device content transfer application. An iPad automatically joins a nearby Samsung Android LocalOnlyHotspot. The hotspot credentials are delivered through an authenticated, encrypted Bluetooth Low Energy (BLE) session. On iPadOS, our application decrypts the credentials natively in Swift and uses NEHotspotConfigurationManager.apply() to join the hotspot. We are investigating an intermittent connection problem during the initial automatic join. We have also submitted a private report through Apple Feedback Assistant: Feedback ID: FB25408475 Test environment Receiver: Physical iPad with a Home button. Sender/hotspot: Samsung SM-E055F. Android version: Android 16. Hotspot security: WPA2/WPA3 transition configuration. iOS implementation: Swift and NetworkExtension. joinOnce = false. The hidden property is not explicitly set. Observed behaviour Two independently instrumented automatic-join sessions showed a similar sequence: A1: The iPad associates with the Samsung hotspot and completes the WPA3 authentication exchange recorded by the Samsung. Approximately 3.35 seconds after the iPad-side join completion, iOS records a beacon-loss/roam declaration and the connection drops. A2: iOS attempts to reconnect, but the authentication exchange does not complete. A3: iOS automatically reconnects successfully, obtains a DHCP address and remains connected during the observation period. The same encrypted credentials work during both the initial and subsequent successful attempts. The apply() completion handler returns without an error. We understand that this does not establish that the device has joined successfully or that local IP connectivity is ready. What we have investigated The first join used cached beacon information approximately eight seconds old; the subsequent successful join used fresh scan information. AWDL activity was observed, but we have not established a causal relationship. Location Services scanning does not explain the first failure in our second instrumented session. The diagnostic label "Beacons Lost" is not being treated as proof of actual missed beacon frames. We have not independently established which WPA mode the iPad negotiated. We have not yet measured TCP readiness during the failed and successful attempts. We do not currently have a standalone minimal Xcode reproduction project. The behaviour was observed using our Flutter-based iOS probe and physical devices. Questions for developers familiar with NetworkExtension Has anyone observed intermittent first-join instability with NEHotspotConfigurationManager when joining a newly created Android LocalOnlyHotspot using WPA2/WPA3 transition mode? Are there documented limitations or known issues involving the first automatic join to a newly created hotspot profile? What is the recommended supported approach for determining that the intended Wi-Fi network is genuinely connected after apply() completes? What is the most reliable way to establish that local TCP communication is ready before beginning an application-level transfer? Are there additional public diagnostic facilities or measurements that could help distinguish Wi-Fi association instability from DHCP or subsequent network-path problems? We are looking for a documented, App Store-compatible approach. We are not assuming a particular root cause and do not want to rely on private APIs or undocumented system behaviour. Any practical experience or pointers to relevant Apple documentation would be appreciated.

On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.

I'm building a macOS network monitor using NEFilterDataProvider as a system extension, distributed with Developer ID signing. On macOS 26.3 (Tahoe), sysextd consistently rejects the activation request with "no policy, cannot allow apps outside /Applications" — despite the app being in /Applications and passing every verification check. I'm aware of the known Xcode NE signing bug (r. 108838909) and have followed the manual signing process from Exporting a Developer ID Network Extension. I've also tried both xcodebuild build and xcodebuild archive workflows — identical failure. Environment macOS 26.3 (25D125), SIP enabled Xcode 26.3 (17C529) Hardware Apple M2 Pro Certificate Developer ID Application (issued Jan 30, 2026 — 27 days old) MDM/Profiles None installed Signing & Verification (all pass) $ spctl -a -vv /Applications/Chakshu.app /Applications/Chakshu.app: accepted source=Notarized Developer ID origin=Developer ID Application: ROBIN SHARMA (R65679C4F3) $ codesign --verify --deep --strict -vv /Applications/Chakshu.app /Applications/Chakshu.app: valid on disk /Applications/Chakshu.app: satisfies its Designated Requirement $ xcrun stapler validate /Applications/Chakshu.app The validate action worked! App signing: Authority=Developer ID Application: ROBIN SHARMA (R65679C4F3) Authority=Developer ID Certification Authority Authority=Apple Root CA TeamIdentifier=R65679C4F3 Runtime Version=26.2.0 Notarization Ticket=stapled App entitlements: com.apple.application-identifier = R65679C4F3.dev.indrasvat.chakshu com.apple.developer.team-identifier = R65679C4F3 com.apple.developer.system-extension.install = true com.apple.developer.networking.networkextension = [content-filter-provider-systemextension] keychain-access-groups = [R65679C4F3.*] Extension signing: Same Developer ID authority, same team, same timestamp. Extension entitlements match (minus system-extension.install). Developer ID provisioning profiles are embedded in both app and extension. What sysextd logs Captured Feb 26, 2026 from log stream --predicate 'process == "sysextd"': sysextd [com.apple.sx:XPC] client activation request for dev.indrasvat.chakshu.filter sysextd attempting to realize extension with identifier dev.indrasvat.chakshu.filter sysextd (Security) SecKeyVerifySignature ← pass (×2) sysextd (Security) SecTrustEvaluateIfNecessary ← pass (×2) sysextd [com.apple.xpc:connection] activating connection: name=com.apple.CodeSigningHelper sysextd [com.apple.xpc:connection] invalidated after the last release sysextd no policy, cannot allow apps outside /Applications sysextd [com.apple.sx:XPC] client connection invalidated Signature and trust evaluation pass. CodeSigningHelper completes. Then the policy check fails. The app receives OSSystemExtensionError code 4 (extensionNotFound). What I've tried and ruled out Build process: Approach Result xcodebuild build -configuration Release + manual re-sign Same failure xcodebuild archive + export from archive + manual re-sign (per thread/737894) Same failure Minimal hand-crafted Xcode project (no xcodegen, trivial code) Same failure Both workflows follow Quinn's process exactly: build with Apple Development → copy app → embed Developer ID provisioning profiles → re-sign inside-out (extension first, then app) with -systemextension suffix entitlements → notarize → staple → install to /Applications. System-level checks: Rebooting — no change Killing sysextd — no change Removing com.apple.quarantine xattr — no change chown root:wheel on app bundle — no change lsregister -r (reset Launch Services) — no change Waiting 27 days for certificate propagation — no change Reinstalling via Finder drag-to-Applications — no change No MDM or configuration profiles installed /Library/SystemExtensions/db.plist shows extensionPolicies: [] (empty) Key observation Pre-existing network extensions activated before macOS 26 work fine on this machine. For example, Tailscale's NEPacketTunnelProvider shows state: activated_enabled in the system extensions database — it was activated on a prior macOS version and is still running. Only new system extension activations fail. I've seen similar Tahoe-specific reports from LuLu (same NEFilterDataProvider type, Developer ID distribution): LuLu #825 LuLu #831 Questions Is this a known regression in macOS 26's sysextd policy evaluation for new Developer ID system extension activations? sysextd's policy check fails after all signature and trust evaluation succeeds. Is there a separate trust/policy path that sysextd consults beyond what spctl, codesign, and CodeSigningHelper verify? Is there anything else I should be checking? I have a sysdiagnose captured immediately after the failure, a minimal reproducer project, and full raw sysextd logs available on request.

Body: I’m building a Developer ID app (distributed outside the Mac App Store) that ships a packet-tunnel system extension. The extension fails at activation with: Extension not found in App bundle. Unable to find any matched extension with identifier: com.hawksnestsoftware.securityhawkvpn.tunnel Setup App: com.hawksnestsoftware.securityhawkvpn, Developer ID Application, team A5WW6PA8WT, hardened runtime, notarized and stapled, installed at /Applications/SecurityHawk VPN.app Extension: Contents/Library/SystemExtensions/PacketTunnel.systemextension, identifier com.hawksnestsoftware.securityhawkvpn.tunnel, CFBundlePackageType = SYSX. codesign --verify --strict passes, and the signature matches its designated requirement. Entitlements: the app has com.apple.developer.system-extension.install, and its embedded provisioning profile grants it. The extension has com.apple.developer.networking.networkextension = packet-tunnel-provider-systemextension. The app calls OSSystemExtensionRequest.activationRequest(forExtensionWithIdentifier:queue:) and the request fails with the error above. Machine: MacBookPro15,3, macOS 15.8.2 (24H232), Xcode 16.4. What I’ve ruled out Sandbox on and off (the error is the same either way) Signing and strict verification The embedded profile’s system-extension entitlement A duplicate Debug copy of the app elsewhere on disk (Spotlight finds only the /Applications copy) A restart before retesting Observed systemextensionsctl list shows no registration for the extension after the failed request. log show and log stream filtered on sysextd show no entries for the request. Question: What causes sysextd to report that it cannot find an extension in the app bundle when the bundle, identifier, and signature all look correct? Is there a required build setting or Info.plist key for a Developer ID system extension that I may be missing? Error seen: Error: “Extension not found in App bundle. Unable to find any matched extension with identifier: com.hawksnestsoftware.securityhawkvpn.tunnel” App: com.hawksnestsoftware.securityhawkvpn, Developer ID, team A5WW6PA8WT, notarized and stapled, installed at /Applications/SecurityHawk VPN.app Extension: Contents/Library/SystemExtensions/PacketTunnel.systemextension, identifier com.hawksnestsoftware.securityhawkvpn.tunnel, CFBundlePackageType SYSX, valid and matching its designated requirement Entitlements: app has com.apple.developer.system-extension.install and the embedded profile grants it; the extension has packet-tunnel-provider-systemextension Machine: MacBookPro15,3, macOS 15.8.2 (24H232), Xcode 16.4 Observed: systemextensionsctl list shows no registration; sysextd logs show nothing for the request Codesign command: denisarsenault@Deniss-MacBook-Pro-2 ~ % codesign -d --entitlements :- "/Applications/SecurityHawk VPN.app/Contents/Library/SystemExtensions/PacketTunnel.systemextension" Executable=/Applications/SecurityHawk VPN.app/Contents/Library/SystemExtensions/PacketTunnel.systemextension/Contents/MacOS/PacketTunnel warning: Specifying ':' in the path is deprecated and will not work in a future release <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string>A5WW6PA8WT.com.hawksnestsoftware.securityhawkvpn.tunnel</string><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array><key>com.apple.developer.team-identifier</key><string>A5WW6PA8WT</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/></dict></plist>denisarsenault@Deniss-MacBook-Pro-2 ~ %

I'm developing a macOS app using a Network Extension Packet Tunnel Provider. The System Extension activates successfully, but NETunnelProviderManager.saveToPreferences() consistently fails with permission denied. Environment macOS virtual machine running under UTM Host app and embedded Packet Tunnel System Extension signed with Developer ID App notarization verified successfully System Extension status: [activated enabled] Packet Tunnel has com.apple.security.app-sandbox=true and com.apple.security.network.client=true Host app has the Network Extension entitlement Reproduction Launch the installed, notarized HostApp. Call NETunnelProviderManager.loadAllFromPreferences(). No manager matching the Packet Tunnel provider bundle identifier is found. Create a NETunnelProviderManager. Configure NETunnelProviderProtocol with the Packet Tunnel provider bundle identifier and a server address. Set localizedDescription and isEnabled = true. Call saveToPreferences(). Observed result On October 30, 2026, the following events were recorded: 11:25:32.643 PROTOTYPE_MANAGER_CREATED 11:25:32.643 PREFERENCES_LOADED 11:25:32.643 PROTOTYPE_VPN_AUTH_SKIPPED 11:25:32.646 Saving configuration ... with existing signature (null) 11:25:33.766 NEConfigurationErrorDomain Code=10 "permission denied" 11:25:33.766 NEVPNErrorDomain Code=5 "permission denied"The app never reaches startVPNTunnel(). What I've already checked Developer ID code signing verification succeeds. Notarization and stapler validation succeed. The System Extension is activated and enabled. The failure reproduces both with and without created.loadFromPreferences() before saving. An explicit VPN authorization step is disabled in these reproduction runs. Questions What conditions can cause NEConfigurationErrorDomain Code=10 when a newly created NETunnelProviderManager is saved? Are there additional signing, entitlement, authorization, or configuration requirements for a Developer ID-distributed macOS Packet Tunnel app? Which NetworkExtension or nehelper diagnostics would help identify the specific permission check that fails? Is there any known difference in this behavior when running under macOS virtualization? I can provide a minimal reproduction project, sanitized logs, entitlement output, and a sysdiagnose privately if necessary. Thank you for your guidance.

On watchOS 27, a third-party watch app that advertises an application service with NWListener (default NWParameters.applicationService, service declared in NSApplicationServices → Advertises) is never advertised: the advertiser path is denied by NECP policy. As a result, when a tvOS app presents DDDevicePickerViewController and the user selects the watch and taps Connect on the watch, sharingd finds no listener (listenerID (null)), the pairing times out after ~30 s, and the tvOS picker's endpoint never returns — neither an endpoint nor an error. Raw lines: watchOS 26.6 (success, pid 267) 16:00:55.891 AppleWatch[267] -[_NWAdvertiser start] [L1] Starting advertiser 16:00:55.891 AppleWatch[267] -[_NWAdvertiser updateFlows:]_block_invoke [L1] Added listener flow ID 667B9945-… 16:00:55.926 rapportd[48] Found registered listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=0A1149F2-… : ageOut=179s agentClient=0x0 { 'kebike' } 16:00:55.927 rapportd[48] Updated RPNWAgentClient[0x176cc550] (LSTNR): < appSvc=com.fitonapp.fiton.FitOnWorkout PID:267 entitled=0 … browseToken=[pid:267,id:667B9945] … > 16:00:55.930 rapportd[48] [pid:267,id:A20E8919] createListenerFramer calling assign with local endpoint=::.51714 16:01:09.956 rapportd[48] [pid:267,id:F7883D0D] ADVERTISE: Start advertise 'FitOnWorkout' request QUIC=NO isTCP=YES params:[tcp, pid: 267, local: ::.51714, …] 16:01:29.352 rapportd[48] Created incoming RPNWConnection[CONN[5BCD2213-…] (IN): … appSvc=com.fitonapp.fiton.FitOnWorkout … EP={kebike:…}] 16:01:29.399 rapportd[48] [pid:267,id:3346E704] assigning connection ::.51714 <-> app_svc: com.fitonapp.fiton.FitOnWorkout, service_id: D2D4D049-… 16:01:29.404 AppleWatch[267] nw_connection_report_state_with_handler_on_nw_queue [C2] reporting state ready Raw lines: watchOS 27 (failure, 10-21) 16:00:48.761 AppleWatch[556] -[_NWAdvertiser start] [L1] Starting advertiser with descriptor: FitOnWorkout scope:3f … 16:00:48.761 AppleWatch[556] -[_NWAdvertiser updateFlows:] [L1] Listener skipping advertise flows due to unsatisfied path with policy drop 16:00:48.760 rapportd[98] [pid:556,id:C1D4B82D] createListenerFramer: incorrect agent type ← never upgraded to LSTNR afterwards … 16:05:37.919 sharingd[458] setupDDUIListenerIfNeeded, incoming pairing session … ← TV's pairing request did arrive 16:05:40.538 sharingd[458] Attempting to launch application com.fitonapp.fiton.watchkitapp 16:05:40.688 rapportd[98] Searching for listener agent client with appSvc='com.fitonapp.fiton.FitOnWorkout' 16:05:40.688 rapportd[98] Created new listener RPNWListener[…][com.fitonapp.fiton.FitOnWorkout]=F625EFB1-… : ageOut=180s agentClient=0x0 { } ← no FitOnWorkout ADVERTISE afterwards; the listener never gets the app's agent client

Hello Apple networking team and fellow developers, Summary We are investigating increased Wi-Fi login and reconnection timeouts after users upgrade to iOS 27. Some players report repeated reconnection failures during battles, preventing completion and potentially losing Star Hunt points. The root cause is not confirmed. 1. Wi-Fi timeout rates by OS version +------------+------------------------+--------------+ | OS version | Timeouts / online hour | Dates (2026) | +------------+------------------------+--------------+ | iOS 26.x | 0.086 | Oct 8-21 | | iOS 27.0 | 1.779 | Oct 8-21 | | iOS 27.0.1 | 1.737 | Oct 8-21 | | iOS 27.2 | 1.437 | Oct 26-28 | +------------+------------------------+--------------+The 27.2 observation cutoff is October 28, 14:15 UTC+8. The earlier iPhone comparison showed approximately 20 times as many Wi-Fi login/reconnection timeout records per online hour on 27.0/27.0.1 as on 26.x. Comparison limit: The 27.2 row uses a different population and observation window. It is not a direct before/after upgrade comparison. 2. Paired comparison: 27.0.1 → 27.2 We separately compared 51 paired iPhone account/device samples: the same account and device, game package version 1.9.1, and 24 hours before and after the first observed 27.2 event. Each side required at least 30 minutes of Wi-Fi online time. These samples first reported 27.2 on or after October 26. +------------------------+----------------+-------------+ | Metric | Before: 27.0.1 | After: 27.2 | +------------------------+----------------+-------------+ | Wi-Fi online hours | 96.69 | 91.05 | | Timeout records | 142 | 45 | | Timeouts / online hour | 1.47 | 0.49 | | Samples with timeouts | 17 / 51 | 6 / 51 | +------------------------+----------------+-------------+This small paired sample suggests an initial improvement of approximately 66%, but failures remain. Measurement limits: Both tables count application-level timeout records, including repeated retries, rather than independent disconnections. The 27.2 sample and observation period are limited. Our OS-version telemetry does not distinguish beta/RC builds from final builds sharing the same version string. 3. Other observations Earlier cohort comparisons did not show a comparable increase over 4G/5G. Wi-Fi-only iPad models are also affected, so switching to the device's own cellular connection cannot explain all cases. Ordinary request errors did not increase to the same extent as login/reconnection timeouts. Connection recovery is an investigation lead, not a confirmed cause. Our iOS HTTP requests use NSURLSession. Current application telemetry does not retain enough native NSError details to identify whether DNS, TCP, TLS, or another stage is responsible. 4. Questions for Apple Are there known iOS/iPadOS 27 changes or regressions involving Wi-Fi connection recovery or NSURLSession that could fit this pattern? Are there relevant fixes in 27.2, or specific OS builds we should compare? Which diagnostics should we collect from affected physical devices (for example, a CFNetwork diagnostic profile, sysdiagnose, or URLSessionTaskMetrics), and how should we submit them privately? We are looking for a systematic way to isolate the cause rather than assuming all cases share one OS bug. Any guidance would be appreciated.

Since the framework manages the lifetime of an instance of a type conforming to NWProtocolFramerImplementation, plus the streaming of input and output into/from the instance, how can testing be done? My example type needs a StreamProtocol object for the underlying bytes; can mocks be created?

In August 2026 we requested the Local Push Connectivity entitlement. On September 12 we received two emails one minute apart: the automated "Network Extension (additional values) entitlement confirmation" from developer@email.apple.com, followed by a reply from Local Push Review ("Re: Requesting Network Extension App Push Entitlement") stating the request was "approved for development and testing purposes only. If and when you have a product ready for the store, please resubmit your request and include a description of your product." We built the NEAppPushProvider, tested it on the vessel's Wi-Fi, and resubmitted through the same request page on September 15. On October 20 we received only the same automated "Network Extension (additional values) entitlement confirmation" — identical wording to September 12 — and no reply from Local Push Review. Since the same automated confirmation accompanied the development-only approval, we can't tell what the October 20 assignment means. The App ID editor shows Network Extension (additional values) either way. Is our resubmission approved for App Store distribution, or is it still pending review? Our team ID is M4S46K7L33.

Hi, I am using Apple's Network.framework APIs, specifically NWConnection and NWListener over UDP, in my project. Both APIs use state-update handlers, and I would like to clarify a few aspects of their lifecycle and callback-delivery semantics. Are .failed and .cancelled delivered only once during the lifecycle? For a given NWConnection or NWListener instance, my understanding is that .failed is a terminal state and the object does not recover from it. Is .failed guaranteed to be delivered at most once during the lifetime of an instance? If the object enters .failed, can I call cancel() on that same instance? If so, will the state-update handler subsequently receive .cancelled? Is .cancelled guaranteed to be delivered at most once per instance, even if cancel() is called multiple times? If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance? Since there is no transition from .cancelled -> .failed? What happens when stateUpdateHandler is replaced while callbacks are pending? Consider the following scenario: I create an NWConnection and assign a stateUpdateHandler (Handler A). The connection's state changes, and a callback for Handler A is enqueued on the connection's associated DispatchQueue. Before that queued callback executes, I replace stateUpdateHandler with Handler B. If the callback for Handler A was already enqueued before the handler was replaced, will Handler A still be invoked? My understanding is Yes, since it was already queued. If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance Can the same state notification be delivered to both Handler A and Handler B, or is it delivered to only one of them i.e., Handler A, since during the state-change Handler A was the one as stateUpdateHandler? Thanks!