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.

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.

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?

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!

Hi, in our project we use Network.framework, with NWListener and NWConnection, to send and receive data over UDP. We use the receiveMessage(completion:) API, which delivers the data as a Data object. We assign this Data to a property of one of our classes, which we continue to work with after the completion handler returns. We pass that property's bytes to our C++ code (through Swift–C++ interop) using Data.withUnsafeMutableBytes(_:). The C++ code modifies the bytes in place, and we then continue working with the modified Data in Swift. Since nothing else refers to the Data we received, the bytes are modified in place and no copy is made. However, if another Data value shared the same buffer, just calling withUnsafeMutableBytes(_:) would create a copy, whether or not we actually modified the bytes. Our understanding is that this is because the method is declared mutating, so the call itself is treated as a write and copy-on-write makes the buffer unique before the pointer is handed out. We also understand that ResultType : ~Copyable (along with the typed throws(E)) only relaxes the requirements on the closure's return type and doesn't affect this behaviour. We understand this approach is unsafe and that the pointer "should not be stored and used outside of the lifetime of the call to the closure", so we will take care of that. Since the typed-pointer variants of APIs such as Data.withUnsafeBytes were deprecated in Swift 5, we would also like to confirm that withUnsafeMutableBytes(_:), the variant that takes an UnsafeMutableRawBufferPointer, is the intended long-term API and isn't expected to be deprecated in the same way.

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

Hi Apple Developer Support / community, I am seeing a URL filter startup failure only in TestFlight builds. The same code path works in development and Ad Hoc builds. App setup: Host app bundle id: com.expleo.protectus.filter.main URL filter control extension bundle id: com.expleo.protectus.filter.main.buf Extension point: com.apple.networkextension.url-filter-control Using NEURLFilterManager / NEURLFilterControlProvider on iOS 26.x App Group and network extension entitlements are configured on host + extension Observed behavior: Extension process starts successfully (pid created) Status changes to starting Then updatePrefilterWithCompletionHandler runs Immediately after, plugin transitions to stopping with error 3 System retries in a loop Key logs: Error Domain=NEAgentURLFilterErrorDomain Code=3 Failed to startFilter NEPIRChecker start block reports: Error Domain=com.apple.CipherML Code=1100 Underlying Error Domain=com.apple.CipherML Code=1800 Message says details are redacted Example sequence: NEURLFilterPlugin ... started with pid ... status changed to starting updatePrefilterWithCompletionHandler enter acceptAgentClients enter setStatus:error ... NEAgentURLFilterErrorDomain Code=3 status changed to stopping with error 3 extension disposed / teardown repeats Important detail: This failure is reproducible in TestFlight only. Same code and configuration works in development and Ad Hoc builds. What we already checked: Extension launches and is discovered correctly by neagent App/extension bundle identifiers are correct App group and network extension entitlements are present in source and archive checks We tested startup gating around local bloom/prefilter readiness We still get NEMembershipCheckerErrorDomain Code=3 with CipherML 1100/1800 in TestFlight Questions: Is NEMembershipCheckerErrorDomain Code=3 in this startup path known to indicate PIR membership/status validation failure in distribution context? Are there TestFlight-specific prerequisites or server-side requirements for PIR/CipherML path that differ from development/Ad Hoc? Is there any supported way to get non-redacted diagnostic details for CipherML 1100/1800 (beyond sysdiagnose submission)? Are there recommended fail-open/fail-closed startup patterns when PIR status is temporarily unavailable? If needed, I can provide: Full sysdiagnose timestamped bundle Exact iOS version and device model Repro steps from clean install Full log stream around NEPIRChecker and NEURLFilterPlugin transitions Thanks in advance.

Two field incidents show an _nstat_rwlock/UDP socket mutex ABBA deadlock followed by a configd watchdog panic. Raw wait-owner records and UUID-matched KDK stacks identify the same cycle in each incident's earlier configd diagnostic and later panic. Affected systems Both kernels: xnu-13432.1.9~1. Kernel UUIDs are in the attachments. Report AReport BmacOS27.0 (26A428)27.0.1 (26A434)HardwareMac16,10 / T8132Mac15,6 / T6030CloudShell PID87443906Blocked configd threadPID 341, TID 19794593PID 113, TID 309370Our NEDNSProxyProvider can capture CloudShell's DNS UDP traffic and forward it via a separate upstream socket. Provider flows and CloudShell sockets have separate lifetimes. Symptoms and reproduction During DNS UDP forwarding and flow/socket cleanup, CloudShell blocks in final socket close. configd's IPConfigurationAgentQueue blocks creating a UDP socket: a diagnostic is captured after 60 seconds without check-ins, followed by panic/restart after 180 seconds: userspace watchdog timeout: no successful checkins from configd (1 induced crashes) in 180 secondsExpected: socket close completes or returns an error. We have no deterministic reproducer, measured failure rate, or reconstructed per-flow close history. Direct lock-owner evidence Raw waitInfo records (mutex tokens are opaque): Report A, 26A428: thread 18691491: kernel mutex 0x61c831d7f38edbc3 owned by thread 19491850 thread 19491850: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491 thread 19794593: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491Report B, 26A434: thread 36984: kernel mutex 0x44aa649ef3095ae1 owned by thread 12555 thread 12555: krwlock 0xfffffe000ca01730 for writing owned by thread 36984 thread 309370: krwlock 0xfffffe000ca01730 for writing owned by thread 36984In each incident, the first two records form a cycle in both snapshots; the third is configd. All three threads are TH_WAIT / TH_UNINT. UUID-matched kernel stacks Caller-to-callee chains; listed offsets match in both kernels. Kernel worker (A: TID 18691491; B: TID 36984): nstat_idle_check + 808 -> in_pcb_checkstate + 128 -> udp_lock + 200 -> lck_mtx_lock_contended + 1212Holds _nstat_rwlock exclusively; waits for CloudShell's UDP socket mutex. CloudShell (A: TID 19491850; B: TID 12555): soclose + 212 -> soclose_locked + 2300 -> sofreelastref + 60 -> flow_divert_detach + 332 -> in_pcbdetach + 168 -> nstat_pcb_detach + 92 -> lck_rw_lock_exclusive + 180 -> lck_rw_lock_exclusive_gen + 912Holds the socket mutex; waits for _nstat_rwlock. XNU acquires these locks, not application code. configd (downstream victim): socket_common -> socreate_internal -> udp_attach -> nstat_udp_new_pcb -> lck_rw_lock_exclusivePossible enabling condition Matched 27 KDK disassembly shows a provider CLOSE path through cfil_sock_is_dead that directly marks the PCB DEAD and schedules GC without nstat cleanup. Public xnu-12377.121.6 (26.5) uses ordinary detach first. Provider CLOSE and final fd close are distinct. A DEAD PCB can retain an nstat locus/reference. Under _nstat_rwlock, nstat_idle_check removes the locus and releases the reference via in_pcb_checkstate(..., WNT_RELEASE, FALSE), which can take the socket mutex. Final close takes the reverse order; nstat_pcb_detach requests the nstat lock even when the locus is null. This is a possible enabling path from disassembly/source analysis, not proof of the preceding provider CLOSE in either incident. The older source already has opposite static lock orders; 26.5 is not proven immune. Questions for Apple Our provider calls closeReadWithError:nil and closeWriteWithError:nil when finished, as documented for NEAppProxyFlow. This does not validate the entire asynchronous lifecycle. Is this cycle known, and is there a fixed build? How is reverse locking avoided after the direct DEAD transition? Is there a supported workaround preserving flow cleanup? Close rate-limiting is not proven to eliminate the issue. Which diagnostics would help correlate provider CLOSE, DEAD, and final fd close? Attachments and timestamps Four EXCERPT attachments contain watchdog messages, raw frames, KDK annotations, and wait-owner records. Full reports are retained for private Feedback Assistant submission. 26A428_panic_excerpt.txt 26A428_configd_excerpt.txt 26A434_panic_excerpt.txt 26A434_configd_excerpt.txt 2026-10-15, +0800: configd capture -> embedded panic event: A: 04:24:43.1258 -> 04:26:44 B: 08:49:29.4349 -> 08:51:32 Use embedded panic times, not file/header timestamps. Original pairs match on boot identity; identifiers are omitted from excerpts. Sources: NEAppProxyFlow, XNU 26.5 comparison.

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.

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

I have a free Apple Developer account and am evaluating an iPhone app that listens for LLDP frames from a USB Ethernet adapter using NWEthernetChannel. Apple’s documentation says this API requires com.apple.developer.networking.custom-protocol. Can this entitlement be used for development on a physical iPhone with free provisioning, or do I need paid Apple Developer Program membership? Does the entitlement require Apple’s approval or a capability request? Can an app with this entitlement be distributed through the App Store? I’m targeting iOS 25 and later. I can provide the adapter and iPhone models if useful.

I've been investigating memory consumption issues with a network extension. It seems as though the "leak" exists within the network extension framework. Looking at a memory graph, there appears to be a _socketFlows dictionary or similar in the network extension framework that holds all of the flows and they continue to pile up and consume memory. The problem seems to be particularly bad when I leave my MacBook plugged in and running over the weekend and come back on Monday. For instance, in that time period, the memory consumption grew from <100MB to >1GB. To try to narrow this down to see if it was an "us" problem or truly in the framework, I installed Objective-See Foundation's Lulu tool, which also uses a network extension. It similarly saw memory grow from around 30MB or less to 600MB in the same time frame. Has anyone else seen this? We do have an open feedback ticket FB18731867 that might be related that has to do with seeing multiple instances of the same data filter provider started and maybe running in a network extension.

I'm developing Androfest, a native Android app with a SwiftUI macOS companion. It provides user-authorized notification forwarding, automatic clipboard synchronization, file transfer, and phone-call controls, with experimental call-audio relay. I need a secure, direct connection between a nearby Android phone and a Mac without requiring both devices to join the same Wi-Fi network or using a cloud relay. Discovery, authenticated pairing, and a bidirectional IP data path are the requirements; application traffic uses certificate-pinned TLS. The Android side uses WifiAwareManager. My development devices are a Galaxy S24 FE running Android 16 / One UI 8 and an Apple silicon M4 Pro Mac running macOS 27.2. I read the DTS answer in “Do Mac computers support Wi-Fi Aware?” (https://developer.apple.com/forums/thread/827887), which explains that the presence of the framework for Mac Catalyst does not imply usable Wi-Fi Aware support on Mac. I am asking specifically about the provisioning information below and whether there is an approved path for this use case. In Certificates, Identifiers & Profiles → Register an App ID → Capabilities → Wi-Fi Aware, the information popover currently shows: Platform Support: iOS Provisioning Support: Development, Ad hoc, App Store Connect, Developer ID Entitlement Keys: com.apple.developer.wifi-aware This is confusing because Developer ID is listed while macOS is not listed under Platform Support. The native macOS SDK declarations I inspected mark the public Wi-Fi Aware APIs unavailable on macOS. Two previously generated Developer ID provisioning profiles for my test App ID had Platform = OSX, but neither contained com.apple.developer.wifi-aware. I also could not find a Wi-Fi Aware-specific approval request in the portal's Capability Requests list. Could Apple clarify the following? Does the Developer ID entry describe a usable configuration for native macOS or Mac Catalyst applications, or is it a portal metadata issue? Is there a supported API, managed entitlement, or approval process for Wi-Fi Aware discovery and IP data paths between a third-party macOS app and an Android device? If so, which target platform, capability, provisioning-profile type, and signing configuration are required? Can that configuration operate on a standard Mac with SIP enabled, default NVRAM/boot arguments, and normal code-signing enforcement? A distributable application needs to work under those conditions. If Wi-Fi Aware is not supported for this scenario, what supported transport would Apple recommend for router-independent Android–Mac communication? Where should I file an enhancement request, and should the portal's Developer ID entry be reported separately? I would appreciate guidance on the supported integration route and any missing provisioning or entitlement step. Thank you.

Hello Apple Developer Community, I’m developing an iOS application and investigating an unusual, persistent HTTPS connectivity issue. I would appreciate guidance from developers experienced with URLSession, CFNetwork, and iOS networking. Environment Main app: React Native / Expo SDK 57. Independent diagnostic app: native Swift using URLSession with a long-lived ephemeral session. Backend: Node.js/Fastify behind Nginx on a Linux VPS. Affected device: physical iPhone 15 Pro running iOS 27.0.1. Comparison device: physical iPhone 11 running iOS 18.7.8. HTTPS API using a publicly trusted TLS certificate. Observed behavior The iPhone 11 generally communicates reliably with the API when its VPN is disabled. The iPhone 15 Pro experiences intermittent connectivity failures over both Wi-Fi and cellular LTE. Successful requests often complete within 100–300 ms. Failed requests receive no HTTP response and terminate with a timeout after approximately 15 seconds. The issue affects authentication, conversation retrieval, and message sending. It is not limited to chat functionality. What we have tested Replaced Expo Fetch with React Native Fetch. The issue persisted. Built a completely independent native Swift diagnostic app using URLSession. The same issue reproduced. Added X-Request-ID tracing to both Nginx and Fastify. During one native diagnostic run of 20 sequential GET requests, the first seven returned HTTP 401 in approximately 149–200 ms (likely due to an expired access token). The following 13 ended with URLSession error -1001, without any HTTP response. The request IDs for these 13 timed-out requests were absent from the checked Nginx and Fastify logs. A separate manual POST /auth/login also timed out with URLSession error -1001 after 15.6 seconds. NWPathMonitor continued to report satisfied over the cellular interface. URLSessionTaskMetrics for failed requests showed a transaction but lacked DNS, TCP, TLS, and response timing data. The server remained running and successfully handled other requests. We have not yet captured TCP packets during an actual failed request. Therefore, we cannot determine whether the failure occurs during DNS resolution, TCP connection establishment, TLS negotiation, or another stage. Questions What could cause URLSession to intermittently time out on one physical iPhone while another device can reach the same HTTPS endpoint? How should we interpret URLSessionTaskMetrics containing a transaction but no DNS/TCP/TLS timing information? Which additional iOS diagnostics would best identify the stage where the request stalls? Are there known differences in CFNetwork connection handling, DNS resolution, IPv6, or network configuration that would be worth investigating? I’m specifically looking for a systematic way to isolate the root cause rather than rewriting the application. Thank you for your help.

I'm developing an iOS app that includes the following Network Extension providers: NEPacketTunnelProvider NEFilterDataProvider NEFilterControlProvider I want to analyze CPU usage, memory footprint, and battery/energy impact for these extensions after release, using data collected from production devices. I've been looking into MetricKit, including MXMetricManager and MXMetricPayload, and would appreciate clarification on its support for app extensions. Specifically: API support: Can MetricKit be initialized and registered as a subscriber from within a Network Extension provider's process? Are there any restrictions specific to these extension types? Metric availability: If registration is supported, do the resulting metric payloads contain CPU, memory, and energy metrics attributable to the extension itself, or do they cover only the containing app? Production reliability: Can I rely on MetricKit to collect these metrics consistently across production devices and app versions? Are reports generated for extensions independently, and are there known limitations in report delivery or coverage? Memory and CPU: Is there a supported way to obtain the extension's peak memory footprint and CPU consumption through MetricKit? If these metrics aren't available through MetricKit, what APIs or reporting mechanisms does Apple recommend? Energy and battery: Can MetricKit provide energy-impact metrics specifically attributable to a Network Extension provider, rather than aggregated metrics for the containing app? Recommended approach: For post-release analysis of these extensions, should I use MetricKit, Xcode Organizer's Energy reports, custom telemetry within the extension, or a combination of these? My goal is to monitor resource consumption and identify regressions in production without relying on Instruments profiling on individual devices. I'd appreciate clarification on which of these capabilities are officially supported for Network Extension providers and which approach Apple recommends for reliable production monitoring. Thanks!

Apple blocked the eight compromised eMudhra intermediate CAs (CVE-2026-111943) for Security.framework clients. But on macOS 27.0.1 (26A434), /usr/bin/curl and /usr/bin/python3 still accept certificates from them. These tools verify against /etc/ssl/cert.pem and do not check revocation. The file (dated Sep 24) still contains both roots that the compromised intermediates chain to: emSign ECC Root CA - G3 AAA Certificate Services To reproduce, with SSL_CERT_FILE and CURL_CA_BUNDLE not set: /usr/bin/curl -sS -o /dev/null -w '%{exitcode}\n' https://dv-g3b-emudhra.we-have-a-problem.com/ # 0 — the connection succeeds grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' /etc/ssl/cert.pem # both roots are presentWith a CA bundle that does not have these roots (Homebrew ca-certificates), the same command fails with "unable to get local issuer certificate". So the system bundle is the cause. softwareupdate -l shows no update. Questions: Does Apple plan to update /etc/ssl/cert.pem for this, and will the security notes say so? Until then, is setting SSL_CERT_FILE to a separate bundle the recommended workaround for the system tools?

Hello, With Xcode 27.1 RC 1, the Background Assets override inside of developer settings is now a blank page. I see there's a new setting for background assets under Scheme < Options. Will the URL replacement return? Thanks