General: Forums subtopic: App & System Services > Networking TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers forums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS TN3179 Understanding local network privacy Adapt to changing network conditions tech talk TCP and UDP ports used by Apple software products support article Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

I am porting a project from the now deprecated dns_util api to use the DNS Service Discovery api. With dns_util I am able to specify a DNS name server to use for resolving queries. This is useful for testing new servers or propogation when changes have been made to DNS records. Is it possible to specify the nameserver to use with DNS Service Discovery?

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

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

We have an app that uses UDP messaging. It has been working for over 3 years successfully. The App is now failing on installation with MacOS26. The issue would appear to be that MacOS is silently blocking the UDP traffic. If we disable the local network for the App, and then turn back on, this will fix the issue. But this needs to be done on every system restart.

We operate a captive portal WIFI network in a walled-garden setup. There is no public internet access on this network. Users connect to our SSID and can only reach a local resource. On Android, our captive portal can show a button that launches the devices default browser and navigates to our portal page. We cannot reproduce this on iOS: we can place the button inside the CNA tear sheet but tapping it does not open Safari, the redirect simply does not happen. I found this older thread describing the same need: https://developer.apple.com/forums/thread/75498 From that thread, it seems the behavior changed several times. It reportedly worked around iOS 11.2 then broke again in later releases. My questions: On current iOS, is it possible to open Safarı or the default browser programmatically from within the CNA? For example, via a link or button after authentication? If yes, what is the supported way? If it is not supported, is that intentional? Is there any official documentation describing CNA limitations and the recommended pattern? For a walled-garden network with no public Internet, what is Apple's recommended approach to move the user from the CNA into a full browser session?

Hello everyone, I have developed an app that is a local networking monitor app for a specific building automation protocol. I have searched the forum and I think I have found some older posts regarding this topic but I could not figure out if my issue falls under the same category. So my app allows the user to connect to local protocol devices, and start a monitor session where they can see incoming/outgoing packets. The connections are UDP or TCP and require opening a socket. Currently, backgrounding the app will make the OS terminate the socket connection, therefore ending the monitor, even if the app is backgrounded by user, to let's say, perform some other task in their phone. I have several requests from users to improve the app by allowing the monitor to continue while the app is backgrounded. However, by reading the relevant documents, I have found this to be almost impossible in iOS app. I have considered: Remote Push Notifications (APNs): The app operates on LAN so this is not an option, since I do not have an infrastructure to somehow send notifications to keep app process alive. Background Tasks (BGTaskScheduler): Not my case, since I do not want periodic execution. The app requires continuous socket listening. VoIP, VPN, or Audio Background Modes: My app does not fall under any of these categories, even though this would solve my situation. By searching around a bit more, I might be able to use either BGProcessingTask, which would allow my app at least to run for some minutes and show the user that they have to foreground it in order to not stop the monitor process, or maybe even App Intents framework. Has anyone faced similar requirement for their app? Any tip or point to a direction I should investigate more? Thanks, Nikos

I previously attempted to apply for the hotspot-provider entitlement but was rejected. I no longer require this entitlement. I need to remove the hotspot-provider permission although the Network Extensions capability is checked. However, the generated provisioning profile still includes the hotspot-provider permission, which causes error 409 when I upload the IPA file. I only need the Network Extensions entitlement. Could you please advise how to remove hotspot-provider from the provisioning profile?

Description of the Issue: We are experiencing intermittent, severe latency spikes during cellular data transmission (specifically with MQTT Publish) on iPhone 17 devices. Through internal testing and cross-referencing with similar user reports online, we suspect this is caused by an aggressive power-saving or sleep mechanism in the cellular modem/iOS network stack when traffic is sporadic or low-frequency. Steps to Reproduce / Observations: Establish an MQTT connection over a cellular network (5G/LTE) on an iPhone 17. Publish messages at irregular or low-frequency intervals (e.g., sporadic IoT data transmission). Result: Severe latency spikes occur intermittently during transmission. Diagnostic Findings & Documented Workarounds: Workaround 1 (Constant Traffic): If we connect a secondary device (e.g., a PC) to the iPhone 17's Personal Hotspot and run a continuous background ping (with a 10ms interval), the MQTT latency spikes disappear completely. This high-frequency traffic prevents the device/modem from dropping into power-save mode. Workaround 2 (VPN Tunnel): Utilizing a VPN profile (such as Cloudflare's 1.1.1.1 app) significantly mitigates the issue. We suspect this is due to either the VPN's background keep-alive packets maintaining the active state of the modem, or iOS applying a less aggressive power-saving policy to active VPN interfaces. System Environment: Device: iPhone 17 series OS: iOS 19 (or specify your current version) Network: Cellular (5G/LTE) Questions Regarding Temporary Workarounds & Mitigations: To unblock our current development and ensure a reliable user experience before an official OS-level fix is deployed, we would highly appreciate Apple's technical guidance on the following questions: Recommended Keep-Alive Mechanism: Since higher frequency traffic effectively prevents the modem from entering power-save mode, does iOS have a recommended, power-efficient way for an application to maintain an active cellular network state (e.g., recommended TCP/MQTT keep-alive intervals or NWPathEvaluator configurations) without being suspended or penalized by the system? Network Optimization APIs: Are there specific Network Framework APIs (Network.framework) or socket configuration flags (such as Multipath TCP, or Quality of Service (QoS) flags like Background vs Default) that can signal to the iOS kernel to apply a less aggressive power-saving policy on the active cellular interface? Background Execution Policy: For IoT applications that need to publish MQTT data seamlessly while running in the background, what is the best practice to prevent the cellular link from dropping into deep sleep mode? We would appreciate it if the Apple Network/CoreOS engineering team could look into this cellular power management behavior. Thank you for your support.

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

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

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

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

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

Hello, I'm developing a gambling blocker app that uses NEFilterDataProvider. My app was approved on the App Store, but the core feature doesn't work for end users. I have the content-filter-provider entitlement. Issue 1 — saveToPreferences() fails in distribution builds In dev builds (Xcode direct install), NEFilterManager.saveToPreferences() works fine — iOS shows a permission dialog and the filter is registered. In distribution builds (TestFlight/App Store), it fails immediately: NEFilterErrorDomain code 5 — Operation not permitted Console log from nehelper: "Creating a content filter configuration is only allowed through profile in production version" Issue 2 — .mobileconfig profile requires MDM Following the Console hint, I tried a .mobileconfig profile with com.apple.webcontent-filter payload (ContentFilterUUID, FilterType: Plugin, PluginBundleID). On an unsupervised consumer iPhone (iOS 18.5), installation fails: Profile Installation Failed — MDM required Question: What is the correct mechanism to activate a NEFilterDataProvider on a consumer (non-MDM) iPhone in a distribution build? Is there a specific entitlement or approval process I'm missing? (DTS Case-ID: 20087732)

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - 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=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

I'm implementing a NETransparentProxyProvider and trying to preserve the original TCP connection semantics as transparently as possible. The current API of NEAppProxyTCPFlow appears not to provide a way to distinguish between the following situations: The client has performed a half-close by calling shutdown(SHUT_WR) (i.e. closed only its write side). The client has fully closed the socket/connection. When readData(completionHandler:) returns empty data, indicating EOF, I cannot determine which of the two cases above has occurred. This creates a problem when forwarding the connection to the upstream server. Upon receiving empty data from the flow, should the corresponding server-side connection: Perform a half-close (close only the write side / send FIN)? Be fully closed? Currently, I always perform a half-close on the server-side connection. While this almost preserves the original flow semantics, it can lead to leaked connections, since the upstream connection may remain in FIN_WAIT_2 indefinitely. Is there any supported way to determine whether the originating connection was half-closed or fully closed? If not, what is the recommended approach for implementing a transparent TCP proxy that needs to accurately preserve TCP shutdown semantics? Any guidance would be appreciated.

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

I created an App using PeerNetworking to connect two iOS-Devices without existing wifi-infrastructure. In general the solution works fine but when there are many other smart devices nearby connection gets unstable and breaks, devices have to be closer together or dont connect at all. In "Lab"-conditions everything works fine. What could I do to get the connection more stable and reliable?

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

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.