Hello, I am working to integrate the new com.apple.developer.networking.carrier-constrained.app-optimized entitlement in my iOS 26 app so that my app can use a carrier-provided satellite network, and want to confirm my understanding of how to detect and optimize for satellite network conditions. (Ref: https://aninterestingwebsite.com/documentation/bundleresources/entitlements/com.apple.developer.networking.carrier-constrained.app-optimized ) My current approach: I plan to set the entitlement to true once my app is optimized for satellite networks. To detect if the device is connected to a satellite network, I intend to use the Network framework’s NWPath properties: isUltraConstrained — I understand this should be set to true when the device is connected to a satellite network. (Ref: https://aninterestingwebsite.com/documentation/network/nwpath/isultraconstrained ) linkQuality == .minimal — I believe this will also be set in satellite scenarios, though it may not be exclusive to satellite connections. (Ref: https://aninterestingwebsite.com/documentation/network/nwpath/linkquality-swift.enum/minimal ) Questions: Is it correct that isUltraConstrained will reliably indicate a satellite connection? Should I also check for linkQuality == .minimal, or is isUltraConstrained sufficient? Are there any additional APIs or best practices for detecting and optimizing for satellite connectivity that I should be aware of? Thank you for confirming whether my understanding and approach are correct, and for any additional guidance.

What is the best way to detect if the Wifi is being used for Wireless Carplay or is just a normal network interface?

There are multiple report of crashes on URLConnectionLoader::loadWithWhatToDo. The crashed thread in the stack traces pointing to calls inside CFNetwork which seems to be internal library in iOS. The crash has happened quite a while already (but we cannot detect when the crash started to occur) and impacted multiple iOS versions recorded from iOS 15.4 to 18.4.1 that was recorded in Xcode crash report organizer so far. Unfortunately, we have no idea on how to reproduce it yet but the crash keeps on increasing and affect more on iOS 18 users (which makes sense because many people updated their iOS to the newer version) and we haven’t found any clue on what actually happened and how to fix it on the crash reports. What we understand is it seems to come from a network request that happened to trigger the crash but we need more information on what (condition) actually cause it and how to solve it. Hereby, I attach sample crash report for both iOS 15 and 18. I also have submitted a report (that include more crash reports) with number: FB17775979. Will appreciate any insight regarding this issue and any resolution that we can do to avoid it. iOS 15.crash iOS 18.crash

Hi everyone, I’m exploring Network Extension options for a use case where I need to log and filter network activity at the packet level. More specifically, I need the ability to detect and potentially block certain TCP behaviors during the handshake. From everything I’ve tested, NEFilterPacketProvider seems to be the only Network Extension type that operates early enough in the flow. NEFilterDataProvider appears to receive flows after the TCP handshake is already completed. It also has some limitations with IP-based filtering (might include hostname instead of IP), inconsistent ICMP behavior, etc. So I went with NEFilterPacketProvider. However, I’m running into a major issue: extremely high CPU usage. To isolate the problem, I stripped my packet handler down to the simplest possible implementation — basically returning .allow for every inbound/outbound packet without any filtering logic. Even with that minimal setup, playing one or two videos in a browser causes the CPU usage of the extension to spike to 20–50%. This seems to be caused purely by the packet volume. I haven’t found any way to pre-filter packets before the handler is invoked, nor any documented method to significantly optimize packet handling at this stage. It’s possible I’m missing something fundamental. Questions: Has anyone else experienced this kind of high CPU usage with NEFilterPacketProvider? Is there any recommended way to reduce the packet handling overhead or avoid processing every single packet? Any known best practices or configuration tips? Thanks in advance!

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.

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

Greetings.I have an app today that uses multipeer connectivity extensively. Currently, when the user switches away from the app, MPC disconnects the session(s) - this is by design apparently (per other feedback). I'd like to hear if anyone has experimented with iOS9 multitasking / multipeer and whether MPC sessions can stay alive?Thanks

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.

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

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.

Hello eveybody,Currently I'm working on an app which connects to a device. During testing I encounter an internal error of NEHotspotConfigurationErrorDomain. See the log snippet:Domain=NEHotspotConfigurationErrorDomain Code=8 "internal error." UserInfo={NSLocalizedDescription=internal error.}This error appears randomly. In one day I encountered it three times. The only solution I can think of is catching this error somehow and then telling the user to restart the device.After this error appears, the wifi functionality of iOS in all third party apps seems to be broken. Only restarting helps as far as I know. Also there seems to be nothing we as app developers can do about it. Therefor I wonder if there is some way to prevent this error somehow? The only solution I can think of is catching this error somehow and then telling the user to restart the device.Also since there is not much information about this error on the web, it would be really nice if someone can clarify whats going on with this error.Regards.

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?

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地址

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.

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?

In our system, when a user enables a mobile hotspot and the system connects to it, the system attempts to verify WIFI availability by sending an HTTP GET request to http://captive.apple.com. Normally, the server returns: HTTP Status: 200 (OK) Content-Type: text/html This has always been used as a sign of normal connectivity. Issue: Since last Friday, the server sometimes responds with: Content-Type: application/octet-stream When this occurs, our system determines that the network is unavailable and displays a connection warning (a “!” icon). Question: Has Apple recently made any backend or CDN configuration changes to captive.apple.com that could affect the response type? Any advice how can we solve this problem? Thanks!

Is there any way to forcibly disable using QUIC? I've noticed this ends up causing issues with our ISP / router, and noticed for many of our customers as well. Creating an ephemeral session doesn't change things, and setting the request to "assumeHttp3Capable" to false doesn't fix things either. We are using Cloudflare Workers as the URL we are hitting, and thus aren't able to disable this server-side.

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://aninterestingwebsite.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) } } }

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()