Since beta 5 of iOS 27 a new entitlement is required to use THClient.enableCredentialSharingModeForExtendedPANID Code that was running fine with previous betas is now displaying an error : 'Did fail sharing credentials: Error Domain=ThreadCredentialsStore Code=14 "CredShare: Failed to enable Credential Sharing Mode; Missing entitlement" UserInfo={NSLocalizedDescription=CredShare: Failed to enable Credential Sharing Mode; Missing entitlement}' I cannot find any mention of this requirement in header or documentation. Has anybody informations about this ? Regards, Jerome T

Hello, We are developing an enterprise iOS application for cellular network benchmarking, performance validation, and network analytics. After reviewing the publicly available iOS frameworks and APIs, including CoreTelephony, we have not identified a supported public API that provides access to the following cellular RF and network measurements: • ARFCN • Band • Bandwidth (BW) • Cell ID • PCI (Physical Cell Identity) • CQI (Channel Quality Indicator) • RSRP (Reference Signal Received Power) • RSRQ (Reference Signal Received Quality) • SINR / SNR • RSSI • TAC (Tracking Area Code) • TA (Timing Advance) As an example, we are interested in obtaining information similar to the following: { "arfcn": "", "band": "", "bw": "", "cellId": "", "cqi": "", "pci": "", "rsrp": "", "rsrq": "", "sinr": "", "rssi": "", "ta": "", "tac": "" } Could Apple please clarify whether any of these measurements are available through an officially supported mechanism, including but not limited to: • Public iOS frameworks or APIs • Special entitlements • Carrier partner programs or integrations • Apple-approved diagnostics or measurement frameworks • Any other Apple-supported programs or access mechanisms We are not seeking to use private APIs, reverse-engineering techniques, or unsupported approaches. Our objective is solely to determine whether Apple provides a legitimate and supported method for an application to access any of these cellular network metrics on iOS devices. If access to any subset of these measurements is supported, we would greatly appreciate guidance regarding the relevant documentation, framework, entitlement, carrier program, or enrollment process. Our use case is limited to: • Cellular network benchmarking • Performance validation and testing • Network quality analytics Thank you for your guidance and assistance.

Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 "Golden Gate" Public Beta. The exact same build/binary works correctly on: macOS 26 "Tahoe" (shipping release) macOS 27 "Golden Gate" Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an "undetermined" state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network, and with tccutil reset LocalNetwork failing both per-app and system-wide (there's no grant to reset in the first place). We'd like a sanity check / to know if others are seeing this, and whether there's a known workaround. Environment App: com.example.Client, non-sandboxed Target: https://:/api/... macOS versions tested: macOS 26 Tahoe — OK; macOS 27 Golden Gate Developer Beta — OK; macOS 27 Golden Gate Public Beta (build: 26A5388g) — fails Mac model: Mac mini Xcode version used to build: 27 beta 2 Error details URLSession completion error: Error Domain=NSURLErrorDomain Code=-1009 "..." UserInfo={ _kCFStreamErrorCodeKey=50, NSUnderlyingError=0x... { Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={ _NSURLErrorNWPathKey=..., _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1 } }, ... } _kCFStreamErrorDomainKey=1 is kCFStreamErrorDomainPOSIX, and code 50 is ENETDOWN. Console log for the same request shows the failure at the connection layer, before any TLS/HTTP activity: Connection 1: received failure notification Connection 1: failed to connect 1:50, reason -1 Connection 1: encountered error(1:50) Task <...>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) What we've ruled out / tried Added NSLocalNetworkUsageDescription to Info.plist — no change in behavior. Confirmed via codesign -d --entitlements - and plutil -p Info.plist that the built/signed app bundle actually contains the key. Checked System Settings → Privacy & Security → Local Network — the app itself does not even appear in the list. Tried resetting the Local Network TCC grant: sudo tccutil reset LocalNetwork com.example.Client → tccutil: Failed to reset LocalNetwork approval status for com.example.Client Also tried a full reset for the service (no bundle id): sudo tccutil reset LocalNetwork → tccutil: Failed to reset LocalNetwork Confirmed tccutil itself is functioning normally on this machine — resetting other services succeeds, e.g.: sudo tccutil reset Camera → Successfully reset Camera So tccutil works in general, but the LocalNetwork service specifically cannot be reset, on this Public Beta build, either per-app or system-wide. Question for the forum Is there a known change/regression on the Golden Gate Public Beta where the Local Network permission prompt doesn't fire for direct-IP connections that don't go through Bonjour/NWBrowser? (The same code works fine on the Developer Beta.) Has anyone else seen tccutil reset LocalNetwork fail (while other services reset fine) specifically on the macOS 27 Golden Gate Public Beta? Any known workaround short of downgrading — e.g. restructuring the connection to use Bonjour/NWBrowser instead of a direct IP connection, or some way to explicitly trigger the permission prompt? We're also planning to file this via Feedback Assistant with a full sysdiagnose, but wanted to check here first in case this is already a known/tracked issue or someone has a workaround. Thanks in advance.

Hi Team, I'm trying to understand the behavior of the following API: HTTPCookieStorage.shared.setCookies(_:for:mainDocumentURL:) Specifically, does this API persist cookies synchronously, or does it perform the storage asynchronously in the background? Our use case is storing FCAP (frequency capping) cookies so they persist across app sessions. We call setCookies(_:for:mainDocumentURL:) and want to know whether the cookies are guaranteed to be written before the method returns, or if the actual persistence happens asynchronously. I couldn't find documentation describing the persistence semantics of this API, so I'd appreciate any clarification or guidance from Apple or anyone familiar with its implementation. Thanks

Hi Apple Developer Team, We have an iOS app using Network Extension URL Filtering for content filtering. The filtering works, but we need to maintain statistics such as: Number of blocked/allowed URLs Blocked domains/URLs Browser-specific statistics We don't currently see an API from the URL Filter that reliably provides the blocked URL event/details, we already say the latest introduction of reportEndPoint https://developer.apple.com/documentation/networkextension/neurlfiltermanager/reportendpoint?changes=_3,_3, we do not need it for supervised devices and that is mainly designed for supervised devices. We are considering using NEPacketTunnelProvider alongside the URL Filter to collect network-level statistics while keeping the URL Filter responsible for the actual blocking. Our concern is that Could you please clarify: Is it supported to use URL/Content Filter + NEPacketTunnelProvider together for this purpose? Would using Packet Tunnel to collect statistics/network telemetry be considered a misuse of NEPacketTunnelProvider, since it is primarily intended for VPN functionality? Does adding the packet-tunnel-provider Network Extension entitlement require separate Apple approval? Could this architecture create an App Store review/distribution issue? Is there an Apple-supported API for obtaining the URL/domain and block decision directly from the URL/Content Filter, which would be preferable to monitoring packets? Our goal is not to replace the content filter with Packet Tunnel. We want to keep filtering in the appropriate Network Extension and use the appropriate mechanism to maintain browser-specific blocked/allowed statistics. Thank you.

The ExternalAccessory framework gives us showBluetoothAccessoryPickerWithNameFilter which provides a list of accessories to connect to. I'm using that with good results to pair an accessory.I am looking for the ability to let the users of my app unpair from a connected accessory. I hunted through the ExternalAccessory framework and couldn't find anything.Any ideas?These are Bluetooth Classic devices, not BLE.

iPhone 12 pro with iOS 26.0 (23A5276f) App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices. Apple will act as the Publisher, and Android will act as the Subscriber. According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log. We request Apple to provide a solution. apple Log-20250808a.txt

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"]

I’d like to ask whether Apple plans to enable Encrypted Client Hello (ECH, RFC 9849) opportunistically by default across the iOS/iPadOS system networking stack. Apple already exposes ECH support through sec_protocol_options_set_enable_encrypted_client_hello(), but there currently appears to be no system-wide preference, configuration profile, or MDM policy to enable ECH for normal system networking clients such as URLSession, CFNetwork, WebKit/Safari, and other apps relying on Apple’s networking stack. I tested this with a working ECH deployment: A domain publishes a valid DNS HTTPS/SVCB record containing an ech parameter. The corresponding TLS endpoint supports ECH. iOS successfully queries and receives the HTTPS/SVCB record. Safari / normal system networking clients then connect to the domain. Packet capture still shows the real SNI in the plaintext ClientHello, and ECH is not attempted. If the same connection is explicitly configured to enable ECH at the TLS protocol-options level, ECH can be used successfully. It would be useful if iOS/iPadOS could: Opportunistically enable ECH by default whenever TLS 1.3 and a valid ECHConfig are available. Optionally provide a system-wide / MDM policy for enabling ECH. Ideally provide an “ECH required” policy that fails closed rather than falling back to plaintext SNI. This would improve hostname privacy for applications using the system networking stack without requiring every application developer to explicitly opt in. I have submitted this through Feedback Assistant as: FB24334961 — Enable Encrypted Client Hello (ECH, RFC 9849) by default for system TLS connections Has anyone found an existing system-level way to enable ECH, or does anyone know whether Apple plans to make this the default behavior?

Dear Apple: We are currently developing and debugging WiFi NAN (Neighbor Awareness Networking) connectivity for Android and Apple devices. We have encountered a multi-device connection issue. Specifically, we have one Android device (Device A), and two Apple devices (Device B and Device C). Both Apple devices run the same application, which allows them to enter the publish state. Assuming Android Device A has already paired with both Apple devices, when we next want to connect specifically to Apple Device B, and both Apple devices happen to be in the publish state at the same time, how can we distinguish between the two devices during service discovery and connection? Because the apps on the two Apple devices are identical, the service names they publish are also the same.

I have a multi-platform app 1 (visionOS, macOS, tvOS) on the app stores. I am trying to add an iOS version but it got rejected. I have been trying to get another visionOS app 2 accepted but that was also rejected. After app 1 was rejected I retried the other app 1 versions and had some issue downloading Background Assets . After reinstalling the app 1 versions from their App Stores they worked as expected. The other app 2 was working for me via TestFlight but each time I submitted a new version of the app it was rejected with a black screen image, indicative of a downloading issue. I may need to do some coding work on app 2 but the behavior of accepted app 1 versions has me asking if others have seen issues with Background Asset downloads. This seems to be a relatively new technology so maybe stiill a work in progress.

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

We maintain a large file-sync app. After our upload endpoint moved to HTTP/2, we found that when multiple NSURLSessionUploadTasks run concurrently, all tasks send their request headers immediately (multiplexed on a single connection — confirmed identical localPort via URLSessionTaskMetrics), but request bodies are transmitted essentially one task at a time: while one task's body saturates the uplink, the other tasks send zero body bytes for the entire duration (countOfBytesSent == 0). This reproduces with both background sessions (BackgroundUploadTask) and default sessions (LocalUploadTask), on Wi-Fi and cellular. iOS 26.5, Xcode 26.3, tasks created with uploadTask(with:fromFile:), multipart POST. This becomes a hard failure behind a load balancer with slow-POST (RUDY) protection: requests whose first body KB doesn't arrive within 5s are rejected with 408. The starved tasks fail even though the network is healthy. For comparison, OkHttp on Android writes bodies in interleaved 16KB DATA frames under identical conditions, so all streams pass the first-KB check. Metrics excerpt (4 concurrent uploads, one h2 connection): task 1: duration 18.7s, sent 180MB (full line rate) task 2: duration 22.8s, sent 43MB (transmitted only after task 1 finished) task 3: duration 46.0s, sent 247MB (after task 2) task 4: duration 5.2s, sent 0 bytes → 408 from the gateway In one run a starved stream sent exactly 65,536 bytes (the default initial stream window) and then stalled. Questions: Is this sender-side scheduling (no round-robin between streams' DATA frames) the expected CFNetwork behavior? Does URLSessionTask.priority influence HTTP/2 stream weighting for upload bodies? Is there any other way to influence bandwidth sharing between concurrent uploads? Is there any supported way to opt out of HTTP/2 (constrain ALPN to HTTP/1.1) or cap concurrent streams per connection from the client side? We believe there isn't, but would like to confirm. What is the recommended pattern for concurrent large uploads in this situation? Filed as FB24062619 with full sanitized metrics attached. Happy to provide more data.

I have an accessory which uses both Bluetooth and WiFi to communicate with the app. I am trying to migrate to Accessory Setup Kit. However, the API expects both the bluetooth identifiers and WIFI SSID or SSID prefix in the ASDiscoveryDescriptor. The problem is we only have the WIFI SSID after BLE pairing. Our current flow looks like this: Pair via BLE Connect via BLE Send a BLE command to request WIFI settings (SSID and password) (Each device has a different SSID and password) Connect to WI-FI hotspot by calling NEHotspotConfigurationManager applyConfiguration with the retrieved credentials. Is there a way to set the Wi-Fi SSID of an ASAccessory object after the initial setup? To use Accessory Setup Kit we would need something like this: Call Accessory Setup Kit with bluetooth identifiers in the descriptor, finish the setup and get ASAccessory object. Connect via BLE Send a BLE command to request WIFI settings (SSID and password) Set the SSID of the ASAccessory to the retrieved value. Connect to WI-FI hotspot by calling `NEHotspotConfigurationManager joinAccessoryHotspot. Thanks!

Hello Team, We have a System Extension with Provider Type "DNS Proxy". We have embedded the System Extension in GUI target which registered as LaunchAgent. We found NEDNSProxyManager saves the proxy configuration in the caller's preferences. Due to that we see a prompt for Network Extension when switching users. On allowing that we see multiple DNS filter in the System Settings->Network->Filters even though one DNS Filter can enabled which is annoying. Question 1: Is this expected for non MDM users? Are the users expected to authorise Network extension when switching users. Question 2: Is there a way to prevent the multiple DNS filter for both MDM and non MDM users? To prevent multiple filters, we identified a solution to embed the System Extension in our LaunchDaemon target. So the proxy configuration will be save in the root preference. But with this approach we ended up with an error [OSSystemExtensionErrorDomain error 13] during OSSystemExtensionRequest.deactivationRequest. Question 3: Is there a way to avoid OSSystemExtensionErrorDomain 13 when deactivating System extension from our LaunchDaemon process? Question 4: What is the best practice in terms of embedding and deploying DNS Proxy System Extension for managed and non managed environment. Also if user expected to see multiple DNS filter. I suggest to show the filter that saved for that user's preference. Thank you.

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

I am currently using macOS 27 beta 4, but this issue also existed on macOS 26.5 before I updated to macOS 27. I am not sure whether earlier system versions had the same problem, as I had never encountered a similar issue before. I am developing through the local network, including using VSCode Remote SSH to connect to a local server, and using a Swift app to establish a WebSocket connection with the local server. Recently, I have encountered multiple cases where the local server connection suddenly failed. Checking the logs showed messages such as Permission denied or similar errors. AI assistants explained that this usually means the target app does not have Local Network permission enabled in Privacy & Security settings. However, I checked the settings page and confirmed that the target apps already have Local Network permission enabled. Previously, when VSCode Remote SSH failed, I observed the following behavior: after updating VSCode, if the local server was not running, VSCode Remote SSH immediately reported that the target server could not be found. After starting the local server, it immediately reported that there was no route to the host (I do not remember the exact English error message, but it was a common network error). Checking the logs showed Permission denied. I even noticed two VSCode entries in the Local Network permission list that could be enabled or disabled independently. Just now, my Swift app failed in a similar way. I verified that the server was running and listening because websocat could successfully connect to the local server. The app uses Starscream, and client.connect() was executed but the connection could not be established. Checking log stream --predicate 'process == "name"' --level debug showed: 2026-08-08 14:48:38.620396 ... nw_endpoint_handler_path_change [C1 ... waiting parent-flow (unsatisfied (Local network prohibited), interface: bridge100, ipv4)] However, after successfully applying the workaround described below, I saw the backend server print related output, proving that the server received the app's ping frame. At the same time, the Local Network permission page did not show this app as an entry, and no permission prompt appeared asking me to authorize Local Network access. Therefore, I am no longer certain that this issue is strictly related to Local Network permission. All of the above cases involve third-party components: VSCode Remote SSH, UTM providing a server at 192.168.64.3, and Starscream instead of the WebSocket implementation provided by Foundation. I am not an expert in networking, so I cannot completely rule out issues caused by third-party software. However, I found that running the following commands in macOS Recovery Mode: #!/bin/bash cd "/Volumes/Data/Library/Preferences/" rm -f com.apple.networkextension.plist rm -f com.apple.networkextension.uuidcache.plist rm -f com.apple.networkextension.control.plist rm -f com.apple.networkextension.necp.plist and then rebooting can resolve the situation where one specific app suddenly cannot access the local network while other apps continue to work normally. Running tccutil reset All com.bundle.id did not solve the problem. This command was suggested by Claude Sonnet 5. I am not even sure whether Local Network permission is managed by TCC, but I am including this information because the five commands above appear to modify NetworkExtension-related files rather than the TCC database. This issue cannot currently be reproduced reliably. I do not know when it will happen. After it occurs, I have not found a normal-system-environment solution. The only workaround I have found is booting into Recovery Mode and clearing the local network authorization-related files.

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle guarantees provided by the Network framework for NWListener and NWConnection when an iOS application transitions to the background and is subsequently suspended. I was going through this Technical Note TN2277 (specifically the Listening socket section), which describes that if the app has gone into the background and eventually gets suspended, then even though the underlying socket is still active/functional, new connections might be immediately rejected by the kernel. In the scenario where the system suspends the app and later reclaims the resources from underneath the listening socket, the app will no longer be able to listen for incoming connections. On resumption, it might be possible that the app is not even notified that the underlying resource has been reclaimed. Relevant Quotes from the Tech note: Once your app goes into the background, it may be suspended. Once it is suspended, it's unable to properly process incoming connections on the listening socket. However, the socket is still active as far as the kernel is concerned. If a client connects to the socket, the kernel will accept the connection but your app won't communicate over it. Eventually the client will give up, but that might take a while. Thus, it's better to close the listening socket when going into the background, which will cause incoming connections to be immediately rejected by the kernel. If the system suspends your app and then, later on, reclaims the resources from underneath your listening socket, your app will no longer be listening for connections, even after it has been resumed. The app may or may not be notified of this, depending on how it manages the listening socket. It's generally easier to avoid this problem entirely by closing the listening socket when the app is in the background. Does the above hold true for Network Framework UDP sockets, or is the stateUpdateHandler of the corresponding NWListener executed on resumption, indicating that the socket has been reclaimed and the state is either cancelled/failed (non-recoverable) or waiting (recoverable)? If yes, should the app close the NWListener when going into background since it might not be able to determine whether the underlying socket resource has been reclaimed or not on resumption? Additionally, for NWConnection client/accepted-client sockets, does the same semantics apply?

On iOS 26.5.2 (23F84), we are observing repeated transient VPN restarts caused by the system nesessionmanager process exiting while active NEPacketTunnelProvider sessions still exist. Immediately before the restart, the tunnel is healthy: WireGuard handshakes, connectivity checks, key validation, and PQS checks all succeed. At the time of failure: All XPC connections to nesessionmanager are invalidated. NetworkExtension calls our provider’s stopTunnel(with:) with NEProviderStopReason.internalError (raw value 17). The extension log says: Calling stopTunnelWithReason because: None, followed by IPC detached. UserEventAgent reports: nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status. The system launches a new nesessionmanager process and restarts the tunnel through On Demand approximately two seconds later. This occurred 15 times within approximately 44 hours. At least one occurrence coincided with multiple processes being terminated under apparent memory pressure. A sysdiagnose captured approximately one minute after an occurrence, together with the packet tunnel logs and detailed timeline, has been submitted in Feedback Assistant: FB24185635 Is this a known nesessionmanager or jetsam/idle-exit issue on iOS 26.5.2? Is there any supported way for a VPN provider to distinguish this system-level transient restart from an actual provider internal error?

I'm seeing an issue with NEURLFilterManager on iOS 26.5.2 and wanted to check if anyone else has encountered this. Our URL Filter implementation was working correctly on previous iOS 26.x releases. After updating devices to iOS 26.5.2, the filter no longer starts. The status changes to: Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn’t be completed. (NetworkExtension.NEURLFilterManager.Error error 10.)'> What I've verified The same project and implementation worked on earlier iOS versions. The app and extension have the required Network Extension capabilities and entitlements. The extension bundle identifier matches the one configured in NEURLFilterManager. The extension is embedded correctly in the application. I've tried uninstalling/reinstalling the app and rebuilding with the latest Xcode. The issue is reproducible on iOS 26.5.2. The filter never appears to start, and the status immediately changes to stopped with NEURLFilterManager.Error 10. I'm trying to determine: Has anyone else observed this behavior on iOS 26.5.2? Is there any known regression or change in NEURLFilterManager or URL Filter extensions in this release? Does Error 10 indicate a different failure mode on iOS 26.5.2 than on previous releases? If anyone has experienced the same issue or found a workaround, I'd appreciate any guidance. Thanks!