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)

Hello! I have read most of the "Background Tasks Resources" here https://developer.apple.com/forums/thread/707503 - but still have a few questions that I need clarified. To provide our context, our usecase is that our user wants to upload files to our servers. This is an active decision by the user to initiate the upload, but we also want make sure the files are uploaded, even if the user chooses to background our app. If we use a URLSession.backgroundto initiate the uploadTask, I understand that we are passing it of to the urlsession deamon to handle the upload. Which is great, if the user chooses to background our app. But, what if they just stay with the app in the foreground? Will it start uploading immediately? Can we expect the same latency that a standard URLSession will provide? And the potential delay will only occur if they actually background our app. Also, what happens if a background upload is in-progress and the user enters our app again? Will it gain priority, and run with similar latency as standard URL session? I.e., can we just always rely on using a background session, or should we kick of a beginBackgroundTask with a standard URL session, and only trigger a background uploadTask if we do not finish the standard upload before getting told we are about to get killed? A different question. I know there is the rate-limit delay added if we trigger multiple background URL tasks. Does that effect the following use case? We would like to send an additional HTTP request to our servers when the upload is completed, to notify it of the completion, but are we allowed to do that when the app is woken from the background? So, basically calling .dataTask from handleEventsForBackgroundURLSession for example?

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

We are using Multipeer Connectivity (MCSession, MCNearbyServiceBrowser, MCNearbyServiceAdvertiser) for nearby peer discovery and communication. **Observed behaviour: ** When Wi-Fi is ON (Not connected to any network) and Mobile Data is also ON: Peer discovery (foundPeer) consistently succeeds Invitation is sent using invitePeer MCSession transitions to .connecting The session remains indefinitely in .connecting connected is never reached notConnected is also not reported When Mobile Data is turned OFF, the same flow reliably reaches .connected. Key details: Both devices have Wi-Fi and Bluetooth enabled Browsing and advertising are active on both devices Application-level timeouts and session resets are implemented The Issue is reproducible across multiple devices with iOS 26 versions. Expectation / Question: We understand that Multipeer Connectivity does not use cellular data for peer discovery or transport. However, when Wi-Fi is available and peers are discovered successfully, we would like clarification on the following: Is it expected behavior that enabling Mobile Data can cause the invitation/connection phase to remain indefinitely in .connecting without transitioning to .notConnected? Are there recommended best practices to avoid stalled invitation or transport negotiation in this scenario? Is there a supported way to detect or recover from a stalled .connecting state beyond application-level timeouts and session resets? Any guidance on expected behavior or recommended handling would be appreciated.

We create custom VPN tunnel by overriding PacketTunnelProvider on MacOS. Normal VPN connection works seamlessly. But if we enable onDemand rules on VPN manager, intemittently during tunnel creation via OnDemand, internet goes away on machine leading to a connection stuck state. Why does internet goes away during tunnel creation?

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) Sometimes we have observed that on starting the transparent proxy extension, the startProxy overridden delegate method(override func startProxy(options: [String : Any]?, completionHandler: @escaping (Error?) -> Void) {) in our AppProxyProvider class which is derived from NETransparentProxyProvider being called more than once for the same extension(pid). This leads to Over-resume of an object crash as we invoke setTunnelNetworkSettings inside the startProxy delegate. As this is controlled by the system, we are not sure why this delegate being called more than once sometimes even if we call the start TransparentProxy only once. Note that, this issue is seen only in Mac OS Tahoe. Apple Feedback ticket: FB21464147 (startProxy delegate for NETransparentProxyProvider class is being called twice for the same pid extension sometimes)

It works when one device is only a publisher and the other is only a subscriber. However, when both devices act as both publisher and subscriber simultaneously—which Apple’s documentation (https://developer.apple.com/documentation/wifiaware/adopting-wi-fi-aware#Declare-services) indicates is valid—the connection never establishes. After timing out, both NetworkListener and NetworkBrowser transition to the failed state. This appears to be a race condition in Network framework. Task.detached { try await NetworkListener( for: .wifiAware( .connecting( to: .myService, from: .allPairedDevices, datapath: .defaults ) ), using: .parameters { Coder( sending: ..., receiving: ..., using: NetworkJSONCoder() ) { TCP() } } ).run { connection in await self.add(connection: connection) } } Task.detached { try await NetworkBrowser( for: .wifiAware( .connecting( to: .allPairedDevices, from: .myService ) ), using: .tcp ).run { endpoints in for endpoint in endpoints { await self.connect(to: endpoint) } } }

When using the NEHotspotConfigurationManager applyConfiguration interface for network connection.Sometimes there is a pop-up prompt when the connection fails, and sometimes there is no pop-up prompt. Why is there no pop-up prompt when the connection fails

When connecting to my M1 mac mini over ssh, certain programs are often unable to reach network destinations in the corporate LAN, although they can usually reach external addresses like www.apple.com. For example, a java program attempting to download from teamcity.dev.corp.com:8111 often fails like: java.net.NoRouteToHostException: No route to host Running the exact same command from the Apple Terminal program works like normal, simply connecting over ethernet on en0 to a TeamCity server inside the same building. Basic diagnostics from the ssh session do not show anything unusual: > traceroute teamcity.dev.corp.com traceroute to teamcity.dev.corp.com (10.21.4.1), 64 hops max, 40 byte packets 1 teamcity.dev.corp.com (10.21.4.1) 1.702 ms 0.409 ms 0.336 ms > route -n get teamcity.dev.corp.com route to: 10.21.4.1 destination: 10.21.4.1 interface: en0 flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 1194 > uname -a Darwin mac 25.1.0 Darwin Kernel Version 25.1.0: Mon Oct 20 19:32:47 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T8103 arm64 Similar problems occur in docker commands to a remote daemon ("no route to host" or "connection refused"): docker -H tcp://<ip>:<port> ... Most other programs are never affected by this problem. Are there other diagnostic steps that might reveal the cause?

For Local network access, Chrome prompts the user to allow access and adds it to Settings --> Privacy & Security --> Local Network. However, for Safari, no prompt appears. How do I force Safari to authorise these local network access requests if it won't trigger the permission dialogue? Is there a specific WKWebView configuration or Safari-specific header required to satisfy this security check?

We've often observed connectivity issues from our VPN app that can only be remedied by removing the VPN profile. It happens to a small but significant amount of our users, this often happens more when the app is updated, but the VPN profile corruption can happen without that too. The behavior we're observing is that any socket opened by the packet tunnel process just fails to send any data whatsoever. Stopping and restarting the packet tunnel does not help. The only solution is to remove the profile and create a new one. We believe our app is not the only one suffering from this issue as other VPN apps have added a specific button to refresh their VPN profile, which seemingly deletes and re-created the VPN configuration profile. Previously, we've caught glimpses of this in a sysdiagnose, but that was a while ago and we found nothing of interest. Alas, the sysdiagnose was not captured on a device with the network extension diagnostic profile (it was not a developer device). I would love to get technical support with this, as our bug reports have gone unanswered for long enough, yet we are still struggling with this issue. But of course, there is no minimum viable xcodeproject that reproduces this. Is there anything we can feasibly do to help with this issue? Is it even an acknowledged issue?

private static func getEthernetIPAddress(from interfaces: [String: String]) -> String? { // 常见虚拟以太网接口名（根据适配器型号可能不同） let poeEthernetInterfaces = ["en2", "en3", "en4", "en5", "eth0", "eth1"] for interfaceName in poeEthernetInterfaces { if let ethernetIP = interfaces[interfaceName], !ethernetIP.isEmpty { return ethernetIP } } return nil }//我们通过该方法去抓取有线网的IP地址，但是有的设备无法抓取到，怎样才能更准确的抓取到有线网络的IP地址

I want to know the reason for last Wi-Fi disconnection. It would be helpful to that I can get the reason-code received from the access point.

NWPathMonitor appears to retain itself (or is retained by some internal infrastructure) once it has been started until cancelled. This seems like it can lead to memory leaks if the references to to the monitor are dropped. Is this behavior documented anywhere? func nwpm_self_retain() { weak var weakRef: NWPathMonitor? autoreleasepool { let monitor: NWPathMonitor = NWPathMonitor() weakRef = monitor monitor.start(queue: .main) // monitor.cancel() // assertion fails unless this is called } assert(weakRef == nil) } nwpm_self_retain()

Hi, I am building an app that depends on multiple iOS devices connecting to a designated "coordinator" iOS device. I am using MPC, and it works great when the devices are connected to the same WiFi AP, with virtually 100% connection success. My definition of success is a near instant detection of available devices, >95% connection success rate, and a stable ongoing connection with no unexpected disconnects. The issue arises when the devices are not connected to the same WiFi network (or connected to no network with WiFi and bluetooth still on). Devices detect each other immediately, but when initiating a connection, both devices initiate a handshake, but the connection is not successful. In the few times where the connection succeeds, the connection quality is high, stable, and doesn't drop. Is this a known limitation of the framework? Could I be doing something wrong in my implementation?

We've received logs and have spuriously reproduced the following behavior: calls to setTunnelNetworkSettings completing with NETunnelProviderError where the code is networkSettingsInvalid, and the error domain string is empty. After subsequent calls to setTunnelNetworkSettings, the tunnel is stopped via the userInitiated stop reason within around 1 second from the first failure. This happens after a number of successful calls to setTunnelNetworkSettings have been made in the lifetime of a given packet tunnel process. We can confirm that no user ever initiates the disconnection. We can confirm that the only significant changes between the different calls to setTunnelNetworkSettings are that the parameters contain different private IPs for the tunnel settings - the routes and DNS settings remain the same. In our limited testing, it seems that we can replicate the behavior we're observing by removing the VPN profile while the tunnel is up. However, we are certain the same behavior happens under other circumstances without any user interaction. Is this what memory starvation looks like? Or is this something else? Our main concern is that the tunnel is killed and it is not brought back up even though our profile is set to be on-demand. It's difficult to give any promises about leaks to our users if the tunnel can be killed at any point and not be brought back. The spurious disconnections are a security issue for our app, we'd like to know if there's anything we can do differently so that this does not happen. We tried to get DTS, but given that we have no way to reproduce this issue with a minimal project. But we can reproduce the behavior (kill the tunnel by removing it's profile) from a minimal Xcode project, is that considered good enough for a reproduction?

Hi there, We have been trying to set up URL filtering for our app but have run into a wall with generating the bloom filter. Firstly, some context about our set up: OHTTP handlers Uses pre-warmed lambdas to expose the gateway and the configs endpoints using the javascript libary referenced here - https://developers.cloudflare.com/privacy-gateway/get-started/#resources Status = untested We have not yet got access to Apples relay servers PIR service We run the PIR service through AWS ECS behind an ALB The container clones the following repo https://github.com/apple/swift-homomorphic-encryption, outside of config changes, we do not have any custom functionality Status = working From the logs, everything seems to be working here because it is responding to queries when they are sent, and never blocking anything it shouldn’t Bloom filter generation We generate a bloom filter from the following url list: https://example.com http://example.com example.com Then we put the result into the url filtering example application from here - https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url The info generated from the above URLs is: { "bits": 44, "hashes": 11, "seed": 2538058380, "content": "m+yLyZ4O" } Status = broken We think this is broken because we are getting requests to our PIR server for every single website we visit We would have expected to only receive requests to the PIR server when going to example.com because it’s in our block list It’s possible that behind the scenes Apple runs sporadically makes requests regardless of the bloom filter result, but that isn’t what we’d expect We are generating our bloom filter in the following way: We double hash the URL using fnv1a for the first, and murmurhash3 for the second hashTwice(value: any, seed?: any): any { return { first: Number(fnv1a(value, { size: 32 })), second: murmurhash3(value, seed), }; } We calculate the index positions from the following function/formula , as seen in https://github.com/ameshkov/swift-bloom/blob/master/Sources/BloomFilter/BloomFilter.swift#L96 doubleHashing(n: number, hashA: number, hashB: number, size: number): number { return Math.abs((hashA + n * hashB) % size); } Questions: What hashing algorithms are used and can you link an implementation that you know is compatible with Apple’s? How are the index positions calculated from the iteration number, the size, and the hash results? There was mention of a tool for generating a bloom filter that could be used for Apple’s URL filtering implementation, when can we expect the release of this tool?

Hello team, Would this mean that content filters intended for all browsing can only be implemented for managed devices using MDM? My goal would be to create a content filtering app for all users, regardless of if their device is managed/supervised. thanks.

This is just an FYI in case someone else runs into this problem. This afternoon (12 Dec 2025), I updated to macOS 26.2 and lost my network. The System Settings' Wi-Fi light was green and said it was connected, but traceroute showed "No route to host". I turned Wi-Fi on & off. I rebooted the Mac. I rebooted the eero network. I switched to tethering to my iPhone. I switched to physical ethernet cable. Nothing worked. Then I remembered I had a beta of an app with a network system extension that was distributed through TestFlight. I deleted the app, and networking came right back. I had this same problem ~2 years ago. Same story: app with network system extension + TestFlight + macOS update = lost network. (My TestFlight build might have expired, but I'm not certain) I don't know if anyone else has had this problem, but I thought I'd share this in case it helps.

Hello, I’m reviewing the open-source mDNSResponder repository and have a question regarding licensing/provenance in mDNSCore/DNSDigest.c file. That file contains an embedded notice stating that parts of the MD5/digest implementation were derived from older OpenSSL sources and therefore include the legacy OpenSSL/SSLeay license text, even though OpenSSL itself is now Apache-2.0 starting from version 3.0. The legacy OpenSSL/SSLeay license is widely understood to impose additional attribution and notice requirements compared to Apache-2.0, and some downstream projects prefer to avoid it when a permissively licensed alternative is available. Repository: https://github.com/apple-oss-distributions/mDNSResponder File: https://github.com/apple-oss-distributions/mDNSResponder/blob/main/mDNSCore/DNSDigest.c#L66 I’d like to clarify a few points: Is the MD5/digest code in DNSDigest.c still based on pre–OpenSSL-3.0 sources, such that retaining the legacy OpenSSL/SSLeay license block is intentional and required? If the goal were to simplify licensing (Apache-2.0 only), would Apple consider replacing this MD5 implementation with an Apache-2.0–licensed alternative (for example, code derived from OpenSSL 3.x or another permissive implementation)? Are there any technical or policy reasons (compatibility, crypto policy, platform APIs) that make such a replacement undesirable? Since GitHub issues and PRs are restricted for this repository, I’m asking here for guidance. If maintainers agree that such an update would be useful, I’d be happy to help by preparing a PR for review. I've also created a feedback report for this topic, the reference ID is FB21269078. Thanks for any clarification.