https://developer.apple.com/documentation/corewlan/cweventtype/linkqualitydidchange As per the documentation core WLAN will send notification when there is a change in RSSI. I did not receive any notification when there is a change in RSSI.

Hello, I have an app that is using iOS 26 Network Framework APIs. It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity. All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network. If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to. By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare. I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work. Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware? Regards, Captadoh

While going through the documentation for NWConnection, there seems to be state known as .waiting which means that the connection is waiting for a path change. For TCP, the state is understandable and can occur under some scenarios. But for the case of UDP, I have following queries: Why do we need .waiting state for the case of UDP? Even if we do need .waiting state for UDP, when all does this state occurs?

Here’s the formatted summary in English for your issue submission: Issue Summary We are activating a Network Extension system extension (filter-data) from a signed and notarized macOS app. Activation consistently fails with the following error: Error Message: OSSystemExtensionErrorDomain code=4 Extension not found in App bundle. Unable to find any matched extension with identifier: com.seaskylight.yksmacos.ExamNetFilter.data At the same time, sysextd logs show: no policy, cannot allow apps outside /Applications However, our host app and executable paths are already under /Applications, and the extension bundle physically exists in the expected app bundle location. Environment Information macOS: Darwin 25.4.0 Host App: /Applications/xxx.app Host Bundle ID: com.seaskylight.yksmacos System Extension Bundle ID: com.seaskylight.yksmacos.ExamNetFilter.data Team ID: BVU65MZFLK Device Management: Enrolled via DEP: No MDM Enrollment: No Reproduction Steps Install the host app to /Applications. Launch the host app via Finder or using the command: open -a "/Applications/xxx.app" Trigger OSSystemExtensionRequest activationRequestForExtension for: com.seaskylight.yksmacos.ExamNetFilter.data. Observe failure callback (code=4). Collect logs: log show --last 2m --style compact --info --debug --predicate 'process == "sysextd"' Check extension status using: systemextensionsctl list (shows 0 extension(s)) Observed Results sysextd client activation request for com.seaskylight.yksmacos.ExamNetFilter.data attempts to realize extension with identifier com.seaskylight.yksmacos.ExamNetFilter.data. Log indicates: no policy, cannot allow apps outside /Applications App-side Diagnostics (captured at failure) PID: 3249 Bundle Path: /Applications/xxx.app Real Path: /Applications/xxx.app Exec Path: /Applications/xxx.app/Contents/MacOS/xxx Real Exec Path: /Applications/xxx.app/Contents/MacOS/xxx Ext Path: /Applications/xxx.app/Contents/Library/SystemExtensions/ExamNetFilterData.systemextension Ext Exists: true Running From Helper: false Error Callback: NSError{domain=OSSystemExtensionErrorDomain code=4 desc=Extension not found in App bundle...} Additional Validation We reproduced the same failure using a minimal native host app (SysExtProbe) in /Applications that only submits the activation request for the same extension identifier. It also fails with OSSystemExtensionErrorDomain code=4, indicating this is not specific to Electron app logic. Signing / Packaging Notes Host app and system extension are signed with the same Team ID (BVU65MZFLK). System extension bundle exists under: /Applications/xxx.app/Contents/Library/SystemExtensions/ExamNetFilterData.systemextension Extension Info.plist contains bundle id: com.seaskylight.yksmacos.ExamNetFilter.data Host app includes NSSystemExtensionUsageDescription. Questions for DTS In non-MDM personal-device scenarios, what exact conditions trigger sysextd to emit: no policy, cannot allow apps outside /Applications even when both bundlePath and realpath are in /Applications? Can code=4 (“Extension not found in App bundle”) be returned for policy/state reasons even when the extension bundle is present and the identifier matches? Are there known sysextd policy/cache states that cause this behavior, and what is the recommended recovery procedure? Feel free to copy and paste this summary for your submission. If you need any further modifications or assistance, let me know!

Hello team, I am trying to find out a way to block urls in the chrome browser if it is found in local blocked list cache. I found URL Filter Network very much suitable for my requirement. But I see at multiple places that this solution is only for Enterprise level or MDM or supervised device. So can I run this for normal user ? as my targeting audience would be bank users. One more thing how can I test this in development environment if we need supervised devices and do we need special entitlement ? When trying to run sample project in the simulator then getting below error

Hello, I am currently developing a PIR server using the pir-server-example repository. We are anticipating a total of 10 million URLs for our dataset. In this context, what would be the optimal shard size (number of records per shard) to balance computational latency and communication overhead? Any advice or best practices for handling a dataset of this scale would be greatly appreciated. Thank you.

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?

Hi I tried to follow this guide https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url I downloaded the sample app and put our pir service server address in the app. The service is already running and the app is connected to the pir service but the url is still not blocked. We tried to block example.com. Is there anything that we need to do in iOS code? This is the sample when there's dataset This is the sample when there's no dataset

Description Enterprise users are experiencing VPN resource access failures after upgrading to macOS Tahoe. Investigation indicates that configd (specifically IPMonitor) is incorrectly re-ranking network interfaces after a connectivity failure with probe server. This results in DNS queries routing through the physical network adapter (en0) instead of the VPN virtual adapter, even while the tunnel is active. This behaviour is not seen in previous macOS versions. Steps to Reproduce: Connect to an enterprise VPN (e.g., Ivanti Secure Access). Trigger a transient network condition where the Apple probe server is unreachable. For example make the DNS server down for 30 sec. Observe the system routing DNS queries for internal resources to the physical adapter. Expected Results The: VPN virtual interface should maintain its primary rank for enterprise DNS queries regardless of the physical adapter's probe status. Actual Results: IPMonitor detects an UplinkIssue, deprioritizes the VPN interface, and elevates the physical adapter to a higher priority rank. Technical Root Cause & Logs: The system logs show IPMonitor identifying an issue and modifying the interface priority at 16:03:54: IPMonitor Detection: The process identifies an inability to reach the Apple probe server and marks en0 with an advisory: Log snippet 2026-01-06 16:03:53.956399+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] configd[594] SetInterfaceAdvisory(en0) = UplinkIssue (2) reason='unable to reach probe server' Interface Re-ranking: Immediately following, IPMonitor recalculates the rank, placing the physical service ID at a higher priority (lower numerical rank) than the VPN service ID (net.pulsesecure...): Log snippet 2026-01-06 16:03:53.967935+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 0. en0 serviceID=50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 addr=192.168.0.128 rank=0x200000d 2026-01-06 16:03:53.967947+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 1. en0 serviceID=net.pulsesecure.pulse.nc.main addr=192.168.0.128 rank=0x2ffffff 3.Physical adapter Is selected as Primary Interface: 2026-01-06 16:03:53.968145+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary IPv4 configd[594]: 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary DNS Packet Trace Evidence Wireshark confirms that DNS queries for enterprise-specific DNS servers are being originated from the physical IP (192.168.0.128) instead of the virtual adapter: Time: 16:03:54.084 Source: 192.168.0.128 (Physical Adapter) Destination: 172.29.155.115 (Internal VPN DNS Server) Result: Connectivity Failure (Queries sent outside the tunnel)

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.

We are building a VPN using NEPacketTunnelProvider where the intent is to route HTTP/S traffic through a local proxy server, while non-HTTP/S traffic flows directly to the network without being tunnelled at the IP layer. The configuration claims no included IP routes — it relies entirely on NEProxySettings to intercept HTTP/S traffic via the URL loading layer. private func configureIPSettings(_ settings: NEPacketTunnelNetworkSettings) { settings.ipv4Settings = NEIPv4Settings( addresses: ["192.168.1.1"], subnetMasks: ["255.255.255.255"] ) // No includedRoutes set — no IP traffic enters the tunnel } private func configureProxySettings(_ settings: NEPacketTunnelNetworkSettings) { let proxySettings = NEProxySettings() proxySettings.httpEnabled = true proxySettings.httpServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.httpsEnabled = true proxySettings.httpsServer = NEProxyServer(address: "127.0.0.1", port: 9000) proxySettings.matchDomains = [""] settings.proxySettings = proxySettings } When matchDomains is nil or not set, HTTP/S traffic does not reach the local proxy in this configuration. Setting matchDomains = [""] makes it work correctly. The matchDomains documentation states: "If the destination host name of a HTTP connection shares a suffix with one of these strings then the proxy settings will be used." An empty string is a suffix of every string, so [""] matching all hostnames follows from that definition. But this isn't explicitly documented. Questions: Is matchDomains = [""] a supported and stable way to apply proxy settings to all HTTP/S traffic when no IP routes are claimed, or is this an unintended side-effect? Why does matchDomains = nil not apply the proxy globally in this configuration? The documentation doesn't describe its behaviour relative to IP routing. NEDNSSettings.matchDomains explicitly documents an empty string as matching all domains — is the same semantics intended for NEProxySettings.matchDomains?

I've been able to run this sample project with the PIRServer. But the urls are still not blocked. https://developer.apple.com/documentation/networkextension/filtering-traffic-by-url https://github.com/apple/pir-service-example I got this on the log Received filter status change: <FilterStatus: 'running'>

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

Hi, I see an interaction issue between a DNS Proxy system extension and MDM on macOS: after some time the device stops processing MDM commands until reboot, while DNS filtering continues to work. Environment: macOS: 15.x / 26.x (reproduced on multiple minor versions) App: /Applications/MyMacProxy.app System extension: NEDNSProxyProvider as system extension Bundle id: com.company.agent.MyMacProxy.dnsProxy Deployment: MDM (SimpleMDM) DNS proxy config via com.apple.dnsProxy.managed Devices: supervised Macs Steps to reproduce: Enrol Mac into MDM. Install MyMacProxy app + DNS proxy system extension via pkg and apply com.apple.dnsProxy.managed profile. DNS proxy starts, DNS is filtered correctly, user network works normally. After some hours, try to manage the device from MDM: push a new configuration profile, remove an existing profile, or install / remove an app. 5.MDM server shows commands as pending / not completed. On the Mac, DNS is still filtered via our DNS proxy, and general network access (Safari etc.) continues to work. After reboot, pending MDM commands are processed and we can remove the app, profile and system extension normally. This is reproducible on our test machines. What I see on the Mac in the “stuck” state apsd is running: sudo launchctl print system/com.apple.apsd # job state = running com.apple.mdmclient.daemon exists as a job but is not running: sudo launchctl print system/com.apple.mdmclient.daemon Abbreviated output: system/com.apple.mdmclient.daemon = { ... state = not running job state = exited runs = 5 last exit code = 0 ... } So the MDM client daemon has exited cleanly (exit code 0) and is currently not running; its APS endpoints are configured. Our DNS proxy system extension is still processing flows: we see continuous logging from our NEDNSProxyProvider, and DNS filtering is clearly active (requests go through our upstream). systemextensionsctl list still shows our DNS proxy system extension as active. From the user’s perspective, everything works (with filtered DNS). From the MDM server’s perspective, commands stay pending until the next reboot. After reboot, MDM behaviour is normal again. Uninstall / cleanup (current approach, simplified) We currently use an MDM‑delivered shell script that: disables our DNS proxy configuration for the console user by editing ~/Library/Preferences/com.apple.networkextension.plist and setting Enabled = false for our DNSProxyConfigurations entries; flushes DNS cache and restarts mDNSResponder; unloads our LaunchDaemon / LaunchAgent for the host app; kills the system extension process using pgrep -f "com.company.agent.MyMacProxy.dnsProxy" | xargs kill -9; removes the extension binary from /Library/SystemExtensions/.../com.company.agent.MyMacProxy.dnsProxy.systemextension; removes /Applications/MyMacProxy.app and related support files. We currently do not call systemextensionsctl uninstall <TEAMID> com.company.agent.MyMacProxy.dnsProxy from MDM, mainly because of SIP and because we understand that fully silent system extension uninstall is constrained. The MDM responsiveness issue, however, can appear even if we don’t run this aggressive uninstall script and just let the extension run for some hours. Questions Is it expected that a DNS Proxy system extension (managed via com.apple.dnsProxy.managed) can leave a device in a state where: apsd is running, com.apple.mdmclient.daemon is not running (last exit code 0), DNS proxy continues to filter traffic, but MDM commands remain pending until reboot? Are there known best practices or pitfalls when combining: DNS Proxy system extensions (NEDNSProxyProvider), MDM‑distributed com.apple.dnsProxy.managed profiles, and MDM app / profile management on recent macOS versions? For uninstall in an MDM environment, what pattern do you recommend? For example, is it better to: disable / remove the DNS proxy profile, stop the NE configuration via NEDNSProxyManager from the app, avoid killing the system extension or removing files from /Library/SystemExtensions immediately, and instead require a reboot for full removal? I can provide a sysdiagnose and unified logs (including nesessionmanager, mdmclient and our logs) from an affected machine if that would be helpful.

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.

Hi, I’m looking for clarification on TN3134: Network Extension provider deployment, specifically iOS deployment requirements for: packet tunnel provider DNS proxy provider From the documentation: Packet Tunnel Provider App extension (min iOS 9.0): per-app mode requires a managed device DNS Proxy Provider App extension (min iOS 11.0): supervised devices only App extension (min iOS 11.0): per-app mode requires managed devices Issue I implemented a DNS proxy using NEDNSProxyManager. Works as expected in debug builds on a local device Fails to configure when distributed via TestFlight Console Output (TestFlight build) error 10:05:39.872258-0500 nehelper The production version of *** is not allowed to create DNS proxy configurations. Use MDM to create DNS Proxy configurations for the production version of ***. Question Is it possible to distribute a DNS proxy provider for use on non-MDM / non-supervised devices? If not: Is the limitation strictly enforced at distribution/runtime? Is a packet tunnel provider the only viable alternative for App Store distribution? There is a lot of different VPN apps on the App Store that appear to work out of the box without MDM or supervision, which suggests they are using a different deployment model. Thank you for any clarification or guidance!

I'm building a macOS network monitor using NEFilterDataProvider as a system extension, distributed with Developer ID signing. On macOS 26.3 (Tahoe), sysextd consistently rejects the activation request with "no policy, cannot allow apps outside /Applications" — despite the app being in /Applications and passing every verification check. I'm aware of the known Xcode NE signing bug (r. 108838909) and have followed the manual signing process from Exporting a Developer ID Network Extension. I've also tried both xcodebuild build and xcodebuild archive workflows — identical failure. Environment macOS 26.3 (25D125), SIP enabled Xcode 26.3 (17C529) Hardware Apple M2 Pro Certificate Developer ID Application (issued Jan 30, 2026 — 27 days old) MDM/Profiles None installed Signing & Verification (all pass) $ spctl -a -vv /Applications/Chakshu.app /Applications/Chakshu.app: accepted source=Notarized Developer ID origin=Developer ID Application: ROBIN SHARMA (R65679C4F3) $ codesign --verify --deep --strict -vv /Applications/Chakshu.app /Applications/Chakshu.app: valid on disk /Applications/Chakshu.app: satisfies its Designated Requirement $ xcrun stapler validate /Applications/Chakshu.app The validate action worked! App signing: Authority=Developer ID Application: ROBIN SHARMA (R65679C4F3) Authority=Developer ID Certification Authority Authority=Apple Root CA TeamIdentifier=R65679C4F3 Runtime Version=26.2.0 Notarization Ticket=stapled App entitlements: com.apple.application-identifier = R65679C4F3.dev.indrasvat.chakshu com.apple.developer.team-identifier = R65679C4F3 com.apple.developer.system-extension.install = true com.apple.developer.networking.networkextension = [content-filter-provider-systemextension] keychain-access-groups = [R65679C4F3.*] Extension signing: Same Developer ID authority, same team, same timestamp. Extension entitlements match (minus system-extension.install). Developer ID provisioning profiles are embedded in both app and extension. What sysextd logs Captured Feb 26, 2026 from log stream --predicate 'process == "sysextd"': sysextd [com.apple.sx:XPC] client activation request for dev.indrasvat.chakshu.filter sysextd attempting to realize extension with identifier dev.indrasvat.chakshu.filter sysextd (Security) SecKeyVerifySignature ← pass (×2) sysextd (Security) SecTrustEvaluateIfNecessary ← pass (×2) sysextd [com.apple.xpc:connection] activating connection: name=com.apple.CodeSigningHelper sysextd [com.apple.xpc:connection] invalidated after the last release sysextd no policy, cannot allow apps outside /Applications sysextd [com.apple.sx:XPC] client connection invalidated Signature and trust evaluation pass. CodeSigningHelper completes. Then the policy check fails. The app receives OSSystemExtensionError code 4 (extensionNotFound). What I've tried and ruled out Build process: Approach Result xcodebuild build -configuration Release + manual re-sign Same failure xcodebuild archive + export from archive + manual re-sign (per thread/737894) Same failure Minimal hand-crafted Xcode project (no xcodegen, trivial code) Same failure Both workflows follow Quinn's process exactly: build with Apple Development → copy app → embed Developer ID provisioning profiles → re-sign inside-out (extension first, then app) with -systemextension suffix entitlements → notarize → staple → install to /Applications. System-level checks: Rebooting — no change Killing sysextd — no change Removing com.apple.quarantine xattr — no change chown root:wheel on app bundle — no change lsregister -r (reset Launch Services) — no change Waiting 27 days for certificate propagation — no change Reinstalling via Finder drag-to-Applications — no change No MDM or configuration profiles installed /Library/SystemExtensions/db.plist shows extensionPolicies: [] (empty) Key observation Pre-existing network extensions activated before macOS 26 work fine on this machine. For example, Tailscale's NEPacketTunnelProvider shows state: activated_enabled in the system extensions database — it was activated on a prior macOS version and is still running. Only new system extension activations fail. I've seen similar Tahoe-specific reports from LuLu (same NEFilterDataProvider type, Developer ID distribution): LuLu #825 LuLu #831 Questions Is this a known regression in macOS 26's sysextd policy evaluation for new Developer ID system extension activations? sysextd's policy check fails after all signature and trust evaluation succeeds. Is there a separate trust/policy path that sysextd consults beyond what spctl, codesign, and CodeSigningHelper verify? Is there anything else I should be checking? I have a sysdiagnose captured immediately after the failure, a minimal reproducer project, and full raw sysextd logs available on request.

Summary I'm implementing NEURLFilter with the com.apple.developer.networking.networkextension.url-filter-provider entitlement for a system-wide URL filtering feature. The feature works perfectly in development-signed builds (connecting successfully to my PIR server over extended testing) but every production-signed build fails before any network call is made. NEURLFilterManager reports .serverSetupIncomplete (code 9). After installing the NetworkExtension debug profile, the unredacted com.apple.CipherML logs reveal the cause: no privacy proxy is provisioned for this bundle identifier, and the connection is configured proxy fail closed. Environment iOS 26 Entitlement: com.apple.developer.networking.networkextension.url-filter-provider Extension point: com.apple.networkextension.url-filter-control PIR server configured via NEURLFilterManager.setConfiguration(...) Privacy Pass issuer configured Dev-signed builds: working correctly, connecting to the PIR server Production-signed builds (both TestFlight and distribution): failing identically The Error Chain Surfaced to the app via NEURLFilterManager.lastDisconnectError: NEURLFilterManager.Error.serverSetupIncomplete (code 9) ← NEAgentURLFilterErrorDomain Code 3 ← com.apple.CipherML Code 1100 "Unable to query status" ← com.apple.CipherML Code 1800 (error details were logged and redacted) After installing the VPN (NetworkExtension) debug profile, the unredacted com.apple.CipherML subsystem shows: 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://<my-pir-server>/config, NSUnderlyingError = { Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" }, _NSURLErrorPrivacyProxyFailureKey = true, NSLocalizedDescription = "The Internet connection appears to be offline." } The critical diagnostic line in the com.apple.network subsystem is: nw_endpoint_proxy_handler_should_use_proxy Proxies not present, but required to fail closed And the connection setup shows the proxy fail closed flag is mandatory for the connection: [C... ... Hostname#...:443 quic, bundle id: <my-bundle-id>, attribution: developer, using ephemeral configuration, context: NWURLSession (sensitive), proxy fail closed] start The network path itself is healthy (Wi-Fi good, DNS resolves correctly), but the connection is explicitly configured to fail closed if no proxy is present, and no proxy is provisioned for this bundle identifier. The entire failure happens in approximately 18 ms, far too fast for any network round-trip, confirming no traffic ever leaves the device. What I've Verified The entitlement is present in the distribution build The NEURLFilterControlProvider extension loads and returns a valid Bloom filter prefilter (with a tag that round-trips correctly between extension and framework) NEURLFilterManager.setConfiguration(pirServerURL:pirPrivacyPassIssuerURL:pirAuthenticationToken:controlProviderBundleIdentifier:) accepts all four parameters without error Development-signed builds of the same bundle identifier connect successfully to the same PIR server On production-signed builds, zero requests reach the PIR server — failure is purely client-side, before any network activity The Question How does the OHTTP privacy proxy get provisioned for a bundle identifier so that production builds can successfully use NEURLFilter? Specifically: Is there a Capability Request form I need to submit for url-filter-provider? I cannot find one in the Capability Requests section of my developer portal. Should I be running my own OHTTP gateway (for example using swift-nio-oblivious-http), and if so, does Apple then need to provision routing from their OHTTP relay to my gateway URL? Is the OHTTP relay path meant to be automatic once the entitlement is active, and if so, is there a specific activation step I'm missing? Is there any way to verify the current provisioning state for a specific bundle identifier from the developer portal? I can provide the full sysdiagnose and unredacted bundle/server details privately to an Apple engineer if that would help diagnose. I'd prefer to keep them out of a public post. Thanks!

We observed intermittent failures when iOS devices repeatedly attempt to connect to an AP via NEHotspotConfiguration. When sniffing the packets, most failures occur before the WPA 4‑way handshake, with a smaller number happening during the handshake itself. SSID and Password were verified to be correct. Root Causes Association fails before handshake (primary issue) iOS often fails at the association phase (Apple80211AssociateAsync errors such as -3905 / -3940). These attempts never reach the WPA 4‑way handshake. iOS auto‑join suppression amplifies the problem After a single association failure, iOS marks the network as failed and blocks retry attempts. Subsequent attempts are rejected by policy (Already failed to auto-join known network profile) without new radio activity. This makes one real failure appear as many repeated failures. 4‑Way handshake failures (secondary) In some cases, association succeeds but the connection drops during WPA setup (Join Failure(6)). The error (if received, not always) is Internal Error - 8. Could we inquire on what might be the best steps to resolve this issue?

Hello! I have an accessory, which is paired already with an iPhone, and am attempting to upgrade its SSID permission to Wi-Fi Aware. In ideal conditions, it works perfectly. However, if I dismiss the picker at the time of pin-code entry, I am unable to re-initialize an upgrade authorization picker. Even though the authorization is not completed a WAPairedDeviceID is assigned to the object of 18446744073709551615. Any subsequent attempts to start the picker up again spits out when treated as a failure serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "No new updates detected from existing accessory descriptor." Attempting with a mutated descriptor serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "Accessory cannot be upgraded with given descriptor." If I try using failAuthorization i get a 550 "Invalid State" error and furthermore if I try finishAuthorization to attempt to clear the descriptor/paired device ID it fails to clear it. If I could be pointed to the intended behavior on how to handle this, or this can be acknowledged as a bug, that would be incredibly appreciated. Thank you!