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.

Hello, I submitted a Network Extension URL Filter (Oblivious HTTP) configuration in CloudKit Console almost a week ago. It still says In Review / Waiting for Approval and I haven't heard anything back since the submission notice. I wanted to check whether anything is missing on my end. Just in case, the configuration ID is 60802ed4-abfa-4b20-a64e-0d35230f478a. The app is an open-source ad and tracker blocker from the developers of an existing content blocker with a large user base. On iPhone and iPad its system-wide blocking runs entirely through the URL filter. Until the configuration is approved the iOS app can't block anything at all, and our testers are left with a Mac-only product in the meantime. Because lookups go through Apple's relay to our own PIR server, we never learn which sites anyone visits. All four endpoints have been live since the day I submitted and the TXT records are in place. Every database we build also includes the www.apple.com/url-filter-test validation entry. Is there anything else I need to provide, or a rough timeline I should expect? Thank you in advance!

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.

I have a Java Swing application that is bundled into an app bundle using jpackage. The app basically launches a newer version of itself, when there is a new version downloaded in the users installation directory. I have noticed a regression or change in behavior with how LocalNetwork privacy works now. Previously, we would launch our Java application using the .app bundle. This is a launcher that checks for updates and will launch another JVM instance using any new jars it downloads when updating. So, it is closing the original process and spawning a new process using the downloaded jar. The new process is where the app connects to a server on the Local Network. This new process cannot access the Local Network even when the entry in privacy and security is enabled for the parent process. I have changed the behavior of my launcher application so that it keeps the process alive after launching the client application. When doing this, Local Network access works. So, my question is: is it required for the parent process to be running in order for a child process to have Local Network access? In previous macOS versions, this was not an issue, so something has changed with Local Network security across all the latest versions 26 and 27.

We would like to minimise the amount of code exposed in the product we have developed and an obvious option is to configure our build setting to use the All Symbols for Strip Style. Some investigation with an AI tool reports there are possible problems doing so. ContentFilter: non-global → all — risky. The NetworkExtension and XPC subsystems load your bundle and look up classes by name through the ObjC runtime, which uses __objc_classlist and friends (not the Mach-O symbol table), so in principle all works. In practice it occasionally breaks bundle loading in edge cases. If you try this, test specifically that systemextensionsctl activates the bundle and the filter actually traps packets. Is it safe to use All Symbols with a content filter or do we need to accept Non-Global symbols? Thanks, Dave

We have an internet app that uses BLE COC to synchronize the call audio of Android devices to the iPhone side microphone. All of this functions normally, but if two conditions are met: upgrading to IOS27; Connect iPhone to headphones. So the up and down latency of our BLE COC data will be significant and increase proportionally with time. Through the analysis of the air interface logs, it can be seen that the number of retries for COC data on the air interface has significantly increased, and the interval between the other two packets is very large (far greater than the 30 millisecond conn interval). I would like to ask if Apple has adjusted the scheduling strategy of the Bluetooth controller on iOS 27, and how can we adapt to this situation? The attachment is a screenshot of the air interface log. The packet circled in the picture is sent from iPhone to Android, with an interval of 300+ms. It can be inferred that the iPhone protocol stack and Bluetooth controller have already squeezed a large amount of data, and our business bitrate is not high, only about 10K per second

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.

This is an extension of https://developer.apple.com/forums/thread/854016 I was wondering if there's a way to print out the bytes passed-through so I can check that framer's implementation. Is there an existing type for this? Or would I need to introduce one? One issue is as a base diagnosing type, I can only check this new framer for correctness through inspection. Another is if using String conversion functionality takes too much resources for a type that may be called alot. My current idea is making an inline-array of 1024 bytes, write the UTF-8 representation directly, wrapping it with a no-allocation NSString, then passing that to the logging infrastructure.

We use Local Push Connectivity (NEAppPushProvider, matchSSIDs set) to receive notifications from an on-premise MQTT broker over WebSocket (wss://host:port/mqtt). iPhone on Wi-Fi, VLAN A (SSID matches matchSSIDs) Server on wired VLAN B, routing and firewall rules allow VLAN A → VLAN B on that port Result: the containing app, in the foreground, connects successfully to wss://<VLAN B IP>:<port>/mqtt. At the same moment, the app push provider (URLSessionWebSocketTask to the exact same URL) fails with "The request timed out". The provider starts normally (start() is called). When the server has an address on the Wi-Fi subnet (VLAN A), the provider connects without any issue. Is the app push provider restricted to servers on the local subnet of the matched Wi-Fi network? If so, is this documented anywhere? If not, what could prevent the provider from reaching a routed address that the app itself can reach? iOS version: 27.0.1 device : iPhone 13

tl;dr: On iPhone Duo with connected WiFi it is not possible to fully verify/scan a NFC ePassport. On iPhone Duo (iPhone19,4, iOS 27.2), reading ePassports via NFCTagReaderSession / NFCISO7816Tag fails reproducibly while the device is connected to Wi-Fi. Access control (PACE) succeeds. During the following file reads (EF.SOD, DG2), one sendCommand call gets no response for about 2 seconds and then fails with NFCReaderError code 102 ("Tag response error / no response"). The failing command varies from run to run. After disconnecting from Wi-Fi in Control Center, the same passport reads immediately. Disconnecting is enough; Wi-Fi does not need to be turned off. The device lies still on the document in all attempts. ReadID Me, Regula Document Reader and our own app (KINEGRAM Digital Seal) all fail the same way. Filed as FB25502333 with sysdiagnose and video. This looks similar to the 2024 issue on iPhone 15 Pro / 16 Pro, where turning off Wi-Fi also helped: https://developer.apple.com/forums/thread/765855 If you see this on an iPhone Duo too, please file a Feedback and reference FB25502333.

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?

userlog.txt We've run into some HTTP request errors, details as follows: We're currently at a loss because restarting the app doesn't help, only rebooting the phone restores things to normal. Based on tracking data, the occurrence rate for users is about 0.033%, and it's only happening on iOS, Android is fine. iOS operating system versions: 14-27 are all affected. The same issue appears in Rust, Flutter, and C/C++. Rust： 2026-07-11-19:39:22.252+0800|F4E26069-2D7E-4D5F-8B53-664E012B2CA7|UPLogDefaultLogger|DEBUG|测试模式|1023629905|[userdomain_rust/rust_userdomain/src/operator/device_ops/refresh_device_list_op.rs:61]query_device_list error: HttpRequstFaild(Reqwest(reqwest::Error { kind: Request, url: "https://zj.haier.net/api-gw/wisdomdevice/device/v11/family/devices?familyId=ALL&filterFlag=false", source: hyper_util::client::legacy::Error(Connect, ConnectError("tcp connect error", 36.156.179.34:443, Os { code: 49, kind: AddrNotAvailable, message: "Can't assign requested address" })) })) Flutter： 2026-07-11-15:29:02.718371+0800|b2257ae8-f7d8-41d0-8811-2ff1824f95d9|UpPlugins|ERROR|正常模式|1023629905|level:error tag:smart_home msg:getWholeHousePreferenceSetting err: DioException [unknown]: null Error: SocketException: Connection failed (OS Error: Can't assign requested address, errno = 49), address = zj.haier.net, port = 443 C/C++： 2026-07-11-19:39:15.247588+0800|a991af96-bf02-4b94-a437-d4f7efc249ff|uSDK|ERROR|正常模式|1023629905|[CAE][[cae_sock_no_ssl_last_err:869][connect fd 122 ret -1 err 49: Can't assign requested address] ] Native iOS HTTP interface requests work fine, for example when using AFNetworking. Looking for your help~

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

Our Network Extension URL Filter configurations in CloudKit Identity & Trust are not moving through onboarding. STG: configuration 6e17673d-dbaa-4b35-98c5-ff9e7a357577, bundle ca.itellyou.stg. Submitted 2026-09-25, status Approved, Onboarding Status "Queued". PRD: configuration 06fa2558-281b-4b55-b59f-402ecf359d18, bundle ca.itellyou. Submitted 2026-10-20, status In Review. Evidence (iPhone 17 Pro Max, 2026-11-06, same commit, same server, same user token): Development-signed build: the filter reaches "running" and blocks our test domains. Ad-hoc (distribution-signed) build: it cycles starting -> stopped with NEURLFilterManager.Error 9. The PIR server, Privacy Pass issuer and OHTTP gateway are live, and the test entry www.apple.com/url-filter-test is present. An Apple engineer confirmed on GitHub (apple/pir-service-example#185) that nothing is pending on our side. We also opened support case 30000007408474. Has anyone seen how long onboarding takes these days, or found a way to get it moving?

Hello, I am wondering about the egress addresses of the Oblivious HTTP relay that Apple runs for Network Extension URL filters. I am building an iOS app that uses NEURLFilterManager. The app builds a Bloom filter from the block lists a user picks. The system only asks our server about a site when that filter has a hit. Each lookup is encrypted with keyword PIR and carries a Privacy Pass token instead of anything tied to the user. It reaches our server through your relay, which strips the device's address. We run our own PIR server, Privacy Pass issuer and OHTTP gateway instead of a hosted service. The gateway is the one part of the setup that should only ever hear from your relay. Since every real lookup comes through the relay, I would really like to drop all other traffic to it at the firewall. Right now I can't do that. I also can't rate limit by address because every legitimate request shares the relay's addresses. As a result the gateway just has to stay open to everyone and rely on global limits, which is a far cry from what I'd want for a service that only one client is meant to reach. I have three questions about this. 1) Are the relay's egress address ranges published somewhere, or can they be shared with developers who have been onboarded? 2) If they are shared, how would we find out when they change and how much notice there is? 3) If the addresses can't be shared, is there another way to tell that a request came from the relay, such as a header or a client certificate? Please let me know if any of this is unclear or if there is a better place to ask. Thank you in advance, Alexander

Filing this as a public thread to try to get DTS attention, similar to how thread 821372 (skmem_slab_free_locked double-free) got resolved - accumulated cross-referenced reports there are what got that one fixed in 26.5/26.6. Panic signature (identical every time): panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268 My own occurrences: 5 panics over 2 days on a MacBook Pro (Mac16,7 / M4 Pro), macOS 26.5.2 build 25F84, kernel Darwin 25.5.0 (xnu-12377.121.10~1/RELEASE_ARM64_T6041). Filed as Feedback Assistant report FB24343421 (5 panic logs + a full sysdiagnose attached). Why this looks like a generic kernel bug, not app-specific: I initially suspected a third-party VPN NetworkExtension (Tailscale) since it appeared in the full stackshot of every one of my panics. Ruled that out: That NE is a userspace-only component - cannot execute kernel code. Two other reporters have hit the identical panic string via completely different, unrelated paths: One reproduced it with no VPN/tunnel software running at all (engine stopped, sysext idle) - see FB24333740, cross-referenced at https://github.com/tailscale/tailscale/issues/20864 Another hit the same panic string on an Intel Mac via a third-party Ethernet kext, no VPN/utun involved at all - https://github.com/SongXiaoXi/AppleIGC/issues/34 So this reproduces through at least 3 independent producer paths (a NetworkExtension, no tunnel software at all, and a third-party Ethernet driver), which points to something generic in the TCP send path (tcp_output -> m_copym_with_hdrs) rather than anything specific to one app or extension. Known non-workarounds: net.inet.tcp.tso=0 does not avoid the code path (checked against the last public xnu source drop). No sysctl or config change has stopped recurrence for anyone who's tried. Related public reports: https://github.com/tailscale/tailscale/issues/20864 https://github.com/tailscale/tailscale/issues/20612 https://github.com/SongXiaoXi/AppleIGC/issues/34 FB24333740 (independent Feedback Assistant report, same signature) FB24343421 (mine, this thread) Still reproducing on the latest public release (26.6.1 / 25G76) per the other reporters. Happy to provide more diagnostics - this is easy to reproduce on my end, roughly every few hours to once a day under normal use.

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.

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.