Our business interface requests require disabling HTTP(s) proxies. We configured URLSessionConfiguration.connectionProxyDictionary as before, but found that it does not work on iOS 26 1.Core code: let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ "HTTPEnable": false, "HTTPSEnable": false, "SOCKSEnable": false, ] let session = URLSession(configuration: configuration) let request = URLRequest(url: URL(string: "https://www.baidu.com")!,timeoutInterval: Double.infinity) // 发送请求 let task = session.dataTask(with: request) { data, response, error in if let error = error { print("网络请求失败: \(error)") } if let data = data { print("网络请求成功，返回数据长度: \(data.count)") if let responseString = String(data: data, encoding: .utf8) { print("返回数据: \(responseString.prefix(100))...") } } } task.resume() 2.Specific steps: We captured traffic using Proxyman and Charles. With the same code, requests cannot be captured on iOS 18 and iOS 16.1, but can be captured on iOS 26.2 and 26.1. Conclusion:Therefore, we suspect there is a bug with URLSessionConfiguration.connectionProxyDictionary on iOS 26.x. Please let us know whether this is a bug. If not, how should we properly disable HTTP(s) proxies? Note: We need to exclude PAC proxies, which are commonly used in corporate internal networks. 3.Devices & Software Xcode 16.4 iPhone 26.2、Simulator 26.1 iPhone 16、Simulator 18.0、Simulator 18.6 Proxyman、Charles

Hello Apple Support Team, We are experiencing a performance issue with HTTP/3 in our iOS application during testing. Problem Description: Network requests using HTTP/3 are significantly slower than expected. This issue occurs on both Wi-Fi and 4G networks, with both IPv4 and IPv6. The same setup worked correctly in an earlier experiment. Key Observations: The slowdown disappears when the device uses: · A personal hotspot. · Network Link Conditioner (with no limitations applied). · Internet sharing from a MacBook via USB (where traffic was also inspected with Wireshark without issues). The problem is specific to HTTP/3 and does not occur with HTTP/2. The issue is reproducible on iOS 15, 18.7, and the latest iOS 26 beta. HTTP/3 is confirmed to be active (via assumeHttp3Capable and Alt-Svc header). Crucially, the same backend endpoint works with normal performance on Android devices and using curl with HTTP/3 support from the same network. I've checked the CFNetwork logs in the Console but haven't found any suspicious errors or obvious clues that explain the slowdown. We are using a standard URLSession with basic configuration. Attempted to collect qlog diagnostics by setting the QUIC_LOG_DIRECTORY=~/ tmp environment variable, but the logs were not generated. Question: What could cause HTTP/3 performance to improve only when the device is connected through a hotspot, unrestricted Network Link Conditioner, or USB-tethered connection? The fact that Android and curl work correctly points to an issue specific to the iOS network stack. Are there known conditions or policies (e.g., related to network interface handling, QoS, or specific packet processing) that could lead to this behavior? Additionally, why might the qlog environment variable fail to produce logs, and are there other ways to obtain detailed HTTP/3 diagnostic information from iOS? Any guidance on further diagnostic steps or specific system logs to examine would be greatly appreciated. Thank you for your assistance.

Our business interface requests require disabling HTTP(s) proxies. We configured URLSessionConfiguration.connectionProxyDictionary as before, but found that it does not work on iOS 16.2 and 16.3.1. 1.Core code: let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ "HTTPEnable": false, "HTTPSEnable": false, "SOCKSEnable": false, ] let session = URLSession(configuration: configuration) let request = URLRequest(url: URL(string: "https://www.baidu.com")!,timeoutInterval: Double.infinity) // 发送请求 let task = session.dataTask(with: request) { data, response, error in if let error = error { print("网络请求失败: \(error)") } if let data = data { print("网络请求成功，返回数据长度: \(data.count)") if let responseString = String(data: data, encoding: .utf8) { print("返回数据: \(responseString.prefix(100))...") } } } task.resume() 2.Specific steps: We captured traffic using Proxyman and Charles. With the same code, requests cannot be captured on iOS 18 and iOS 16.1, but can be captured on iOS 26.2 and 26.1. Conclusion:Therefore, we suspect there is a bug with URLSessionConfiguration.connectionProxyDictionary on iOS 26.x. Please let us know whether this is a bug. If not, how should we properly disable HTTP(s) proxies? Note: We need to exclude PAC proxies, which are commonly used in corporate internal networks. 3.Devices & Soft Xcode 16.4 iPhone 26.2、Simulator 26.1 Proxyman、Charles

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

https://developer.apple.com/documentation/corewlan/cweventtype/linkqualitydidchange As per the documentation core WLAN will send notification when there is a change in RSSI. I did not receive any notification when there is a change in RSSI.

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

While going through the documentation for NWConnection, there seems to be state known as .waiting which means that the connection is waiting for a path change. For TCP, the state is understandable and can occur under some scenarios. But for the case of UDP, I have following queries: Why do we need .waiting state for the case of UDP? Even if we do need .waiting state for UDP, when all does this state occurs?

Here’s the formatted summary in English for your issue submission: Issue Summary We are activating a Network Extension system extension (filter-data) from a signed and notarized macOS app. Activation consistently fails with the following error: Error Message: OSSystemExtensionErrorDomain code=4 Extension not found in App bundle. Unable to find any matched extension with identifier: com.seaskylight.yksmacos.ExamNetFilter.data At the same time, sysextd logs show: no policy, cannot allow apps outside /Applications However, our host app and executable paths are already under /Applications, and the extension bundle physically exists in the expected app bundle location. Environment Information macOS: Darwin 25.4.0 Host App: /Applications/xxx.app Host Bundle ID: com.seaskylight.yksmacos System Extension Bundle ID: com.seaskylight.yksmacos.ExamNetFilter.data Team ID: BVU65MZFLK Device Management: Enrolled via DEP: No MDM Enrollment: No Reproduction Steps Install the host app to /Applications. Launch the host app via Finder or using the command: open -a "/Applications/xxx.app" Trigger OSSystemExtensionRequest activationRequestForExtension for: com.seaskylight.yksmacos.ExamNetFilter.data. Observe failure callback (code=4). Collect logs: log show --last 2m --style compact --info --debug --predicate 'process == "sysextd"' Check extension status using: systemextensionsctl list (shows 0 extension(s)) Observed Results sysextd client activation request for com.seaskylight.yksmacos.ExamNetFilter.data attempts to realize extension with identifier com.seaskylight.yksmacos.ExamNetFilter.data. Log indicates: no policy, cannot allow apps outside /Applications App-side Diagnostics (captured at failure) PID: 3249 Bundle Path: /Applications/xxx.app Real Path: /Applications/xxx.app Exec Path: /Applications/xxx.app/Contents/MacOS/xxx Real Exec Path: /Applications/xxx.app/Contents/MacOS/xxx Ext Path: /Applications/xxx.app/Contents/Library/SystemExtensions/ExamNetFilterData.systemextension Ext Exists: true Running From Helper: false Error Callback: NSError{domain=OSSystemExtensionErrorDomain code=4 desc=Extension not found in App bundle...} Additional Validation We reproduced the same failure using a minimal native host app (SysExtProbe) in /Applications that only submits the activation request for the same extension identifier. It also fails with OSSystemExtensionErrorDomain code=4, indicating this is not specific to Electron app logic. Signing / Packaging Notes Host app and system extension are signed with the same Team ID (BVU65MZFLK). System extension bundle exists under: /Applications/xxx.app/Contents/Library/SystemExtensions/ExamNetFilterData.systemextension Extension Info.plist contains bundle id: com.seaskylight.yksmacos.ExamNetFilter.data Host app includes NSSystemExtensionUsageDescription. Questions for DTS In non-MDM personal-device scenarios, what exact conditions trigger sysextd to emit: no policy, cannot allow apps outside /Applications even when both bundlePath and realpath are in /Applications? Can code=4 (“Extension not found in App bundle”) be returned for policy/state reasons even when the extension bundle is present and the identifier matches? Are there known sysextd policy/cache states that cause this behavior, and what is the recommended recovery procedure? Feel free to copy and paste this summary for your submission. If you need any further modifications or assistance, let me know!

Hello team, I am trying to find out a way to block urls in the chrome browser if it is found in local blocked list cache. I found URL Filter Network very much suitable for my requirement. But I see at multiple places that this solution is only for Enterprise level or MDM or supervised device. So can I run this for normal user ? as my targeting audience would be bank users. One more thing how can I test this in development environment if we need supervised devices and do we need special entitlement ? When trying to run sample project in the simulator then getting below error

Hello, I am currently developing a PIR server using the pir-server-example repository. We are anticipating a total of 10 million URLs for our dataset. In this context, what would be the optimal shard size (number of records per shard) to balance computational latency and communication overhead? Any advice or best practices for handling a dataset of this scale would be greatly appreciated. Thank you.

We've received several reports of a new bug while setting up our products with WAC. The Accessory Setup UI appears with a blank network selected and the message 'This accessory will be set up to join "(null)".' at top. The user can tap "Show Other Networks..." to select another network, but this experience is very confusing. Why does this UI present a choice that is known to be invalid when other valid choices exist? I've captured a screenshot and sysdiagnose from this case. In most cases this problem happens only intermittently, but I can reproduce it consistently by disconnecting my iPhone from any WiFi network (WiFi remains enabled). My suggestion for a better user experience is that this UI should select the default network according to these rules: The network to which iPhone is currently connected. Any network which is in the known/my list for this iPhone Any valid network I believe rule #1 is the existing behavior, but applying rules #2 and #3 as fallbacks would be an improvement. Is there anything I can change in my iOS code or in my accessory's WAC server to improve this experience?

Hi I tried to follow this guide https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url I downloaded the sample app and put our pir service server address in the app. The service is already running and the app is connected to the pir service but the url is still not blocked. We tried to block example.com. Is there anything that we need to do in iOS code? This is the sample when there's dataset This is the sample when there's no dataset

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)

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.

We are building a VPN using NEPacketTunnelProvider where the intent is to route HTTP/S traffic through a local proxy server, while non-HTTP/S traffic flows directly to the network without being tunnelled at the IP layer. The configuration claims no included IP routes — it relies entirely on NEProxySettings to intercept HTTP/S traffic via the URL loading layer. private func configureIPSettings(_ settings: NEPacketTunnelNetworkSettings) { settings.ipv4Settings = NEIPv4Settings( addresses: ["192.168.1.1"], subnetMasks: ["255.255.255.255"] ) // No includedRoutes set — no IP traffic enters the tunnel } private func configureProxySettings(_ settings: NEPacketTunnelNetworkSettings) { let proxySettings = NEProxySettings() proxySettings.httpEnabled = true proxySettings.httpServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.httpsEnabled = true proxySettings.httpsServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.matchDomains = [""] settings.proxySettings = proxySettings } When matchDomains is nil or not set, HTTP/S traffic does not reach the local proxy in this configuration. Setting matchDomains = [""] makes it work correctly. The matchDomains documentation states: "If the destination host name of a HTTP connection shares a suffix with one of these strings then the proxy settings will be used." An empty string is a suffix of every string, so [""] matching all hostnames follows from that definition. But this isn't explicitly documented. Questions: Is matchDomains = [""] a supported and stable way to apply proxy settings to all HTTP/S traffic when no IP routes are claimed, or is this an unintended side-effect? Why does matchDomains = nil not apply the proxy globally in this configuration? The documentation doesn't describe its behaviour relative to IP routing. NEDNSSettings.matchDomains explicitly documents an empty string as matching all domains — is the same semantics intended for NEProxySettings.matchDomains?

I've been able to run this sample project with the PIRServer. But the urls are still not blocked. https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url https://github.com/apple/pir-service-example I got this on the log Received filter status change: <FilterStatus: 'running'>

When using the official Wi-Fi Aware demo app on iOS, with the iOS device configured as a NAN Subscriber, after successfully establishing a peer-to-peer connection with another device via Wi-Fi Aware (NAN), the network path object nwPath.availableInterfaces does not list the nan0 virtual network interface. The nan0 interface is the dedicated NAN (Neighbor Aware Networking) interface used for Wi-Fi Aware data communication. Its absence from availableInterfaces prevents the app from correctly identifying/using the NAN data path, breaking expected Wi-Fi Aware data transmission logic. log: iOS works as subscriber: [onPathUpdate] newPath.availableInterfaces: ["en0"] iOS works as publisher: [onPathUpdate] newPath.availableInterfaces: ["nan0"]

Hi, I see an interaction issue between a DNS Proxy system extension and MDM on macOS: after some time the device stops processing MDM commands until reboot, while DNS filtering continues to work. Environment: macOS: 15.x / 26.x (reproduced on multiple minor versions) App: /Applications/MyMacProxy.app System extension: NEDNSProxyProvider as system extension Bundle id: com.company.agent.MyMacProxy.dnsProxy Deployment: MDM (SimpleMDM) DNS proxy config via com.apple.dnsProxy.managed Devices: supervised Macs Steps to reproduce: Enrol Mac into MDM. Install MyMacProxy app + DNS proxy system extension via pkg and apply com.apple.dnsProxy.managed profile. DNS proxy starts, DNS is filtered correctly, user network works normally. After some hours, try to manage the device from MDM: push a new configuration profile, remove an existing profile, or install / remove an app. 5.MDM server shows commands as pending / not completed. On the Mac, DNS is still filtered via our DNS proxy, and general network access (Safari etc.) continues to work. After reboot, pending MDM commands are processed and we can remove the app, profile and system extension normally. This is reproducible on our test machines. What I see on the Mac in the “stuck” state apsd is running: sudo launchctl print system/com.apple.apsd # job state = running com.apple.mdmclient.daemon exists as a job but is not running: sudo launchctl print system/com.apple.mdmclient.daemon Abbreviated output: system/com.apple.mdmclient.daemon = { ... state = not running job state = exited runs = 5 last exit code = 0 ... } So the MDM client daemon has exited cleanly (exit code 0) and is currently not running; its APS endpoints are configured. Our DNS proxy system extension is still processing flows: we see continuous logging from our NEDNSProxyProvider, and DNS filtering is clearly active (requests go through our upstream). systemextensionsctl list still shows our DNS proxy system extension as active. From the user’s perspective, everything works (with filtered DNS). From the MDM server’s perspective, commands stay pending until the next reboot. After reboot, MDM behaviour is normal again. Uninstall / cleanup (current approach, simplified) We currently use an MDM‑delivered shell script that: disables our DNS proxy configuration for the console user by editing ~/Library/Preferences/com.apple.networkextension.plist and setting Enabled = false for our DNSProxyConfigurations entries; flushes DNS cache and restarts mDNSResponder; unloads our LaunchDaemon / LaunchAgent for the host app; kills the system extension process using pgrep -f "com.company.agent.MyMacProxy.dnsProxy" | xargs kill -9; removes the extension binary from /Library/SystemExtensions/.../com.company.agent.MyMacProxy.dnsProxy.systemextension; removes /Applications/MyMacProxy.app and related support files. We currently do not call systemextensionsctl uninstall <TEAMID> com.company.agent.MyMacProxy.dnsProxy from MDM, mainly because of SIP and because we understand that fully silent system extension uninstall is constrained. The MDM responsiveness issue, however, can appear even if we don’t run this aggressive uninstall script and just let the extension run for some hours. Questions Is it expected that a DNS Proxy system extension (managed via com.apple.dnsProxy.managed) can leave a device in a state where: apsd is running, com.apple.mdmclient.daemon is not running (last exit code 0), DNS proxy continues to filter traffic, but MDM commands remain pending until reboot? Are there known best practices or pitfalls when combining: DNS Proxy system extensions (NEDNSProxyProvider), MDM‑distributed com.apple.dnsProxy.managed profiles, and MDM app / profile management on recent macOS versions? For uninstall in an MDM environment, what pattern do you recommend? For example, is it better to: disable / remove the DNS proxy profile, stop the NE configuration via NEDNSProxyManager from the app, avoid killing the system extension or removing files from /Library/SystemExtensions immediately, and instead require a reboot for full removal? I can provide a sysdiagnose and unified logs (including nesessionmanager, mdmclient and our logs) from an affected machine if that would be helpful.

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.

Hi, I’m looking for clarification on TN3134: Network Extension provider deployment, specifically iOS deployment requirements for: packet tunnel provider DNS proxy provider From the documentation: Packet Tunnel Provider App extension (min iOS 9.0): per-app mode requires a managed device DNS Proxy Provider App extension (min iOS 11.0): supervised devices only App extension (min iOS 11.0): per-app mode requires managed devices Issue I implemented a DNS proxy using NEDNSProxyManager. Works as expected in debug builds on a local device Fails to configure when distributed via TestFlight Console Output (TestFlight build) error 10:05:39.872258-0500 nehelper The production version of *** is not allowed to create DNS proxy configurations. Use MDM to create DNS Proxy configurations for the production version of ***. Question Is it possible to distribute a DNS proxy provider for use on non-MDM / non-supervised devices? If not: Is the limitation strictly enforced at distribution/runtime? Is a packet tunnel provider the only viable alternative for App Store distribution? There is a lot of different VPN apps on the App Store that appear to work out of the box without MDM or supervision, which suggests they are using a different deployment model. Thank you for any clarification or guidance!