Hello, I have been playing around the the SimpleURLFilter sample code. I keep getting this error upon installed the filter profile on the device: mapError unexpected error domain NEVPNConnectionErrorDomainPlugin code 7 which then causes this error: Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn’t be completed. (NetworkExtension.NEURLFilterManager.Error error 14.)'> I can't find much info about code 7. Here is the configuration I am trying to run: <Configuration: pirServerURL: 'http://MyComputer.local:8080' pirAuthenticationToken: 'AAAA' pirPrivacyPassIssuerURL: 'http://MyComputer.local:8080' enabled: 'true' shouldFailClosed: 'true' controlProviderBundleIdentifier: 'krpaul.SimpleURLFilter.SimpleURLFilterExtension' prefilterFetchInterval: '2700.0'>

I am trying to setup a system-wide DNS-over-TLS for iOS that can be turned off and on from within the app, and I'm struggling with the implementation details. I've searched online, searched forums here, used ChatGPT, and I'm getting conflicting information or code that is simply wrong. I can't find example code that is valid and gets me moving forward. I think I need to use NEDNSProxyProvider via the NetworkExtension. Does that sound correct? I have NetworkExtension -> DNS Proxy Capability set in both the main app and the DNSProxy extension. Also, I want to make sure this is even possible without an MDM. I see conflicting information, some saying this is opened up, but things like https://developer.apple.com/documentation/Technotes/tn3134-network-extension-provider-deployment saying a device needs to be managed. How do private DNS apps do this without MDM? From some responses in the forums it sounds like we need to parse the DNS requests that come in to the handleNewFlow function. Is there good sample code for this parsing? I saw some helpful information from Eskimo (for instance https://developer.apple.com/forums/thread/723831 ) and Matt Eaton ( https://developer.apple.com/forums/thread/665480 )but I'm still confused. So, if I have a DoT URL, is there good sample code somewhere for what startProxy, stopProxy, and handleNewFlow might look like? And valid code to call it from the main app?

How often do we see control filter start and stop? I read somewhere that data filter is long lived and control Filter is short lived. When does the operating system kills the control filter process?

1) Blocked page UX When a URL is blocked, the browser typically shows a generic error like “"Safari cannot open the page because it couldn’t load any data,” with no indication that the page was blocked by a policy. Is there any plan to add an API that allows developers to present a custom “blocked” page or remediation action, similar to NEFilterControlProvider’s remediationMap? Even a minimal hook (custom HTML, deep link, or support URL) would make the experience clearer for users. 2) Cross‑app link‑opening behavior With a block rule in place, direct navigation in Safari is blocked as expected. However, tapping the same URL in a messaging app (e.g., WhatsApp) opens Safari - and the page loads, not blocked. Repro steps: Configure a URL Filter extension that blocks https://example.com. Case A: Open a browser and type the URL in the address bar → blocked (expected). Case B: Tap the same URL in WhatsApp (or another messenger) → a browser opens and the page loads (unexpected). iOS version - 26.0

I was exploring the scenarios where an NWListener or NWConnection can be invalidated or reclaimed by the OS itself. I came across the document TN2277: Networking and Multitasking, which discusses situations where iOS can reclaim the underlying socket descriptor. The document states: while the app is suspended the system may choose to reclaim resources out from underneath a network socket used by the app, thereby closing the network connection represented by that socket. From this, I understand that when the app is in a suspended state, the OS may reclaim the socket descriptor. My questions are: In what scenarios does the OS not reclaim the socket descriptor while the app is suspended, and in which cases does it reclaim it? When reclamation occurs, does the OS reclaim 'a' single NWListener/NWConnection, or does it reclaim 'all' NWListener/NWConnections opened by the application? Thanks.

Title / Summary Crash in libquic.dylib when app is backgrounded and issues an HTTP/3 request Description On iOS 26, the app crashes inside libquic.dylib while performing a network request using HTTP/3 (QUIC) after the app has moved to the background. The crash happens within low-level QUIC / libquic internals. Reproduction Steps Launch the app, perform normal operations. Background the app (press home / switch away). While in background, trigger a network request that uses HTTP/3 / QUIC. Observe that the app crashes (stack trace pointing into libquic.dylib). Expected Behavior The HTTP/3 request in background should either be handled gracefully (fail or complete) without causing a crash; the app must not be terminated due to internal libquic failures. Actual Behavior The app crashes with signals/exceptions coming from libquic.dylib (in the QUIC / packet building / encryption / key state logic) when a HTTP/3 request is made in background. Environment / Device Information • OS: iOS 26 • Device: iPhone 13 Pro Max • Network environment: (Wi-Fi / Cellular) • HTTP/3 support: enabled in URLSession / Network framework Stack Trace： 8eedc0df3d914b0faf8def9af3b21574-symbolicated.crash

We are using wifi_aware demo at https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps. We use iPhone 16 with ios26 to install this app successfully for the first time. After then we want to remove some paired devices, but the function used to delete paired device is not founded. So we uninstall the app, and intend to install it again. This time, it jump to the interface displaying the message "This device does not support Wi-Fi Aware". We are confused by this and don't know what to do. Instead of using other devices, how can we successfully install the app on this device. The iphone, Apple computer and Xcode environment maintain the same for sure. We sincerely appreciate your reply.

We currently have a PacketTunnelProvider providing a VPN connection to managed devices. Our profile locks this down with OnDemandEnabled and OnDemandUserOverrideDisabled set to true. We've had reports of the OnDemand feature not kicking in on macOS when switching profiles or creating new profiles for managed users (but this works for the initial user login). When switching profiles, OnDemand does not enable; however, if the user manually enables the VPN and then disables, OnDemand will now correctly turn the connection back on. The installed profile contains: OnDemandEnabled: 1 OnDemandRules: Connect Action for WiFi, Cellular, and Ethernet OnDemandUserOverrideDisabled: 1 From sysdiagnose logs, I see some interesting logs for nesessionmanager: Handling a network changed event Resetting VPN On Demand Found 0 registrations for [...].PacketTunnel Failed to find [...].PacketTunnel app extension using neagent Plugin is not available in launch services Plugin is not installed (I also see some failures with LSApplicationProxy, but not sure if those are relevant.) Eventually, I see: Plugin is installed Enabling VPN On Demand And things seem to kick off more as expected from that point on. Do we have any guidance on how to address this issue? We also have a ticket submitted with Feedback Assistant.

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.

I have been playing around with the new URL Filtering API. I have successfully installed and configured the sample code, Installed the example app to my iPhone, and am also running the PIR server locally on my Mac. In my input.txtpb file, I simply have 2 endpoints: rows: [{ keyword: "instagram.com", value: "1" }, { keyword: "youtube.com/shorts", value: "1" }] Neither of these are blocked when I attempt to load them from either a browser, or their dedicated apps. Are there any debugging tips I should know about? Additionally, I have also noticed a few times I have left the filter running on my phone, after leaving my LAN (where the PIR server is running), suddenly throughout the day I'm having random, completely unrelated endpoints blocked on my phone. I thought this API was never supposed to produce false positives (without calling back to the PIR server for confirmation).

Hello, we are developing hardware that needs to connect to an iPhone via Wi-Fi to send requests to a server. On Android, we have managed to create a programmatic local hotspot within the app to facilitate connection and improve the user experience. On iOS, however, Personal Hotspot must be manually enabled from the system settings, and the user must manually enter the SSID and password, which significantly degrades the UX. My questions are: Is there a workaround, unofficial method, or private API to generate a local hotspot from an app on iOS, similar to what can be done on Android? Is there an alternative within the MFi program or through specific frameworks to facilitate a quick and automatic connection between the hardware and the iPhone without relying on the manual Personal Hotspot? Are there any best practices for improving the local Wi-Fi connection experience between an accessory and an iPhone in the absence of hotspot controls? I would appreciate any guidance, experience, or resources that would help me better understand the feasible options in iOS for scenarios where fast and direct communication between hardware and mobile devices via Wi-Fi is required.

Hi! I wrote an internal used backup command line tool which is in use since several years. Today I got an error while sending an email: “Failed: ioOnClosedChannel”. I assume that the latest macOS updates did break my app. On the server I use macOS 15.7 and on my development machine macOS 26. Here is the related code: private func sendMail() { var a : [Email.Attachment] = [] if self.imageData != nil { switch self.imageType { case .tiff: a.append(Email.Attachment(name: "Statistics.tif", contentType: #"image/tiff"#, contents: ByteBuffer(bytes: self.imageData!))) case .pdf: a.append(Email.Attachment(name: "Statistics.pdf", contentType: #"application/pdf"#, contents: ByteBuffer(bytes: self.imageData!))) case .unknown: fatalError("Unimplemented attachment type!") } } mailHtml = mailHtml.replacingOccurrences(of: "<br>", with: "<br>\n") let email = Email(sender: .init(name: "Backup", emailAddress: "SENDER@MYDOMAIN"), replyTo: nil, recipients: recipients, cc: [], bcc: [], subject: self.subject, body: .universal(plain: self.mailText, html: mailHtml), attachments: a) let evg = MultiThreadedEventLoopGroup(numberOfThreads: System.coreCount) let mailer = Mailer(group: evg, configuration: smtpConfig, transmissionLogger: nil) do { print("Sending mail... ", terminator: "") try mailer.send(email: email).wait() // <-- ERROR HERE Failed: ioOnClosedChannel print("done.") } catch { print("Failed: \(error)") } do { try evg.syncShutdownGracefully() } catch { print("Failed shutdown: \(error)") } } I use https://github.com/sersoft-gmbh/swift-smtp. Any clue about the reason of this error? TIA, GreatOm

Device: iPhone 17 Series System: iOS 26.0.0 Wi-Fi: TKIP encryption protocol Question: Unable to join the network We have several products that are used by connecting to iPhone via Wi-Fi. Recently, many customers who have purchased the iPhone 17 series have reported that they are unable to connect to Wi-Fi. For Wi-Fi with TKIP encryption, after entering the password correctly to connect to the Wi-Fi, a pop-up appears stating "Unable to join the network.". Only Wi-Fi with WPA2-AES can be used normally. Before that, during the iPhone 11 era or even earlier, the TKIP encryption method was in normal use. However, the new iPhone models were incompatible with it, which obviously caused great inconvenience. I hope the engineers can fix this issue to support Wi-Fi with older encryption protocols.

We have a customer reporting a bunch of problems with our (Transparent Proxy Provider-based) suite. Looking at a sysdiagnose, I see that our GUI applet was killed: Termination Reason: Namespace PORT_SPACE, Code 14123288431434181290 (Limit 305834 ports) Exceeded system-wide per-process Port Limit Looking at the top.txt file from it, I see that it has 193,086 ports -- compared to about ~250 on one of my test systems. Has anyone run into this? Any idea what might be causing it? (I'm still poring over the sysdiagnose, but I don't see any kernel logs around that time -- except that our process does close a dozen or so ports because of cancellation.)

Macbook OS Version: macOS 14.7.3 (23H417) Mobile OS: iOS Mobile OS Version: iOS 18.6.2 Mobile Manufacturer: Apple Mobile Model: iPhone 12 Pro Max Page Type: vue vue Version: vue2 Packaging Method: Cloud Packaging Project Creation Method: HBuilderX Steps: The backend server is deployed on AWS in Japan with a Japanese IP. Packaging the APP in HBuilderX and publishing it to the Apple App Store were both successful. In a subsequent version, we planned to add a push notification feature and selected uniPush V2. Due to the separation of frontend and backend, the frontend APP implements functions such as registration, login, password change, page content display, and product lists through the server's RESTful APIs. Test colleagues reported that the APP could not load pages when used in Japan; however, it worked normally in China. In China: Pinging the server IP and domain from a MacBook was successful. Testing the API with Postman on a MacBook was successful. In Japan: Pinging the server IP and domain from a MacBook was successful. Testing the API with Postman on a MacBook failed with the error: HandshakeException: Connection terminated during handshake This appears to be an SSL communication failure. We tested the SSL certificate using www.ssllabs.com/ssltest and received an A+ rating. The certificate should not be an issue. we deselected uniPush V2, repackaged the APP, and uploaded it to TestFlight. The result remained the same: the APP content failed to load in Japan, while it worked normally in China. Expected Result: Access to the Japanese server APIs should work normally both in China and Japan. Actual Result: The APP content fails to load when used in Japan, but works normally in China.

I encountered an undesired DNS behaviour when using L2TP/ipsec VPN. I have DHCP configured Wi-Fi connection, which send dns servers and search domain (192.168.0.10, lan) VPN sends its own DNS server (10.0.0.2), search domain (intranet) is added manually in VPN DNS config settings. I expect, when VPN is connected, to be still able to resolve local names, i.e some-host.lan. However, they become unresolvable. quick check shows that the remote dns server is used to resolve local names. shilishper@mac ~ % host -v some-host.lan Trying "some-host.lan" Host some-host.lan not found: 3(NXDOMAIN) Received 106 bytes from 10.0.0.2#53 in 16 ms Received 106 bytes from 10.0.0.2#53 in 16 ms Actually, all dns queries are going to the remote server. I would expect that only queries for the configured domain (intranet) should go to that server. I played with the service order, but it didn't change anything. Is anything can be done about this, programmatically? PS new to macOS, but have extensive linux knowledge

Hi, I have a VPN product for macOS. When activated, it creates a virtual interface that capture all outgoing traffic for the VPN. the VPN encrypt it, and send it to the tunnel gateway. The gateway then decapsulates the packet and forwards it to the original destination. To achieve this, The vpn modifies the routing table with the following commands: # after packets were encoded with the vpn protocol, re-send them through # the physical interface /sbin/route add -host <tunnel_gateway_address_in_physical_subnet> <default_gateway> -ifp en0 > /dev/null 2>&1 # remove the default rule for en0 and replace it with scoped rule /sbin/route delete default <default_gateway> -ifp en0 > /dev/null 2>&1 /sbin/route add default <default_gateway> -ifscope en0 > /dev/null 2>&1 # create new rule for the virtual interface that will catch all packets # for the vpn /sbin/route add default <tunnel_gateway_address_in_tunnel_subnet> -ifp utunX > /dev/null 2>&1 This works in most cases. However, there are scenarios where the VPN process may crash, stop responding, or another VPN product may alter the routing table. When that happens, packets may no longer go out through the correct interface. Question: Is there a way to reliably reconstruct the routing table from scratch in such scenarios? Ideally, I would like to rebuild the baseline rules for the physical interface (e.g., en0) and then reapply the VPN-specific rules on top. Are there APIs, system utilities, or best practices in macOS for restoring the original routing configuration before reapplying custom VPN routes? Thanks

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?

Android phones supporting Wi-Fi Aware 4.0 should be able to connect with iPhones (iOS 26). For testing, we selected two Samsung S25 devices, which support Wi-Fi Aware 4.0. Issues we are facing Android as Publisher, iOS as Subscriber, iOS cannot discover the service. Log shows: Discovery: Dropping event, 02:14:60:76:a6:0f missing DCEA attribute. iOS as Publisher, Android as Subscriber.Android can discover the service.However, the PIN code is not displayed on iOS. From the packet capture, the publish packet does not contain the DCEA field. However, Android-to-Android devices can still pair normally, and the subsequent PASN packets include the DCEA field. It seems that the Wi-Fi Alliance only requires the DCEA to be present in the PASN packets. iOS cannot discover Android devices or complete pairing — is this caused by the DCEA field, or by other reasons?

Background Android phones supporting Wi-Fi Aware 4.0 should be able to connect with iPhones (iOS 26). For testing, we selected two Samsung S25 devices, which support Wi-Fi Aware 4.0. Issues we are facing Android as Publisher, iOS as Subscriber.iOS cannot discover the service. Log shows: Discovery: Dropping event, 02:14:60:76:a6:0f missing DCEA attribute. iOS as Publisher, Android as Subscriber,Android can discover the service.However, the PIN code is not displayed on iOS. From the packet capture, the publish packet does not contain the DCEA field. However, Android-to-Android devices can still pair normally, and the subsequent PASN packets include the DCEA field. It seems that the Wi-Fi Alliance only requires the DCEA to be present in the PASN packets. iOS cannot discover Android devices or complete pairing — is this caused by the DCEA field, or by other reasons?