I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro. However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know? The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later). Anyone knows why? Samson

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!

Hello, I have an app that is using iOS 26 Network Framework APIs. It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity. All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network. If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to. By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare. I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work. Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware? Regards, Captadoh

Description Enterprise users are experiencing VPN resource access failures after upgrading to macOS Tahoe. Investigation indicates that configd (specifically IPMonitor) is incorrectly re-ranking network interfaces after a connectivity failure with probe server. This results in DNS queries routing through the physical network adapter (en0) instead of the VPN virtual adapter, even while the tunnel is active. This behaviour is not seen in previous macOS versions. Steps to Reproduce: Connect to an enterprise VPN (e.g., Ivanti Secure Access). Trigger a transient network condition where the Apple probe server is unreachable. For example make the DNS server down for 30 sec. Observe the system routing DNS queries for internal resources to the physical adapter. Expected Results The: VPN virtual interface should maintain its primary rank for enterprise DNS queries regardless of the physical adapter's probe status. Actual Results: IPMonitor detects an UplinkIssue, deprioritizes the VPN interface, and elevates the physical adapter to a higher priority rank. Technical Root Cause & Logs: The system logs show IPMonitor identifying an issue and modifying the interface priority at 16:03:54: IPMonitor Detection: The process identifies an inability to reach the Apple probe server and marks en0 with an advisory: Log snippet 2026-01-06 16:03:53.956399+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] configd[594] SetInterfaceAdvisory(en0) = UplinkIssue (2) reason='unable to reach probe server' Interface Re-ranking: Immediately following, IPMonitor recalculates the rank, placing the physical service ID at a higher priority (lower numerical rank) than the VPN service ID (net.pulsesecure...): Log snippet 2026-01-06 16:03:53.967935+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 0. en0 serviceID=50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 addr=192.168.0.128 rank=0x200000d 2026-01-06 16:03:53.967947+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 1. en0 serviceID=net.pulsesecure.pulse.nc.main addr=192.168.0.128 rank=0x2ffffff 3.Physical adapter Is selected as Primary Interface: 2026-01-06 16:03:53.968145+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary IPv4 configd[594]: 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary DNS Packet Trace Evidence Wireshark confirms that DNS queries for enterprise-specific DNS servers are being originated from the physical IP (192.168.0.128) instead of the virtual adapter: Time: 16:03:54.084 Source: 192.168.0.128 (Physical Adapter) Destination: 172.29.155.115 (Internal VPN DNS Server) Result: Connectivity Failure (Queries sent outside the tunnel)

We are developing an iOS application that is interacting with HTTP APIs that requires us to put a unique UUID (a nonce) as an header on every request (obviously there's more than that, but that's irrilevant to the question here). If the same nonce is sent on two subsequent requests the server returns a 412 error. We should avoid generating this kind of errors as, if repeated, they may be flagged as a malicious activity by the HTTP APIs. We are using URLSession.shared.dataTaskPublisher(for: request) to call the HTTP APIs with request being generated with the unique nonce as an header. On our field tests we are seeing a few cases of the same HTTP request (same nonce) being repeated a few seconds on after the other. Our code has some retry logic only on 401 errors, but that involves a token refresh, and this is not what we are seeing from logs. We were able to replicate this behaviour on our own device using Network Link Conditioner with very bad performance, with XCode's Network inspector attached we can be certain that two HTTP requests with identical headers are actually made automatically, the first request has an "End Reason" of "Retry", the second is "Success" with Status 412. Our questions are: can we disable this behaviour? can we provide a new request for the retry (so that we can update headers)? Thanks, Francesco

I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁. What current and past iPhone and iPad models support Wi-Fi Aware? And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?

I have added a Network Extension to my iOS project to use the WireGuard library. Everything was working fine up to Xcode 16, but after updating, I’m facing a build issue. The build fails with the following error: No such file or directory: '@rpath/WireGuardNetworkExtensioniOS.debug.dylib' I haven’t explicitly added any .dylib to my project. The Network Extension target builds and runs fine on Xcode 16.

Hi All, I am currently working on a Network Extension App for MacOS using 3 types of extensions provided by Apple's Network Extension Framework. Content Filter, App Proxy (Want to get/capture/log all HTTP/HTTPS traffic), DNS Proxy (Want to get/capture/log all DNS records). Later parse into human readable format. Is my selection of network extension types correct for the intended logs I need? I am able to run with one extension: Main App(Xcode Target1) <-> Content Filter Extension. Here there is a singleton class IPCConnection between App(ViewController.swift) which is working fine with NEMachServiceName from Info.plist of ContentFilter Extension(Xcode Target2) However, when I add an App Proxy extension as a new Xcode Target3, I think the App and extension's communication getting messed up and App not getting started/Crashing. Here, In the same Main App, I am adding new separate IPCConnection for this extension. Here is the project organization/folder structure. MyNetworkExtension ├──MyNetworkExtension(Xcode Target1) │ ├── AppDelegate.swift │ ├── Assets.xcassets │ ├── Info.plist │ ├── MyNetworkExtension.entitlement │ | ── Main │ |-----ViewController.swift │ └── Base.lproj │ └── Main.storyboard ├── ContentFilterExtension(Xcode Target2) │ ├── ContentFilterExtension.entitlement │ │ ├── FilterDataProvider.swift │ │ ├── Info.plist │ │ ├── IPCConnection.swift │ │ └── main.swift ├── AppProxyProviderExtension(Xcode Target3) │ ├── AppProxyProviderExtension.entitlement │ │ ├── AppProxyIPCConnection.swift │ │ ├── AppProxyProvider.swift │ │ ├── Info.plist │ │ └── main.swift └── Frameworks ├── libbsm.tbd └── NetworkExtension.framework Is my Approach for creating a single Network Extension App with Multiple extensions correct or is there any better approach of project organization that will make future modifications/working easier and makes the maintenance better? I want to keep the logic for each extension separate while having the same, single Main App that manages everything(installing, activating, managing identifiers, extensions, etc). What's the best approach to establish a Communication from MainApp to each extension separately, without affecting one another? Is it good idea to establish 3 separate IPC Connections(each is a singleton class) for each extension? Are there any suggestions you can provide that relates to my use case of capturing all the network traffic logs(including HTTP/HTTPS, DNS Records, etc), especially on App to Extension Communication, where my app unable to keep multiple IPC Connections and maintain them separately? I've been working on it for a while, and still unable to make the Network Extension App work with multiple extensions(each as a new Xcode target). Main App with single extension is working fine, but if I add new extension, App getting crashed. I suspect it's due to XPC/IPC connection things! I really appreciate any support on this either directly or by any suggestions/resources that will help me get better understand and make some progress. Please reach out if in case any clarifications or specific information that's needed to better understand my questions. Thank you very much

Hello, I'm trying to build the sample app from Building peer-to-peer apps that demonstrates Wi-Fi Aware. Upon downloading the example source code, opening it in Xcode 26.0 beta, and building the app, the compiler fails with: DeviceDiscoveryPairingView.swift:8:8 No such module 'DeviceDiscoveryUI' Is this a known issue? I know that DeviceDiscoveryUI was previously only a tvOS capability. Thanks

Hello, I have a few questions regarding URL Filter (iOS 26) and Content Filter Providers. URL Filter According to the WWDC26 video, URL Filter appears to be available for both consumer and enterprise deployments. This seems consistent with the classic Network Extension Provider Deployment documentation (TN3134 – August 2025), where no specific deployment restriction is mentioned. However, a more recent document (Apple Platform Deployment, September 2025) indicates the following for URL Filter: “Requires supervision on iPhone, iPad and Mac” (with a green checkmark). 👉 My question: Is URL Filter actually available for consumer use on non-supervised iPhones (deployed on Testflight and AppStore), or is supervision now required? Content Filter Providers From past experience, I remember that Content Filter Providers were only available on supervised devices. Based on the current documentation, I am questioning their usability in a consumer context, i.e. on non-supervised iPhones. In the Network Extension Provider Deployment documentation, it is stated that this is a Network Extension and that, since iOS 16, it is a “per-app on managed device” restriction. In the more recent Apple Platform Deployment document, it states for iPhone and iPad: “App needs to be installed on the user’s iOS and iPadOS device and deletion can be prevented if the device is supervised.” 👉 My understanding: Supervised device: The Content Filter Provider is installed via a host application that controls enabling/disabling the filter, and the host app can be prevented from being removed thanks to supervision. Non-supervised device: The Content Filter Provider is also installed via a host application that controls enabling/disabling the filter, but the app can be removed by the user, which would remove the filter. 👉 My question: Can Content Filter Providers be used in a consumer context on non-supervised iPhones (deployed on Testflight and AppStore), accepting that the user can uninstall the host app (and therefore remove the filter)? Thank you in advance for your feedback. Sources: TN3134 => TN3134: Network Extension provider deployment | Apple Developer Documentation Apple Platform Deployment / Filter content for Apple devices => https://support.apple.com/en-gb/guide/deployment/dep1129ff8d2/1/web/1.0

In our iOS application, we need to list available WiFi networks so that users can select one for device configuration. Here's the workflow: Initially, the hardware device acts as a WiFi Access Point (AP). The app should scan for nearby WiFi networks to detect the device's AP. The app connects temporarily to this AP and sends the selected WiFi credentials to the device. The device then connects to the selected WiFi network and stops broadcasting its AP. Is this flow achievable on iOS? We understand that Apple restricts access to WiFi scanning APIs — are there any supported methods (e.g., using NEHotspotHelper) or entitlements (such as MFi) that could enable this?

Hi, I’m implementing a macOS DNS Proxy as a system extension and running into a persistent activation error: OSSystemExtensionErrorDomain error 9 (validationFailed) with the message: extension category returned error This happens both on an MDM‑managed Mac and on a completely clean Mac (no MDM, fresh install). Setup macOS: 15.x (clean machine, no MDM) Xcode: 16.x Team ID: AAAAAAA111 (test) Host app bundle ID: com.example.agent.NetShieldProxy DNS Proxy system extension bundle ID: com.example.agent.NetShieldProxy.dnsProxy The DNS Proxy is implemented as a NetworkExtension system extension, not an app extension. Host app entitlements From codesign -d --entitlements :- /Applications/NetShieldProxy.app: xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy.dnsProxy <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy-systemextension</string> </array> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> <string>group.example.NetShieldmac</string> <string>group.example.agent.enterprise.macos</string> <string>group.example.com.NetShieldmac</string> </array> DNS Proxy system extension Info.plist On the clean Mac, from: bash plutil -p "/Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension/Contents/Info.plist" I get: json { "CFBundleExecutable" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleIdentifier" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleName" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundlePackageType" => "SYSX", "CFBundleShortVersionString" => "1.0.1.8", "CFBundleSupportedPlatforms" => [ "MacOSX" ], "CFBundleVersion" => "0.1.1", "LSMinimumSystemVersion" => "13.5", "NSExtension" => { "NSExtensionPointIdentifier" => "com.apple.dns-proxy", "NSExtensionPrincipalClass" => "com_example_agent_NetShieldProxy_dnsProxy.DNSProxyProvider" }, "NSSystemExtensionUsageDescription" => "SYSTEM_EXTENSION_USAGE_DESCRIPTION" } The DNSProxyProvider class inherits from NEDNSProxyProvider and is built in the system extension target. Activation code In the host app, I use: swift import SystemExtensions final class SystemExtensionActivator: NSObject, OSSystemExtensionRequestDelegate { private let extensionIdentifier = "com.example.agent.NetShieldProxy.dnsProxy" func activate(completion: @escaping (Bool) -> Void) { let request = OSSystemExtensionRequest.activationRequest( forExtensionWithIdentifier: extensionIdentifier, queue: .main ) request.delegate = self OSSystemExtensionManager.shared.submitRequest(request) } func request(_ request: OSSystemExtensionRequest, didFailWithError error: Error) { let nsError = error as NSError print("Activation failed:", nsError) } func request(_ request: OSSystemExtensionRequest, didFinishWithResult result: OSSystemExtensionRequest.Result) { print("Result:", result.rawValue) } } Runtime behavior on a clean Mac (no MDM) config.plist is created under /Library/Application Support/NetShield (via a root shell script). A daemon runs, contacts our backend, and writes /Library/Application Support/NetShield/state.plist with a valid dnsToken and other fields. The app NetShieldProxy.app is installed via a notarized, stapled Developer ID .pkg. The extension bundle is present at: /Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension. When I press Activate DNS Proxy in the UI, I see in the unified log: text NetShieldProxy: [com.example.agent:SystemExtensionActivator] Requesting activation for system extension: com.example.agent.NetShieldProxy.dnsProxy NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - activation failed: extension category returned error (domain=OSSystemExtensionErrorDomain code=9) NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - OSSystemExtensionError code enum: 9 NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - validationFailed And: bash systemextensionsctl list -> 0 extension(s) There is no prompt in Privacy & Security on this clean Mac. Question Given: The extension is packaged as a system extension (CFBundlePackageType = SYSX) with NSExtensionPointIdentifier = "com.apple.dns-proxy". Host and extension share the same Team ID and Developer ID Application cert. Entitlements on the target machine match the provisioning profile and Apple’s docs for DNS Proxy system extensions (dns-proxy-systemextension). This is happening on a clean Mac with no MDM profiles at all. What are the likely reasons for OSSystemExtensionErrorDomain error 9 (validationFailed) with "extension category returned error" in this DNS Proxy system extension scenario? Is there any additional configuration required for DNS Proxy system extensions (beyond entitlements and Info.plist) that could trigger this category-level validation failure? Any guidance or examples of a working DNS Proxy system extension configuration (host entitlements + extension Info.plist + entitlements) would be greatly appreciated. Thanks!

My company has a server that supports ticket-based TLS session resumption (per RFC 5077). We have done Wireshark captures that show that our iOS client app, which uses URLSession for REST and WebSocket connections to the server, is not sending the TLS "session_ticket" extension in the Client Hello package that necessary to enable ticket-based resumption with the server. Is it expected that URLSession does not support ticket-based TLS session resumption? If "yes", is there any way to tell URLSession to enable ticket-based session resumption? the lower-level API set_protocol_options_set_tls_tickets_enabled() hints that the overall TLS / HTTP stack on IOS does support ticket-based resumption, but I can't see how to use that low-level API with URLSession. I can provide (lots) more technical details if necessary, but hopefully this is enough context to determine whether ticket-based TLS resumption is supported with URLSession. Any tips / clarifications would be greatly appreciated.

According to documentation, the URLSession background tasks continue even when the app is suspended. What is the lifespan of the URLSessionDownloadDelegate object when app is suspended or terminated? Will it get re-created and re-initialize properties when the app re-launches, or will it somehow restore the existing property values? Also, urlSessionDidFinishEvents not getting called, and what do we need to do there with the backgroundCompletionHandler? Any insights are much appreciated. We are getting ready to launch and this is a roadblock. (visionOS26.4) Thank you. @Observable class DownloadManager: NSObject, URLSessionDownloadDelegate { ... let config = URLSessionConfiguration.background(withIdentifier: "TestDL") config.sessionSendsLaunchEvents = true var urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil) func downloadFiles(... { // initiate multiple file downloads concurrently for url in urlList { let task = urlSession.downloadTask(with: url) task.resume() } } func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) { ... func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) { ... func urlSession(_: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { ... // Not getting called ?? // Is this only called when app is suspended/terminated? func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) { print("didFinishEvents") Task { @MainActor in //urlSession?.finishTasksAndInvalidate() //urlSession = nil // not sure what to do here: if let appDelegate = UIApplication.shared.delegate as? AppDelegate, let completionHandler = appDelegate.backgroundCompletionHandler { completionHandler() appDelegate.backgroundCompletionHandler = nil } } }

Hello and Good day! We are conducting Bonjour Conformance Test (BCT) for Printer device. BCT result is PASSED but with warning in Multicast DNS, specifically, WARNING: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Other Shared Reply Timing is passed: PASSED: MULTIPLE QUESTIONS - SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION Environment: BCT Tool Version: 1.5.4 (15400) MacOS Sequioa 15.5 DUT Firmware : Linux Debian 9 Apple mDNSResponder 1790.80.10 Service types: _ipps._tcp, _uscans._tcp, _ipp._tcp, _uscan._tcp Router : NEC AtermWR8370N Setup: 1-to-1 [Mac->Router<-DUT connection] Based on debug.log, this is where WARNING occurs: NOTICE 2026-03-04 10:51:06.870187+0900 _shared_reply_timing 04103: Shared reply response times: min = 26ms, max = 114ms, avg = 65.50ms WARNING 2026-03-04 10:51:06.870361+0900 _shared_reply_timing 04136: 50 percent of the replies within the correct range fell in the interval 20ms and 46ms (should be close to 25%). PASSED (SHARED REPLY TIMING) In the same debug.log for MULTIPLE QUESTIONS - SHARED REPLY TIMING is PASSED: NOTICE 2026-03-04 10:52:29.912334+0900 _shared_reply_timing 04103: Shared reply response times: min = 22ms, max = 112ms, avg = 78.00ms DEBUG_2 2026-03-04 10:52:29.912849+0900 recv_packet 01997: received packet (558 bytes) PASSED (MULTIPLE QUESTIONS - SHARED REPLY TIMING) [Details] Looking at Bonjour_Conformance_Guideline.pdf https://download.developer.apple.com/Documentation/Bonjour_Conformance_Test_Guideline/Bonjour_Conformance_Guideline.pdf there were some differences: In 1.6.2 Expected Result: Test Result File of Test that All Tests Passed, this is not displayed: PASSED: SHARED REPLY TIMING - UNIFORM RANDOM REPLY TIME DISTRIBUTION And in II.8 Shared Reply Timing: (Ideally, 25% of the answers should fall in each 21ms quadrant of the range 20ms - 125ms.) and comparing to the debug.log, there was a discrepancy of the interval, because 20ms and 46ms is 26ms interval. From RFC6762 6. Responding, Ideal range is from 20ms-120ms Because of this, please advise on the questions below: I would like to know on the possible cause and resolution for these WARNINGS. And since in current BCT result, (Test result integrity signature is generated), I would like to know if this is acceptable for BCT certification. Thank you.

Our app has a network extension (as I've mentioned lots 😄). We do an upgrade by downloading the new package, stopping & removing all of our components except for the network extension, and then installing the new package, which then loads a LaunchAgent causing the containing app to run. (The only difference between a new install and upgrade is the old extension is left running, but not having anything to tell it what to do, just logs and continues.) On some (but not all) upgrades... nothing ends up able to communicate via XPC with the Network Extension. My simplest cli program to talk to it gets Could not create proxy: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named blah was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named bla was invalidated: failed at lookup with error 3 - No such process.} Could not communicate with blah Restarting the extension by doing a kill -9 doesn't fix it; neither does restarting the control daemon. The only solution we've come across so far is rebooting. I filed FB11086599 about this, but has anyone thoughts about this?

Hi All, I am working on a macOS System Extension using Apple’s Network Extension Framework, designed to observe and log network activity at multiple layers. The system extension is currently stable and working as expected for HTTP and DNS traffic with 3 providers, getting Socket, HTTP, and DNS logs. Current Architecture Overview The project consists of two Xcode targets: 1. Main App Process Responsible for: Managing system extension lifecycle (activation, configuration) Establishing IPC (XPC) communication with extensions Receiving structured logs from extensions Writing logs efficiently to disk using a persistent file handle Uses: OSSystemExtensionManager NEFilterManager, NETransparentProxyManager, NEDNSProxyManager NWPathMonitor for network availability handling Persistent logging mechanism (FileHandle) 2. System Extension Process Contains three providers, all running within a single system extension process: a) Content Filter (NEFilterDataProvider) Captures socket-level metadata Extracts: PID via audit token Local/remote endpoints Protocol (TCP/UDP, IPv4/IPv6) Direction (inbound/outbound) Sends structured JSON logs via shared IPC b) Transparent Proxy (NETransparentProxyProvider) Intercepts TCP flows Creates a corresponding NWConnection to the destination Captures both HTTP and HTTPS traffic, sends it to HTTPFlowLogger file which bypasses if it's not HTTP traffic. Uses a custom HTTPFlowLogger: Built using SwiftNIO library (NIO HTTP1) Parses up to HTTP/1.1 traffic Handles streaming, headers, and partial body capture (with size limits) Maintains per-flow state and lifecycle management Logs structured HTTP data via shared IPC c) DNS Proxy (NEDNSProxyProvider) Intercepts UDP DNS traffic Forwards queries to upstream resolver (system DNS or fallback) Maintains shared UDP connection Tracks pending requests using DNS IDs Parses DNS packets (queries + responses) using a custom parser Logs structured DNS metadata via shared IPC Shared Component: IPCConnection Single bidirectional XPC channel used by all providers Handles: App → Extension registration Extension → App logging Uses Mach service defined in system extension entitlements Project Structure NetworkExtension (Project) │ ├── NetworkExtension (Target 1: Main App) │ ├── AppDelegate.swift │ ├── Assets.xcassets │ ├── Info.plist │ ├── NetworkExtension.entitlements │ ├── Main.storyboard │ └──ViewController.swift │ ├── SystemExtensions (Target 2: Extension Process) │ ├── common/ │ │ ├── IPCConnection.swift │ │ └── main.swift │ │ │ ├── DNSProxyProvider/ │ │ ├──DNSDataParser.swift │ │ └──DNSProxyProvider.swift (DNS Proxy) │ │ │ ├── FilterDataProvider/ │ │ └── FilterDataProvider.swift │ │ │ ├── TransparentProxyProvider/ │ │ ├── HTTPLogParser.swift │ │ ├── LogDataModel.swift │ │ └──TransparentProxyProvider.swift │ │ │ ├── Info.plist │ └── SystemExtensions.entitlements │ Current Capabilities Unified logging pipeline across: Socket-level metadata HTTP traffic (HTTP/1.1) DNS queries/responses Efficient log handling using persistent file descriptors Stable IPC communication between app and extensions Flow-level tracking and lifecycle management Selective filtering (e.g., bypass rules for specific IPs) What's the best approach to add TLS Inspection with MITM proxy setup? Some context and constraints: Existing implementation handles HTTP parsing and should remain unchanged (Swift-based). I’m okay with bypassing apps/sites that use certificate pinning (e.g., banking apps) and legitimate sites. Performance is important — I want to avoid high CPU utilization. I’m relatively new to TLS inspection and MITM proxy design. Questions Is it a good idea to implement TLS inspection within a system extension, or does that typically introduce significant complexity and performance overhead? As NETransparentProxyProvider already intercepting HTTPS traffic, can we redirect it to a separate processing pipeline (e.g., another file/module), while keeping the existing HTTP parser(HTTPFlowLogger - HTTP only parser) intact? What are the recommended architectural approaches for adding HTTPS parsing via MITM in a performant way? Are there best practices for selectively bypassing pinned or sensitive domains while still inspecting other traffic? Any guidance on avoiding common pitfalls (e.g., certificate handling, connection reuse, latency issues)? I’m looking for a clean, maintainable approach to integrate HTTPS inspection into my existing system without unnecessary complexity or performance degradation. Please let me know if any additional details from my side would help in suggesting the most appropriate approach. Thanks in advance for your time and insights—I really appreciate it.

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, Our project is a MacOS SwiftUI GUI application that bundles a (Sandboxed) System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider (NEPacketTunnelProvider), as our project requires the creation of a TUN device. In order for our System VPN to function, it must reach out to a (self-hosted) server (i.e. to discover a list of peers). Being self-hosted, this server is typically not accessible via the public web, and may only be accessible from within a VPN (such as those also implemented using NEPacketTunnelProvider, e.g. Tailscale, Cloudflare WARP). What we've discovered is that the networking code of the System Network Extension process does not attempt to use the other VPN network interfaces (utunX) on the system. In practice, this means requests to IPs and hostnames that should be routed to those interfaces time out. Identical requests made outside of the Network System Extension process use those interfaces and succeed. The simplest example is where we create a URLSession.downloadTask for a resource on the server. A more complicated example is where we execute a Go .dylib that continues to communicate with that server. Both types of requests time out. Two noteworthy logs appear when packets fail to send, both from the kernel 'process': cfil_hash_entry_log:6088 <CFIL: Error: sosend_reinject() failed>: [30685 com.coder.Coder-Desktop.VPN] <UDP(17) out so b795d11aca7c26bf 57728068503033955 57728068503033955 age 0> lport 3001 fport 3001 laddr 100.108.7.40 faddr 100.112.177.88 hash 58B15863 cfil_service_inject_queue:4472 CFIL: sosend() failed 49 I also wrote some test code that probes using a UDP NWConnection and NWPath availableInterfaces. When run from the GUI App, multiple interfaces are returned, including the one that routes the address, utun5. When ran from within the sysex, only en0 is returned. I understand routing a VPN through another is unconventional, but we unfortunately do need this functionality one way or another. Is there any way to modify which interfaces are exposed to the sysex? Additionally, are these limitations of networking within a Network System Extension documented anywhere? Do you have any ideas why this specific limitation might exist?

I’m developing an iOS idle game (guild management). To detect manual device time changes that would break progression, I need a trusted “current real-world time” reference. I’m considering querying Apple’s NTP host time.apple.com, but I couldn’t find any official guidance about whether third-party apps may use time.apple.com directly (acceptable use, rate limits, whether it’s discouraged, etc.). Apple Developer Support couldn’t provide info and suggested asking on the forums. Questions: 1. Is it permitted for a third-party iOS app to query time.apple.com via NTP/SNTP (Yes/No or conditional)? 2. If permitted, are there any published or recommended constraints (rate limits, caching, prohibited patterns, commercial app considerations)? 3. If not permitted / not recommended, what is the recommended alternative approach (run our own time service, use public NTP pool, or any Apple-recommended mechanism)? 4. If there is any official document / policy covering this, could you point me to it? For context: I do not need sub-second accuracy and I do not intend high-frequency polling. If implemented at all, it would be very low frequency (e.g., first launch + once per 24h) with caching and graceful fallback on failure. My main goal is policy clarity rather than implementation details.