Our NEURLFilter (URL Filter) and Live Caller ID Lookup entitlements are both Approved, but on device the URL filter never activates — the NEURLFilter session loops starting → stopped, so no URLs are filtered. App: bundle app.scamzero (App ID 6768433709) URL Filter Config ID: 224e33c9-b03b-44ce-87cd-2153c86908ce Live Caller ID Lookup Config ID: 0abdc42b-c98b-4753-8af4-9334d42abdb8 Device: iPhone on iOS 26. Test account has the paid plan that enables the feature. The system log shows the failure is fetching the Privacy Pass token issuer directory through Apple's relay (gateway.icloud.com), not our backend: ciphermld : Failed to fetch Token Issuer Directory. URL: https://gateway.icloud.com/pat-issuer-directory?issuer=issuer.scamzero.app Status Code: 404 → NEURLFilterPlugin setStatus:error — NEAgentURLFilterErrorDomain Code=3 → NESMURLFilterSession status changed to stopping with error 3 → prefilterCleanup (removes the prefilter mmap) → session restarts → loop This looks like NEURLFilterManager.Error.serverSetupIncomplete (9). What we have already verified on our side (everything conforms): We run Apple's unmodified reference PIRService (from apple/pir-service-example). Our issuer directory at https://issuer.scamzero.app/.well-known/private-token-issuer-directory returns 200 with valid token-keys (token-type 2) and issuer-request-uri. OHTTP gateway (gateway.scamzero.app/ohttp-configs and /gateway), PIR service (service.scamzero.app), use case app.scamzero.url.filtering, bearer token AAAA, DNS TXT apple-url-filter=app.scamzero, and the validation URL apple.com/url-filter-test = 1 are all configured. Our pre-launch checks pass. The precomputed Bloom prefilter loads on device with the correct bit/hash/seed and ~37k domains. Key observation: our OHTTP gateway logs show zero successful OHTTP requests from Apple's infrastructure since Aug 10, and gateway.icloud.com/pat-issuer-directory?issuer=issuer.scamzero.app returns 404 on device. This suggests our Privacy Pass issuer is not registered/validated in Apple's PAT issuer directory, even though both entitlements are Approved. Question: How can we get our Privacy Pass issuer (issuer.scamzero.app) registered/validated in Apple's token issuer directory for the use cases app.scamzero.url.filtering and Live Caller ID Lookup? The entitlements are approved, but the on-device token issuer directory lookup fails with 404, which prevents the filter from ever activating. Happy to file a Feedback with a sysdiagnose if useful.

We are using an URLSessionDataTask to download some JSON from a server and lately we sometimes receive NSURLErrorCancelled (code -999) for no apparent reason. After enabling CFNetwork Diagnostic Logging I found that in these cases the request finishes with the error mentioned above instead of HTTP/1.1 200 OK even though the response body seems to be transferred in its entirety. What could be causing this? I am pretty certain that it is not us cancelling the task.

Dear Apple：I am developing an app and I would like to use Apple's AccessorySetupKit to complete the binding with an accessory. My accessory supports both Bluetooth and Wi-Fi Aware. I want to use AccessorySetupKit to complete both the Bluetooth pairing and the Wi-Fi Aware pairing with the accessory in one go. For Bluetooth, we also need to use the ANCS service, so the Bluetooth pairing requires a PIN code pop-up. However, we would like to skip this Bluetooth PIN code pairing, or combine it with the Wi-Fi Aware PIN code pairing into a single step. Is this possible under the current AccessorySetupKit framework? Because having the user confirm the PIN code twice does not seem like a great user experience. I would appreciate your help in answering this. Thank you.

When I set IncludeAllNetworks in my VPN profile along with the excludeRoutes for traffic I want to go outside of the tunnel, I see the exclude routes being added to the the route table but when we try and to connect on those hosts something is setting a route to the TUN interface and ignoring the excluded routes in the settings. I'm assuming that some policy before any route table is being looked at is doing this but does that then mean IncludeAllNetworks=true and excludeRoutes are actually incompatible? Is this documented and I just missed it?

Testing NEURLFilterControlProvider on iOS 26.6, I've measured two behaviours around stop(reason:) that I can't reconcile with the documentation, and I'd like to know whether either is intended. Setup: development-signed build, filter configured and running, instrumented stop(reason:) that logs the reason and then emits elapsed-time markers. All timings below are from device log archives collected with "log collect --device". The reason parameter is always .none nesessionmanager records a specific stop reason for itself, then passes .none (0) to the provider. Two different user actions, two different internal reasons, same .none delivered. Disabling via NEURLFilterManager (isEnabled = false, saveToPreferences): 15:20:12.173 nesessionmanager: Setting last stop reason to 31 15:20:12.175 MyProvider: stop() entered, reason=0 (none) 15:20:14.208 MyProvider: stop() completed after 2032ms 15:20:14.209 nesessionmanager: status changed to disconnected, last stop reason Configuration was disabled Disabling the filter from iOS Settings: 15:25:04.167 nesessionmanager: Setting last stop reason to 1 15:25:04.169 MyProvider: stop() entered, reason=0 (none) 15:25:06.198 MyProvider: stop() completed after 2028ms 15:25:06.200 nesessionmanager: status changed to disconnected, last stop reason Stop command received The system clearly knows why the filter stopped, and the values it uses (31, 1) are outside the NEProviderStopReason range, so there appears to be a richer internal enum that isn't mapped through to the provider. Is .none what a URL filter control provider should expect in all cases? If so, is there any supported way for the provider to distinguish a deliberate user disable from system settings, say, an in-app disable, app update or a configuration reload? Is stop(reason:) guaranteed to be called? I do cleanup work in stop(), so I want to know whether it is a reliable lifecycle callback or a best-effort one. I found at least one teardown path where it is skipped entirely. When the configuration is removed as part of the app being deleted, the session is torn down without the provider ever being invoked. The extension is terminated roughly 355 ms before the configuration removal: 15:33:59.361 launchd: service inactive: MyProvider, leaving extension group 15:33:59.363 runningboardd: Executing termination request 15:33:59.431 launchd: remove all extension instances ... total of 0 extension instances were found to remove 15:33:59.716 nesessionmanager: configuration has been removed, stopping 15:33:59.716 nesessionmanager: Setting last stop reason to 32 15:33:59.717 nesessionmanager: plugin NEURLFilterPlugin(...) disposed 15:33:59.717 nesessionmanager: status changed to disconnected, last stop reason Configuration was removed No stop() call appears anywhere in the archive, and the plugin is disposed rather than stopped. The whole teardown takes one millisecond. The ordering looks like the cause: by the time nesessionmanager removes the configuration, the extension process is already gone, so there is nothing left to call stop() on. Thread 713975 describes stopTunnel being called with .providerDisabled in the equivalent situation for a packet tunnel provider, so the behaviour appears to differ by provider type. So my question is about the contract rather than this specific path: should a URL filter control provider treat stop(reason:) as guaranteed, or as best-effort? If it is best-effort, are there other teardown paths where it is skipped, so I can make sure nothing important depends on it running?

Hi everyone, I’m looking for some clarification regarding "Transparent Proxy configurations on macOS". We have a requirement where multiple security/networking solutions may need to use a "Transparent Proxy" on the same macOS device. For example, one solution may be used for web security/SSL inspection while another solution is required for a different security or network traffic use case. My questions are: 1.Does macOS support configuring and running multiple Transparent Proxy providers simultaneously on the same device? 2. If multiple Transparent Proxy configurations are deployed through MDM, how does macOS determine which proxy handles the traffic? 3.Is there any limitation on the number of Transparent Proxy configurations/providers that can be configured? 4.Can multiple Transparent Proxy providers coexist if they handle different traffic, applications, or network interfaces? 5. If multiple providers are configured, is there a supported mechanism to define priority, ordering, or traffic routing between them? 6. Are there any differences or limitations across recent macOS versions, particularly macOS 15 and macOS 26? 7. Is there any Apple documentation or recommended architecture for deploying multiple Transparent Proxy providers on the same Mac? If anyone has implemented or tested a setup with multiple Transparent Proxy providers on macOS, I’d appreciate any insights, documentation, or real-world experience. Thanks! Vijay

Hello, I am evaluating a technical concept for an airline passenger application and would like to clarify what is possible using public iOS APIs. Is there any supported public API, framework or entitlement that allows an iOS application to reliably determine whether: cellular radio/connectivity has been disabled by the user, while Wi-Fi remains enabled and connected? The goal is only to verify this device state. The application would not attempt to enable or disable Airplane Mode or cellular connectivity itself. I have reviewed Core Telephony, but it does not appear to provide an explicit and reliable Airplane Mode state. Would there be a supported way for an airline application to verify this condition, or is this intentionally unavailable to third-party applications on iOS? Thank you for your guidance. Kind regards, Colin Friedrichs

Hello , We are developing an enterprise iOS application for cellular network benchmarking, performance validation, and analytics. We have reviewed the publicly available iOS APIs, including CoreTelephony, and have not identified a public API that provides access to the following cellular RF/network measurements: ARFCN / EARFCN / NRARFCN 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) Could Apple please clarify whether any of the above measurements can be accessed through an officially supported mechanism, including but not limited to: Public iOS frameworks or APIs Special entitlements Managed or supervised-device capabilities Enterprise-specific capabilities Carrier-partner programs or integrations Apple-approved diagnostic or measurement frameworks Other approved mechanisms or programs We are not seeking to use private APIs, reverse-engineering techniques, or unsupported mechanisms. Our goal is to understand whether Apple provides any legitimate and supported way for an enterprise application to obtain these measurements on iOS devices. If access to any subset of these metrics is supported, could you please point us to the relevant documentation, framework, entitlement, carrier program, or enrollment process? Our use case is limited to cellular network benchmarking, performance validation, and network analytics on iOS devices. Thank you for your guidance.

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!