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.

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.

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!

I'm developing a lighting control app for iOS that receives Art-Net (UDP port 6454) and sACN (UDP port 5568) packets from a lighting console and relays commands to BLE wristbands with LEDs. This is used in live event production — the participant locks their phone while in a show and expects lighting control to continue uninterrupted. The problem UDP receive stops reliably ~30 seconds after the screen locks. I understand this is by design - iOS suspends apps in the background. However, I'm trying to understand if any supported path exists for this use case. What I've already tried UIRequiresPersistentWiFi = true - helps with Wi-Fi association but doesn't prevent app suspension Silent AVAudioEngine loop with UIBackgroundModes: audio - keeps the app alive, works in testing, but risks App Store rejection and feels like an abuse of the audio background mode NWListener (Network framework) on the UDP port - same suspension behaviour Socket rebind on applicationWillEnterForeground - recovers after resume but doesn't prevent dropout What I'm asking Is there any supported background mode or entitlement for sustained UDP receive in a professional/enterprise context? (Similar to how VoIP apps get the voip background mode for sustained network activity.) Is the silent audio workaround considered acceptable for App Store distribution in a professional tools context, or will it be rejected? Is NEAppProxyProvider or another Network Extension a viable path, and if so does it require a special entitlement? Test project I have a minimal Xcode project (~130 lines) demonstrating the issue — NWListener on port 6454, packet counter, staleness timer, and silent audio toggle. I can share the test code. STEPS TO REPRODUCE In Xcode (one-time setup): Select the UDPBackgroundTest target → Signing & Capabilities → set your Team Plug in your iPhone → select it as the run destination Build & run — confirm packets appear on screen when you run 'send_test_udp.py' Lock the phone and observe the dropout Test: Open the app and run 'python3 send_test_udp.py 192.168.0.XXX' The app counts up the packages, they match the python output. 1 packet per second. lock screen & and wait 10 seconds unlock phone an see the numbers are 10 packets off

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

Hello. There is a condition that two requests are executed from an iPhone to the application, and the same session must be maintained throughout the execution of these two requests. The application resides within AWS. AWS ALB offers a Sticky Session feature to maintain sessions; to use this feature, Sticky Session Cookies are utilized, and it seems that the iPhone must be able to set the cookie. I would like to know if the iPhone can accept cookies for Sticky Sessions. Has anyone experienced a similar situation before?

I’m building an app on macOS 26.4 with Xcode 26.4. When I build and run my app it started prompting me for network access, which it didn’t do before with Xcode 26. It did that repeatedly, and I had been approving the prompts and the app had been working. Now the app’s network features are not working, and I assume its because its being blocked by macOS, even though I accepted the network requests each time. In System Settings - Privacy and Security - Local Network, the app has many repeated entries, like 20, and all of them are turned on.

We have been testing several domains (including xiaohongshu.com, bilibili.com, douyin.com, and tls13.xargs.org) and have encountered a systemic issue related to Apple's Certificate Transparency (CT) policy enforcement on iOS 18. We would like to seek clarification from the Apple team. Observed Behavior: On iOS 18 devices where the CT log list (assetVersion) is at version ≤1006, Safari presents "This Connection Is Not Private" for the affected domains. NSURLSession returns error -1202 (NSURLErrorServerCertificateUntrusted), and SecTrust rejects the certificate chain entirely. Other domains whose certificates use 2026-series CT log servers connect normally on the same device. Key Affected User Pattern: The vast majority of affected devices are those upgraded directly from iOS 14 or iOS 15 to iOS 18, where the CT log list did not automatically update after the upgrade and remains stuck at version ≤1006. Brand-new devices and devices that have updated their CT list to version 1012 connect normally — confirmed through direct testing. This suggests the issue is not a bug in iOS 18 itself, but rather a failure to refresh the CT log list on older devices after a major OS upgrade, resulting in a low-… (truncated) Root Cause Analysis: The failing certificates embed SCTs from three CT log servers: Cloudflare Nimbus2027, Tiger2027h1, and Elephant2027h1. These servers were added to Apple's trusted CT log list between September and November 2025. Devices whose CT list is still at version ≤1006 do not include these servers, causing all SCTs to be deemed invalid and the certificate to be rejected. Questions: What triggers a CT log list update? Under what conditions does the Trusted Asset (CT log list) update on iOS devices? Is there an update mechanism independent of the system OTA? Why does upgrading from iOS 14/15 to iOS 18 appear to leave the CT list at an older version rather than refreshing it as part of the upgrade? Is Apple aware of this as a known issue? For devices that upgraded to iOS 18 from iOS 14/15 and whose CT list was not refreshed, while CAs are already using newly-trusted log servers — does Apple have an official recommendation or a fix planned? Is there a "safe use window" guidance for CAs? Does Apple communicate to CAs a recommended waiting period after a new CT log server is added to the trust list, before it should be used to issue certificates targeting iOS users? If not, are there plans to publish such guidance? CT list behavior across upgrade paths: Can Apple clarify whether devices upgrading from iOS 14/15 to iOS 18 receive a different CT list assetVersion compared to devices upgrading from iOS 16/17 or performing a clean install? Is there a patch or mechanism to ensure devices on older upgrade paths also receive timely CT list updates? Thank you for your attention. We look forward to a clear response.

Problem description Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments. We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested. Out of the many issues our main app exhibits, the test app showcases some: The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access. The app shows a different Local Network Usage Description than in the project's plist. Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off. We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings. Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior? Related material Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement. Local Network FAQ Technote TN3179 Steps to Reproduce Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested. On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist. The app properly shows packets are received from the console on our LAN. We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed. We then reboot the machine. After reboot, the same list does not show the app anymore. We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received. After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine. We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version. The updated version also asks for Local Network access, this time with proper Usage Description. A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app. We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off. We toggle on one of the app, all of them toggle on. All 3 versions have local network access.

How do I make a basic request with URLSession? See https://stackoverflow.com/questions/30573898 for reference. Also https://developer.apple.com/documentation/ has details.

URLSession question

Hello team, We are using below example https://github.com/apple/pir-service-example as a starting point to setup PIR server for our backend, but I am not really understanding what else we need in this example to configure OHTTP gateway. Any help will be appreciated.

I'm relatively new to socket networking, and am migrating an older project from CocoaAsyncSocket to Swift's native Network. The project utilises GCDAsyncUdpSocket.enableBroadcast(_ flag: Bool), but I don't know how to replicate this in Network. How do I enable UDP Broadcast on NWConnection?

Hello, I am currently developing a headless macOS daemon (HarmonBridge) that requires extremely low-latency, high-bandwidth UDP video streaming between a Mac and a Linux host over a dedicated 2.5GbE/5GbE local network link. We are utilizing widely available Realtek RTL8156 / RTL8156B based USB 2.5G network adapters. Under macOS, these adapters default to the generic com.apple.DriverKit.AppleUserECM driver. The hardware itself natively supports Jumbo Frames (MTU 9000), but the DriverKit implementation artificially restricts the MTU cap to 1500 bytes. Because we are forced through MTU 1500, we are incurring significant performance penalties: Excessive IP fragmentation for our large UDP video payloads. Unnecessary CPU overhead due to increased hardware interrupts and header processing at 2.5Gbps speeds. For a latency-critical application like ours, reducing CPU interrupts and utilizing true hardware-level Jumbo Frames is essential. My Questions: Is there an undocumented boot-arg or network sysctl parameter that permits overriding the AppleUserECM 1500 MTU hard-limit for 2.5G USB adapters on Apple Silicon? Are there any roadmap plans from the DriverKit/Networking team to re-enable standard Jumbo Frame negotiation for RTL8156 hardware using the generic ECM driver? If the answer to both is no, does Apple grant NetworkingDriverKit Entitlements to independent developers specifically for the purpose of writing custom hardware overrides to patch missing MTU features in the default ECM stack? Because AppleUserECM effectively acts as a gatekeeper to the underlying MAC/PHY capabilities of these modern USB NICs, any guidance on achieving wire-native MTU 9000 under the current DriverKit paradigm would be hugely appreciated. Thank you!

I'm implementing a NEDNSProxyProvider on macOS 15.x and macOS 26.x. The flow works correctly up to the last step — returning the DNS response to the client via writeDatagrams. Environment: macOS 15.x, 26.x Xcode 26.x NEDNSProxyProvider with NEAppProxyUDPFlow What I'm doing: override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool { guard let udpFlow = flow as? NEAppProxyUDPFlow else { return false } udpFlow.readDatagrams { datagrams, endpoints, error in // 1. Read DNS request from client // 2. Forward to upstream DNS server via TCP // 3. Receive response from upstream // 4. Try to return response to client: udpFlow.writeDatagrams([responseData], sentBy: [endpoints.first!]) { error in // Always fails: "The datagram was too large" // responseData is 50-200 bytes — well within UDP limits } } return true } Investigation: I added logging to check the type of endpoints.first : // On macOS 15.0 and 26.3.1: // type(of: endpoints.first) → NWAddressEndpoint // Not NWHostEndpoint as expected On both macOS 15.4 and 26.3.1, readDatagrams returns [NWEndpoint] where each endpoint appears to be NWAddressEndpoint — a type that is not publicly documented. When I try to create NWHostEndpoint manually from hostname and port, and pass it to writeDatagrams, the error "The datagram was too large" still occurs in some cases. Questions: What is the correct endpoint type to pass to writeDatagrams on macOS 15.x, 26.x? Should we pass the exact same NWEndpoint objects returned by readDatagrams, or create new ones? NWEndpoint, NWHostEndpoint, and writeDatagrams are all deprecated in macOS 15. Is there a replacement API for NEAppProxyUDPFlow that works with nw_endpoint_t from the Network framework? Is the error "The datagram was too large" actually about the endpoint type rather than the data size? Any guidance would be appreciated. :-))

I have the following code that is attempting to set up Hotspot 2.0 using an EAP-TLS configuration. I am importing a pk12 file and using those certificates. I have tried all manner of permutations for the configuration, and have narrowed down all the errors I was getting and now I am just getting a generic: Error: invalid EAP settings. I have tried adding the identity separately and either get an entitlements issue which I can't figure out why since I have added the required network extension sharing groups, or a duplicate item error, meaning it was already correctly added. The certificate and configuration are correctly working through an Android app already. static let accessGroup: String? = { guard let prefix = Bundle.main.object(forInfoDictionaryKey: "AppIdentifierPrefix") as? String else { print("Could not load group") return nil } return "\(prefix)com.apple.networkextensionsharing" }() static func setupHotspot(data: CertificateData) { let h20 = NEHotspotHS20Settings(domainName: data.realm, roamingEnabled: false) h20.naiRealmNames = [data.realm] var result: CFArray? let options: [CFString: Any] = [ kSecImportExportPassphrase: "**********", kSecAttrLabel: "ident:\(data.user)", kSecAttrAccessGroup: accessGroup!, kSecReturnPersistentRef: true ] let status = SecPKCS12Import(data.p12 as CFData, options as CFDictionary, &result) guard status == errSecSuccess, let importResult = result as? [[String: Any]], let resultDict = importResult.first else { print("P12 Import failed: \(status)") return } let identity = resultDict[kSecImportItemIdentity as String] as! SecIdentity let eap = NEHotspotEAPSettings() eap.supportedEAPTypes = [NEHotspotEAPSettings.EAPType.EAPTLS.rawValue as NSNumber] eap.isTLSClientCertificateRequired = true eap.trustedServerNames = [ data.realm ] eap.outerIdentity = "anonymous" guard eap.setIdentity( identity ) else { print("setIdentity failed") return } let configuration = NEHotspotConfiguration(hs20Settings: h20, eapSettings: eap) NEHotspotConfigurationManager.shared.apply(configuration) { error in if let error = error { print("Error: \(error.localizedDescription)") } else { print("Success") } } }

Development environment: Xcode 26.4, macOS 26.3.1 Run-time configuration: iOS 18.7.6 and higher We have an application running on supervised devices, with an MDM profile typically deployed via jamf. The profile enables a Content Filter, with the two flags "Socket Filter" and "Browser Filter" set to true. On the device side, we implement the content filter as a network extension via: a class FilterDataProvider extending NEFilterDataProvider, a class FilterControlProvider extending NEFilerControlProvider. For the record, the FilterDataProvider overrides the handle*() methods to allow all traffic; the handleNewFlow() simply reports the new connection to FilterControlProvider for analysis. Problem: some customers reported that after a reboot of their device, they would not get access to the internet for up to 60s/90s. We have not been able to reproduce the problem on our own devices. What we see is that, even with our app uninstalled, without any Content Filter, it takes roughly 20s to 25s for a device to have internet access, so we can probably consider this 20s delay as a baseline. But would you be aware of a reason that would explain the delay observed by these customers? More details: We have conducted some tests on our devices, with extended logging. In particular: we have added an internet probe in the app that is triggered when the app starts up: it will try to connect to apple.com every 2s and report success or failure, we also have a network monitor (nw_path_monitor_set_update_handler) that reacts to network stack status updates and logs the said status. A typical boot up sequence shows the following: the boot time is 7:59:05, the app starts up at 7:59:30 (manually launched when the device is ready), the probe fails and keeps failing, the content filter is initialized/started up 7:59:53 and is ready at 7:59:55, the network monitor shows that the network stack is connected (status = nw_path_status_satisfied) right after that, and the probe succeeds in connecting 2s later. In other words, internet is available about 50s after boot time, 25s after app startup (i.e. after the device is actually ready). For some customers, this 25s delay can go up to 60/90s.