I'm developing an iOS app that aims to manage network usage on an iPhone acting as a Personal Hotspot. I'd like to know whether there is a supported public API that allows a third-party iOS app running on the host iPhone to limit the download speed of devices connected through Personal Hotspot. For example, I'd like to limit the download speed of tethered devices to a maximum of 1 Mbps, without limiting the host iPhone's own network traffic. Is this technically possible using public iOS APIs, or is this type of bandwidth control restricted to the system? Thank you for your guidance.

Steps to reproduce: Open captive network (DHCP + DNS → portal, hotspot-detect.html returns 302). Scan the Wi-Fi QR code with Camera and tap "Join". Stay in Camera. Expected: CNA is presented after a Camera-initiated join, as it is after a join from Settings > Wi-Fi. Actual: CNA is not presented until the user manually opens Settings > Wi-Fi. Impact: In-flight Wi-Fi with no internet, where the portal is mandatory. QR codes are the only onboarding method, and most users stay in Camera. Environment: iOS 18.7, iPhone 15 Pro max Questions: Is there any supported way to have the CNA presented after a Camera-initiated Wi-Fi join, without requiring the user to open Settings or Safari? If not, is this expected behavior, or a bug worth tracking?

We're moving our VPN client's firewall off pf (TN3165) and, following the advice in https://developer.apple.com/forums/thread/781996, relying on enforceRoutes plus a content filter. That works well for keeping traffic in the tunnel, but it has a side effect we can't work around. We add excluded routes at runtime (hostname-based split tunnelling), so the provider calls setTunnelNetworkSettings while connected. With enforceRoutes = true, any connected socket to a tunnelled destination (TCP, or UDP after connect()) that sends during the update gets EPIPE and stays broken until the app reopens it. It happens with identical settings too, and the EPIPE raises SIGPIPE, so apps that don't ignore it are terminated. From a sysdiagnose, every update logs "Resetting the virtual interface", the utun's address is removed and re-added about 5 ms later, and a socket that sends in that gap is marked defunct by necp_socket_find_policy_match ("Marking socket in state 258 as defunct"). With enforceRoutes = false nothing dies, but packets for tunnelled destinations leave on the physical interface during the update. It reproduces on macOS 15.7, 26.5, 27.0 and 27.2 beta 3 (26B5101f). I filed FB25176278 with a minimal sample (a packet tunnel provider that echoes UDP, so no server is needed) and a sysdiagnose from 27.2 beta 3. Two questions: Is there a supported way to change excludedRoutes on a running tunnel without the interface reset? If not, is there anything a provider can do to avoid this today, short of not updating routes while connected? Thanks!

Hi, We're in the process of following Apple’s guidance on transitioning away from Packet Filter (pf) and migrating to a Network Extension-based solution that functions as a firewall. During this transition, we've encountered several limitations with the current Content Filter API and wanted to share our findings. Our VPN client relies on firewall functionality to enforce strict adherence to split tunneling rules defined via the routing table. This ensures that no traffic leaks outside the VPN tunnel, which is critical for our users for a variety of reasons. To enforce this, our product currently uses interface-scoped rules to block all non-VPN traffic outside the tunnel. Replicating this behavior with the Content Filter API (NEFilterDataProvider) appears to be infeasible today. The key limitation we've encountered is that the current Content Filter API does not expose information about the network interface associated with a flow. As a workaround, we considered using the flow’s local endpoint IP to infer the interface, but this data is not available until after returning a verdict to peek into the flow’s data—at which point the connection has already been established. This can result in connection metadata leaking outside the tunnel, which may contain sensitive information depending on the connection. What is the recommended approach for this use case? NEFilterPacketProvider? This may work, but it has a negative impact on network performance. Using a Packet Tunnel Provider and purely relying on enforceRoutes? Would this indeed ensure that no traffic can leak by targeting a specific interface or by using a second VPN extension? And more broadly—especially if no such approach is currently feasible with the existing APIs—we're interpreting TN3165 as a signal that pf should be considered deprecated and may not be available in the next major macOS release. Is that a reasonable interpretation?

Hi Apple engineers and developers, I am developing a consumer digital-wellbeing app called Ghostie and am trying to determine the correct Apple-supported architecture for its iOS version before continuing implementation. Ghostie's core functionality is to let the user temporarily disconnect selected third-party apps from the Internet while keeping the rest of the device online. For example: WhatsApp: blocked Instagram: blocked Slack: blocked Maps: remains online Banking: remains online Music: remains online On Android, this is implemented using VpnService with per-app traffic handling. For iOS, I have been researching Network Extension, including: NEFilterDataProvider / NEFilterControlProvider content-filter-provider NETunnelProvider / packet-tunnel-provider per-app VPN configurations Apple's current documentation appears to indicate restrictions around per-app configurations and content filtering on iOS, including managed/supervised-device requirements in certain cases. My question is specifically about a normal consumer application distributed through the App Store, where the user owns and controls their personal device and Ghostie is not an MDM/enterprise product. Is there currently an Apple-supported API, entitlement, or Network Extension architecture that would allow Ghostie to: identify selected installed third-party apps; prevent those selected apps from establishing network connections; leave all other apps' network connectivity unaffected; and allow the user to turn this blocking on and off from Ghostie? If this is not possible for an ordinary consumer App Store application, could an Apple engineer please confirm which specific iOS restriction prevents it and whether there is any alternative supported architecture? I am trying to establish the technically and commercially viable architecture before implementing the iOS version. Thank you!

Feedback ID: FB25211847 Since 2026-10-11 the root DNSKEY RRset is signed only by KSK-2024 (key tag 38696). With DNSSEC required using nw_parameters_set_requires_dnssec_validation(parameters, YES), mDNSResponder fetches the full chain (icann.org A/DNSKEY/DS, org DNSKEY/DS, root DNSKEY) from the local resolver. All records are present and all signatures validate. After the root DNSKEY query concludes, no validation result is logged, no result or error is delivered to the getaddrinfo request, and later requests for the same name attach as duplicates to the stuck questions and also never return. Without DNSSEC required, the connection succeeds immediately. Suspected cause: KSK-2024 missing from the built-in trust anchors. Secondary issue: validation failure is not reported to the client; the request hangs indefinitely.

Title: NEFilterDataProvider — fail-closed behaviour after provider crash or suspension I'm investigating the documented failure behaviour of NEFilterDataProvider on macOS. For a content filter handling outbound socket flows: If the data provider process crashes, is terminated, or disconnects unexpectedly, what happens to existing allowed, paused and partially released flows? If the provider is suspended or its callback queue stops making progress, does macOS retain existing verdicts indefinitely, block further data, or apply some other behaviour? Can an existing passBytes allowance remain usable after the provider becomes unavailable? Is there a supported mechanism for independently confirming that all relevant existing flows and outstanding release allowances have been fenced? I'm particularly interested in documented guarantees, rather than implementation behaviour observed in individual tests. Any relevant Apple API documentation or technical clarification would be appreciated.

Windows 11 Pro 25H2 – Bonjour 3.1.0.1 / mdnsNSP.dll – Code Integrity Event ID 3033 Hello Apple Developer Community, I am seeking technical assistance with a persistent Windows Code Integrity event involving Apple's Bonjour for Windows, specifically mdnsNSP.dll. PowerShell diagnostics, signature checks, service checks, Winsock inspection, and Event Viewer analysis have not yet established a permanent fix. I would appreciate guidance from Apple engineers or developers familiar with Bonjour, Winsock Name Space Providers, and Windows signing policies. 1. SYSTEM Windows 11 Pro 25H2, build 26200 iTunes 12.10.11.2 (classic Windows desktop application) Bonjour 3.1.0.1 Bonjour directory: C:\Program Files\Bonjour\ Affected file: C:\Program Files\Bonjour\mdnsNSP.dll Reported DLL version: 3.1.0.1; reported date: August 12, 2015 iTunes manages a large local music library. The existing iTunes application, its library database, metadata, and media files must be preserved. I do not want to migrate to Apple Music or Apple TV. 2. ERROR AND EVIDENCE Windows Event Viewer reports: Provider: Microsoft-Windows-CodeIntegrity Event ID: 3033 Affected process: C:\Windows\System32\svchost.exe Referenced DLL: C:\Program Files\Bonjour\mdnsNSP.dll The diagnostic message indicates that the DLL does not meet the Microsoft signing-level requirements of the affected process. Yet signature verification reports a valid Apple digital signature. I have not determined the precise policy requirement or root cause. A signing-level incompatibility with Windows 11 25H2 is a possibility, not an established finding. This event alone does not prove that Bonjour as a whole is broken or that the DLL has a security vulnerability. 3. FINDINGS AND CHECKS Bonjour service: startup type Automatic; status Running. mDNSResponder.exe is running. This does not prove that every Bonjour component works. mdnsNSP.dll: publisher Apple; digital signature reported Valid. Winsock catalog: two entries reference mdnsNSP.dll. Whether these are expected separate registrations is not yet established. Examined Bonjour components, versions, service and process status, digital signatures, Windows networking configuration, Winsock catalog, and Event Viewer using PowerShell and Windows tools. No permanent repair has been confirmed. No broad Winsock reset or speculative registry modification is desired. 4. QUESTIONS 1) Is Bonjour 3.1.0.1, especially mdnsNSP.dll, known to have a compatibility or signing-level issue on Windows 11 25H2? 2) Why might an Apple-signed DLL with a valid Authenticode signature not meet the signing-level requirements of the svchost.exe process attempting to load it? Which diagnostics identify the exact policy? 3) What is the latest Apple-supported Bonjour version for this Windows environment? Is there a supported repair or update path independent of classic iTunes? 4) Is it normal for mdnsNSP.dll to appear twice in the Winsock catalog? If so, why? 5) Can Bonjour be repaired or reinstalled without modifying iTunes 12.10.11.2 or its library, and without disrupting other Winsock providers or network services? 6) Would the full Event ID 3033 XML, DLL signature details, and relevant Winsock entries help Apple determine the root cause? I can share appropriately redacted diagnostics on request. 5. SECURITY AND PRESERVATION REQUIREMENTS I am looking for a documented, targeted, reversible where possible, and lasting solution—not merely a way to silence Event ID 3033. Please do not recommend disabling Code Integrity, Memory Integrity, or other Windows protections. The repair must not introduce security risks or impair other applications, network providers, or Windows services. I want to retain iTunes 12.10.11.2 and the entire music library, and avoid reinstalling Windows or installing Apple Music/TV. I am comfortable running specific PowerShell diagnostics and reporting results. Personal identifiers, addresses, and unredacted logs have intentionally been excluded from this public report. Thank you for your technical guidance. REFERENCES Apple Bonjour: https://developer.apple.com/bonjour/ Microsoft Windows Security: https://support.microsoft.com/en-us/windows/security/windows-security/device-security-in-the-windows-security-app#bkmk_lsa-protection Microsoft Learn (LSA protection / Code Integrity events): https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

I'm trying to invoke a 3rd party command line tool from a launch agent to connect to a server on my LAN. It seems impossible. I have a little shell script that does what I need, and it works fine invoked in Terminal.app. The first time I run it that way I get permission prompts and I agree to them all. Subsequent invocations work. Now I put a launch agent in ~/Library/Launch Agents. It does nothing more than invoke my shell script at some specific time daily. launchd launches it, but it fails to access the LAN, with a 'no route to host' error message. The command line tool I'm trying to use is not a macOS-provided one, but one from MacPorts/HomeBrew (I tried both). It doesn't even matter which tool I'm using, I tried a very simple case of just using nc/netcat. If I use the macOS-provided nc, then I can access my LAN. If I install nc from MacPorts /HomeBrew, that nc cannot access my LAN. This I've reproed on a literally brand new Mac, then updated to newest Sequoia (15.3.2), then done all I've described above. I've ruled out DNS by working with raw IP addresses. I've disabled gatekeeper with sudo spctl --master-disable. I've tried using cron instead of launch agents, same results. I've tried codesigning with codesign -dvvv /opt/homebrew/bin/nc, no help. I've read TN3179 Understanding local network privacy. In summary: Terminal.app -> script -> macOS/brew nc -> internet/LAN = works launchagent -> script -> macOS nc -> internet = works launchagent -> script -> macOS nc -> LAN = works launchagent -> script -> brew nc -> internet = works launchagent -> script -> brew nc -> LAN = fails How can I make that last case work?

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

We run a Wi-Fi network with our own captive portal and want iOS clients to be told that Private Relay is not available here, as described in Prepare your network or web server for iCloud Private Relay and WWDC21 session 10096. Our setup: Resolver: Unbound, handed out via DHCP, with local-zone: "mask.icloud.com" always_nxdomain and local-zone: "mask-h2.icloud.com" always_nxdomain. The network is IPv4-only. The captive portal intercepts all UDP port 53 traffic and drops everything else (e.g. port 853). TCP port 53 is not served. We also tried NXDOMAIN for mask-api.icloud.com, apple-native-relay.apple.com, mask.apple-dns.net, mask-api.fe.apple-dns.net and mask-t.apple-dns.net, with no change. [Result of our resolver log: do queries for the mask hosts arrive from the test iPhone, and what do we answer? Before and after captive-portal login?] What the documentation promises: “users will be alerted that they need to either disable Private Relay for that network, or choose another network.” What happens: On [iPhone model], iOS [exact version/build], with Private Relay enabled in iCloud settings and “Limit IP Address Tracking” [on/off] for this Wi-Fi, joining our network shows no message at all. [What the user sees instead: Safari loads normally / pages fail / nothing changes.] Counter-observation: On a hotel guest network (Marriott) the same kind of device did show a notice, so the feature seems to still work on current iOS. We do not know how that network blocks Private Relay. Related reports: thread 687684 and thread 722315 describe a similar gap (network-level NXDOMAIN gives no alert, on-device DNS filtering does). Our own report: FB[number], no response so far. Questions: Which conditions must be met for iOS to show the message? Is NXDOMAIN for the two documented names enough, or does the alert also depend on other hostnames, the DNS response type (NXDOMAIN vs. NODATA), or the state of the network (e.g. before/after captive login)? Is the alert suppressed when “Limit IP Address Tracking” was turned off for that Wi-Fi earlier, or when Private Relay has already connected successfully on another network? Is the documentation still accurate for current iOS releases? If not, could it be updated?

Hello, I am writing about a Network Extension URL Filter configuration submitted through the Identity & Trust section of the CloudKit Console on 5 September 2026 Status shown: In Review / Waiting for Approval Last Modified: 5 September 2026 (unchanged since submission) It has now been 37 days with no response — no approval, no rejection, and no request for changes. The PIR server , Privacy Pass issuer and HTTP/2 OHTTP gateway have been live and serving since the day of submission, configured per the Onboarding.md guidance in Apple's PIR service example, including the apple-url-filter DNS TXT record on the service URL and the url-filter-test validation entry. Could anyone please let me know: Whether this configuration is actually in a review queue, and the expected timeframe; Whether anything further is required from our side — if so, we will act on it the same day. The URL filter is a core protection feature of our app, which is currently in App Store review; the feature stays disabled for users until this registration is approved, so the delay is holding up what we can ship. Thank you for your help.

We are observing an issue on iOS 26.6.x where the Personal Hotspot SSID stops being advertised after a period of time, making it unavailable for discovery by nearby devices. This behavior impacts our device onboarding workflow, which relies on connecting to the iPhone's Personal Hotspot. Once the SSID is no longer advertised, nearby devices are unable to discover and connect to the hotspot. Based on our testing, the behavior appears to be independent of our application and seems to be controlled by the operating system. The same behavior is observed even when our application is not running. Observed Behavior Personal Hotspot is enabled and initially discoverable. After a few minutes, the hotspot SSID is no longer visible to nearby devices. Devices can no longer discover or connect to the hotspot. Simply opening the Settings app again causes the hotspot SSID to start advertising immediately and become discoverable once more. The behavior is reproducible on iOS 26.6.x. Expected Behavior While Personal Hotspot remains enabled, the hotspot SSID should continue to be advertised and discoverable by nearby devices without requiring the user to reopen the Settings app. Alternatively, if this behavior is intentional, clarification on the expected hotspot advertisement lifecycle and any related system policies would be appreciated. Impact This issue affects workflows that depend on persistent hotspot availability for accessory provisioning and device onboarding. Users may be required to repeatedly open the Settings app to make the hotspot discoverable again, which negatively impacts the provisioning experience. Questions Is this a known change in Personal Hotspot behavior in iOS 26.6.x? Is it expected for the hotspot SSID to stop advertising after a period of inactivity? Is reopening the Settings app expected to restart hotspot advertising? Are there any new power management or system-level restrictions affecting hotspot discoverability? Is there a recommended approach for applications that depend on consistent Personal Hotspot availability during device setup?

Our app supports large-file uploads (20 GB+) and uploads of many files. We use a background URLSession so transfers can continue if the user backgrounds the app. In separate affected-device captures, Console logs and a sysdiagnose show dasd declining upload activities under Energy Budget Policy or Data Budget Policy. Upload tasks are created and resumed, but no bytes are transferred. Subsequent uploads can also remain queued, including after earlier uploads are cancelled and the app is relaunched. The issue is intermittent but can persist: one device recovered after approximately 24 hours; another remained affected for several days. We have not established what causes recovery or how the relevant budget eligibility is computed or replenished. Foreground and power observations For the energy-budget reproduction, the user kept the app foregrounded. Application lifecycle logs and RunningBoard running-active-Visible notifications corroborate foreground/active state around the affected task creation and resume operations. The rejection repeatedly reports: Energy Budget Policy [energyBudget]: Required:1.00, Observed:0.00 Decision: MNP Battery samples were approximately 68%, with Low Power Mode off. New uploads using the same session succeeded while the device was connected to external power and were rejected again after disconnection. Discretionary configuration versus daemon classification Our upload-session factory does not set isDiscretionary to true. In a separate, successful reproduction, instrumentation read isDiscretionary from the actual owning URLSession.configuration at task creation: 10:35:04.234749-0500 Frame.io: Upload task 1 created in session com.frameio.backgroundSession.diagnostics, configured isDiscretionary: false The corresponding daemon entry was: 10:35:04.245137-0500 nsurlsessiond: NDSession <8BA476D9-E790-46B6-B1DA-0246E14BBDAF> Task <1B16494D-BBE8-448F-9297-9DB8772ADD92>.<1> current discretionary status for com.frame.FrameIO is discretionary (opt-in: 0) All five tasks in that successful upload showed this combination. We do not yet have the instrumented configuration readout from the failed energy-budget reproduction. Implementation notes Large files are split into smaller files to support resumable uploads through our backend API. Each part is submitted as a file-backed upload task through the same background session, using a stable session identifier across launches. Goal User-initiated uploads make progress while the app is foregrounded and the network is available, and continue when possible after backgrounding. We understand background execution is system-controlled, but need to avoid uploads remaining stalled for days with no actionable recovery. We are considering switching between foreground and background URLsessions when the app moves between the foreground and background, but have concerns about that the bookkeeping on that path could be a brittle pattern. We have also considered using a BGContinuedProcessingTaskRequest for the entire upload, but have concerns about running into new scheduling issues there. Questions What session configuration and task-submission pattern does Apple recommend for this requirement? Is a background URLSession appropriate for both foreground and background uploading, or should we use a different architecture? Is it expected that tasks created and resumed while the app is foreground/active, with the owning session reporting isDiscretionary = false, can be blocked by Energy Budget or Data Budget Policy? If so, what supported approach allows these user-initiated uploads to progress while the app remains foregrounded? When this restriction persists across cancellation, new uploads, and app relaunch, what supported recovery mechanism should we implement? Can the app detect the restriction and take an effective action, rather than requiring external power or waiting an unknown amount of time? For 20 GB+ files and large upload batches split into file-backed tasks, are there recommended chunk sizes, outstanding-task limits, or session-management practices that prevent this failure mode? If the captured foreground behavior is unexpected, is this a known OS issue with an available fix or supported workaround? What additional evidence is needed to obtain a concrete remediation?

Hello Apple Developer Team, I am developing an iPhone application called RF Field Test for professional DAS (Distributed Antenna System) and macro cellular network technicians. The application already supports GPS location tracking, network connection detection, and cellular speed testing. To make it useful for professional RF field testing, I need access to real-time cellular measurements, including: PCI (Physical Cell Identity) Cell ID / ECI / NCI RSRP, RSRQ, and SINR LTE and NR frequency bands EARFCN and NR-ARFCN LTE / 5G NSA / 5G SA identification Channel bandwidth Serving and neighboring cell information I understand that standard public Core Telephony APIs do not expose most of these measurements. My questions are: Is there an officially supported API, entitlement, or carrier-specific development program that provides access to these measurements? Can an independent developer apply for this access, or must the application be developed through an authorized cellular carrier? Would Apple's interoperability request process be appropriate for requesting these capabilities? If these measurements are unavailable to third-party applications, is there an official recommended approach for developing professional cellular RF testing tools on iPhone? I am looking for a legitimate, App Store-compliant solution without private APIs or unsupported methods. Thank you for any guidance.

I am looking for guidance on the new Swift NetworkConnection<QUIC> DATAGRAM API. A Network.framework defect has not been established. I filed FB25125957, which includes a minimal reproducible source package and numeric evidence. Environment Apple Silicon M2, macOS 27.0.1 (26A434), Xcode 27.0 (27A266a), macOS SDK 27.0 (26A425), Swift 6.4. Builds use an explicit DEVELOPER_DIR, Swift 6 strict concurrency, and warnings as errors. Apple-to-Apple localhost case Both endpoints offer maxDatagramFrameSize(1400), explicitly start their parent connections, and wait for ready. Fresh certificate mutual TLS uses a private test root, role-specific SAN validation, and preknown exact leaf pins. No system trust or keychain modification. After ready, the client awaits parent.datagrams, then reads usableDatagramFrameSize on that same parent. The accessor returns and the getter returns 0. Both endpoints passed their current TLS 1.3 / ALPN / certificate gates, with no early data. The server getter remained unobserved when our local guard stopped this case. No DATAGRAM payload was sent. Our capability error 1005 is a local guard, not NWError. Independent-peer case One Apple listener and an aioquic 1.3.0 client, both advertising 1400, with the same current root/SAN/exact-pin authentication requirements. Both passed mutual authentication, TLS 1.3 / 0x1301 / exact ALPN, with no resumption or early data. The peer decoded Apple's remote max_datagram_frame_size=1400 (present) and recorded its own serialized offer=1400. On the same accepted Apple parent, await datagrams returned and usableDatagramFrameSize completed with 0. The peer's local serialization does not prove that Apple parsed its offer. No application DATAGRAM or media payload was sent. Questions Does ready guarantee that the peer DATAGRAM transport parameter has been processed? Does completing await parent.datagrams provide a stronger guarantee? If a zero usable capacity is transient, what supported event or API should be awaited rather than arbitrary sleeps/retries? What is the supported start/ready/datagrams ordering and parent lifetime for outgoing versus accepted connections? Is opening a reliable stream first a prerequisite? Is there a minimal certificate-TLS DATAGRAM example? Which public diagnostic can distinguish an absent/zero peer advertisement from usable-size calculation, interoperability, or lifecycle issues? Is there a known limitation in this exact OS/SDK, a fixed version, or an authentication-preserving workaround? The source and evidence are attached to FB25125957. They contain no private keys, passwords, pairing credentials, user footage, app bundles, or full qlog. I am asking about basic DATAGRAM availability, not claiming any Wi-Fi or video performance result.

On macOS 27.0.1 (26A434), a SOCKS5 proxy is applied to TCP connections but never to QUIC. This happens whether the proxy comes from a PAC file in the system proxy settings or from an explicit ProxyConfiguration. The system SOCKS5 client only ever sends CONNECT; it never sends UDP ASSOCIATE (RFC 1928, CMD 0x03), so it has no way to carry UDP. URLSession handles this by staying on TCP through the proxy. A QUIC NWConnection instead connects directly to the origin, as if no proxy were configured. Setup. The system proxy settings use a PAC URL (ProxyAutoConfigURLString in scutil --proxy; in my test it was installed through NEProxySettings.proxyAutoConfigurationURL). For the test host, a public site that serves HTTP/3, the PAC returns SOCKS5 127.0.0.1:<port>. For the explicit cases I used a local SOCKS5 server that logs every command it receives. With the system PAC, default parameters, no explicit proxy: URLSession, assumesHTTP3Capable = true: goes through the proxy over TCP (transaction metrics: h2, isProxyConnection == true, remote address 127.0.0.1:<port>). HTTP/3 isn't used, which is consistent: the proxy can't carry it. NWConnection, TLS: currentPath.remoteEndpoint is 127.0.0.1:<port>. The PAC is honored. NWConnection, QUIC (ALPN h3): .ready in about 170 ms, and currentPath.remoteEndpoint is the origin's own address. The PAC is ignored. With an explicit proxy, set via NWParameters.PrivacyContext.proxyConfigurations: QUIC with a working SOCKS5 server: .ready, and the server receives nothing — no CONNECT, no UDP ASSOCIATE. QUIC with the proxy pointing at a port nothing listens on: still .ready, still connected to the origin's own address. TLS with that same dead proxy: stays in .waiting with ECONNREFUSED. The proxy is honored for TCP. At no point did the SOCKS5 server receive a UDP ASSOCIATE request. Cases 3–5 are the concerning part. An app that configures a proxy, or a user or administrator who installs a PAC, reasonably expects traffic to go through the proxy or fail. Instead, QUIC traffic goes straight to the origin, which then sees the device's own address, and nothing in the API signals that the proxy was skipped. Minimal snippet: import Network let host: NWEndpoint.Host = "YOUR_HTTP3_HOST" // any public host that serves HTTP/3 let parameters = NWParameters(quic: NWProtocolQUIC.Options(alpn: ["h3"])) // Remove these four lines to test with the system PAC instead. let privacy = NWParameters.PrivacyContext(description: "socks5-quic") privacy.proxyConfigurations = [ ProxyConfiguration(socksv5Proxy: .hostPort(host: "127.0.0.1", port: 1099)) // nothing listens on 1099 ] parameters.setPrivacyContext(privacy) let connection = NWConnection(host: host, port: 443, using: parameters) connection.stateUpdateHandler = { state in if case .ready = state { // Prints the origin's own address. With NWParameters.tls instead of QUIC, // the same proxy configuration leaves the connection in .waiting (ECONNREFUSED). print(connection.currentPath?.remoteEndpoint as Any) } } connection.start(queue: .main) I filed this as FB24760235 on 09/13/2026 and haven't had a response, so I'd like to ask here: Is it intended that a QUIC NWConnection ignores both the system PAC and proxyConfigurations? If so, how can an app find out that a connection went direct? And shouldn't a connection that can't honor the configured proxy fail rather than bypass it? Is UDP ASSOCIATE support planned for the system SOCKS5 client, so that QUIC and other UDP traffic can follow a SOCKS5 proxy the way TCP does? Thanks!

Requirement Description The app operates as a central device. It connects to a Bluetooth peripheral via Core Bluetooth. Once connected, the peripheral enables a Wi-Fi hotspot. The app joins this hotspot and transfers data over a TCP connection. The app needs to remain active in the background until this TCP data transfer is complete.  Question Regarding the Proposed Solution One proposed approach is to have the peripheral send periodic BLE notifications (reporting transfer progress) to the app, using each notification to briefly wake the app and extend its background execution time. Would this method successfully keep the TCP connection alive in the background until the transfer finishes? Does it comply with App Store review guidelines?  Request for Alternative Solutions If this approach is not viable, could you advise on any supported mechanisms or recommended architectures that would allow a local Wi-Fi TCP data transfer to complete reliably after the app moves to the background?

Recently, I've been asking here about creating a NWProtocolFramerImplementation that splits across line breaks. Examples and questions usually involve some glob in a "while true" loop. From reading around, couldn't that function be implemented as: func handleInput(framer: NWProtocolFramer.Instance) -> Int { // Pull out objects until an incomplete object is discovered. var domainData: Data? while framer.parseInput( minimumIncompleteLength: 1, maximumLength: .max, parse: { buffer, isComplete in guard let buffer else { return 0 } // Why is `buffer` an Optional? // Other checks and computations // Mutate domainData with the result of this iteration. // Return how many bytes from the buffer are an irrevocable part of domainData. } ) { defer { domainData = nil } guard let domainData else { break } let domainMessage = //... let framerMessage = NWProtocolFramer.Message(myMessage: domainMessage) // The return value is whether or not the delivery was immediate. _ = framer.deliverInputNoCopy(length: domainData.count, message: framerMessage, isComplete: true) } return 0 } A clear separation of concerns, and makes figuring out what's going on easier.

What is the estimated timeline for Apple to implement Wi-Fi Aware Release 5 (R5) support?