We have a macOS system extension with NETransparentProxyProvider which is able to intercept traffic and handle it. We also wanted to setup few search domains from our network extension. However, unlike PacketTunnelProvider, NEDNSSettings are completely ignored with NETransparentProxyProvider. So whats the best way to setup few DNS search domains when using NETransparentProxyProvider.

Hello there, Starting from iOS 18.4, support was included for QWAC Validation and QCStatements. Using the official QWAC Validator at: https://eidas.ec.europa.eu/efda/qwac-validation-tool I was able to check that the domain "eidas.ec.europa.eu" has a valid QWAC certificate. However, when trying to obtain the same result using the new API, I do not obtain the same result. Here is my sample playground code: import Foundation import Security import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true @MainActor class CertificateFetcher: NSObject, URLSessionDelegate { private let url: URL init(url: URL) { self.url = url super.init() } func start() { let session = URLSession(configuration: .ephemeral, delegate: self, delegateQueue: nil) let task = session.dataTask(with: url) { data, response, error in if let error = error { print("Error during request: \(error)") } else { print("Request completed.") } } task.resume() } nonisolated func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard let trust = challenge.protectionSpace.serverTrust else { completionHandler(.cancelAuthenticationChallenge, nil) return } if let certificates = SecTrustCopyCertificateChain(trust) as? [SecCertificate] { self.checkQWAC(certificates: certificates) } let credential = URLCredential(trust: trust) completionHandler(.useCredential, credential) } nonisolated func checkQWAC(certificates: [SecCertificate]) { let policy = SecPolicyCreateSSL(true, nil) var trust: SecTrust? guard SecTrustCreateWithCertificates(certificates as CFArray, policy, &trust) == noErr, let trust else { print("Unable to create SecTrust") return } var error: CFError? guard SecTrustEvaluateWithError(trust, &error) else { print("Trust evaluation failed") return } guard let result = SecTrustCopyResult(trust) as? [String : Any] else { print("No result dictionary") return } let qwacStatus = result[kSecTrustQWACValidation as String] let qcStatements = result[kSecTrustQCStatements as String] print("QWAC Status: \(String(describing: qwacStatus))") print("QC Statements: \(String(describing: qcStatements))") } } let url = URL(string: "https://eidas.ec.europa.eu/")! let fetcher = CertificateFetcher(url: url) fetcher.start() Which prints: QWAC Status: nil QC Statements: nil Request completed. Am I making a mistake while using the Security framework? I would greatly appreciate any help or guidance you can provide.

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.

Hello, We are facing what we believe is a compatibility issue with two networking APIs. If the Network extension VPN configuration has includeAllNetworks flag enabled and the NEHotspotHelper is registered. The user has internet connection but it is blocked, and there user will get internet back only after restarting the device. VPN Configuration is as below while connecting to VPN, { localizedDescription = WLVPN WireGuard Configuration enabled = YES protocolConfiguration = { serverAddress = <18-char-str> passwordReference = {length = 20, bytes = 0x67656e70ed0d05c06b1b4896bf4fef2031e1a92d} disconnectOnSleep = NO includeAllNetworks = YES excludeLocalNetworks = YES excludeCellularServices = YES excludeAPNs = YES excludeDeviceCommunication = YES enforceRoutes = NO providerBundleIdentifier = com.wlvpn.ios.consumervpn.network-extension } onDemandEnabled = NO onDemandRules = () } After running the code shown below. Regardless if the VPN is connected or not, the user needs to restart his device to regain internet access. private let neHelperQueue = DispatchQueue(label: "com.wlvpn.ios.consumervpn.hotspot", attributes: DispatchQueue.Attributes.concurrent) let options: [String: NSObject] = [kNEHotspotHelperOptionDisplayName : "" as NSObject] let status = NEHotspotHelper.register(options: nil, queue: neHelperQueue) { cmd in NSLog("Received command: \(cmd.commandType.rawValue)") } We need to use the includeAllNetworks flag to prevent the novel "Tunnel vision" vulnerability. Can we please have some help getting confirmation if both functionalities are compatible or if there's a way to enable them at the same time?

We are assisting a client with their app integration. The client believes that NEPacketTunnelProvider, NEHotspotHelper, and NEHotspotManager extensions stop functioning if the containing app hasn't been launched by the user within some recent window (e.g. 30, 60, or 90 days). We haven't been able to find any documentation supporting this claim. Specifically, we'd like to know: Is there any app launch recency requirement that would cause iOS to stop invoking a registered NEHotspotHelper or NEHotspotManager configuration? Is there any app launch recency requirement that would cause iOS to tear down or prevent activation of a NEPacketTunnelProvider? More generally, does iOS enforce any kind of "staleness" check on apps that provide Network Extension or Hotspot-related functionality, where not being foregrounded for some period causes the system to stop honoring their registrations? If such a mechanism exists, we'd appreciate any pointers to documentation or technical notes describing the behavior and timeframes involved. If it doesn't exist, confirmation would help us guide our client's debugging in the right direction. Thank you.

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

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

Is it somehow possible to get the transport layer (UDP and TCP) payload amounts for TLS or QUIC connections established via the Network framework? (From within the app itself that establishes the connections.) I am currently using the ntstat.h kernel socket calls, but I hope there is a simpler solution. With ntstat, I have not yet been able to observe a specific connection. I have to search for the connection I am looking in all (userspace) connections.

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

I haven’t come across any official documentation regarding the limit on the number of Network Extensions macOS can run. However, I did see some discussions suggesting that Apple might restrict this to 5 extensions in macOS Tahoe. Is there any official confirmation on this?

Since updating to macOS 26.4 developerbeta 2 I've been getting full loss of dns resolution. I am not running a VPN or any network extensions that I am aware of. I'm not sure how to report this in the feedback utility as I cannot find an appropriate category for it. Happy to file it if someone can give an appropriate suggestion - the closest I could see was Wi-Fi but that wanted Wi-Fi logs for the issue, which I do not believe to be needed as this is not a Wi-Fi connectivity issue. Running dig example.com +short nslookup example.com ping example.com Gives the following output 104.18.27.120 104.18.26.120 Server: 10.0.1.1 Address: 10.0.1.1#53 \ Non-authoritative answer: Name: example.com Address: 104.18.26.120 Name: example.com Address: 104.18.27.120 \ ping: cannot resolve example.com: Unknown host This shows it's not an issue with my local network and that core networking is working, but something in the mDNSResponder/dns stack of macOS is failing. This causes all apps/browsers that do not implement their own DNS lookups to fail (Chrome still works). Sometimes the issue clears after running the following commands (for a period), sometimes it does not. A restart always resolves the issue temporarily. sudo killall -9 mDNSResponder sudo killall -9 mDNSResponderHelper sudo dscacheutil -flushcache sudo ifconfig en0 down sudo ifconfig en0 up

Hey! We discovered an unexpected side-effect of enabling enforceRoutes in our iOS VPN application - video airplay from iOS to tvOS stopped working (Unable to Connect popup appears instead). Our flags combination is: includeAllNetworks = false enforceRoutes = true excludeLocalNetworks = true Interestingly, music content can be AirPlayed with the same conditions. Also, video AirPlay from iOS device to the macOS works flawlessly. Do you know if this is a known issue? Do you have any advice if we can fix this problem on our side, while keeping enforcRoutes flag enabled?

I am using Network framework for connecting two iPad devices that are connected through LAN and has Wifi enabled. I have enabled peerToPeerIncluded. I would like to understand how the framework chooses the interface types for browsing and discovering devices. When I start a browser with browser.run or listener.run, does the browser and advertiser browse and listen on all available interface types? My concern is that if it does in only one interface, Is there a chance that the browser is browsing in one interface(Lets say WiredEthernet) and the listener is listening on another interface(Lets say AWDL) and they dont discover?

All of our uses of CFSockets have started causing crashes in iOS 16. They seem to be deprecated so we are trying to transition over to using the Network framework and NWConnection to try to fix the crashes. One of our uses of them is to ping a device on the local network to make sure it is there and online and provide a heartbeat status in logs as well as put the application into a disabled state if it is not available as it is critical to the functionality of the app. I know it is discouraged to disable any functionality based on the reachability of a resource but this is in an enterprise environment where the reachability of this device is mission critical. I've seen other people ask about the ability to ping with the Network framework and the answers I've found have said that this is not possible and pointed people to the SimplePing sample code but it turns out our existing ping code is already using this technique and it is crashing just like our other CFSocket usages, inside CFSocketInvalidate with the error BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock. Is there any updated way to perform a ping without using the CFSocket APIs that now seem to be broken/unsupported on iOS 16?

Dear Apple Developer Support Team, I am writing to inquire about the process for obtaining approval for the following entitlement in my iOS/macOS app: <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider</string> </array> Specifically, I would like guidance on: The steps required to submit a request for this entitlement. Any necessary documentation or justification that needs to be provided to Apple. Typical review timelines and approval criteria. Any restrictions or compliance requirements associated with this entitlement. Our app intends to implement a content filtering functionality to enhance network security and user safety. We want to ensure full compliance with Apple’s policies and guidelines. Could you please provide detailed instructions or point us to the relevant resources to initiate this approval process? Thank you for your assistance.

We have a VPN app that uses NEPacketTunnelProvider with includeAllNetworks = true. We've encountered an issue where push notifications are not delivered over Wi-Fi while the tunnel is active in a pre-MFA quarantine state (tunnel is up but traffic is blocked on server side), regardless of whether excludeAPNS is set to true or false. Observed behavior Wi-Fi excludeAPNS = true - Notifications not delivered Wi-Fi excludeAPNS = false - Notifications not delivered Cellular excludeAPNS = true - Notifications delivered Cellular excludeAPNS = false - Notifications not delivered On cellular, the behavior matches our expectations: setting excludeAPNS = true allows APNS traffic to bypass the tunnel and notifications arrive; setting it to false routes APNS through the tunnel and notifications are blocked (as expected for a non-forwarding tunnel). On Wi-Fi, notifications fail to deliver in both cases. Our question Is this expected behavior when includeAllNetworks is enabled on Wi-Fi, or is this a known issue / bug with APNS delivery? Is there something else in the Wi-Fi networking path that includeAllNetworks affects beyond routing, which could prevent APNS from functioning even when the traffic is excluded from the tunnel? Sample Project Below is the minimal code that reproduces this issue. The project has two targets: a main app and a Network Extension. The tunnel provider captures all IPv4 and IPv6 traffic via default routes but does not forward packets — simulating a pre-MFA quarantine state. The main app configures the tunnel with includeAllNetworks = true and provides a UI toggle for excludeAPNS. PacketTunnelProvider.swift (Network Extension target): import NetworkExtension class PacketTunnelProvider: NEPacketTunnelProvider { override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1") let ipv4 = NEIPv4Settings(addresses: ["198.51.100.1"], subnetMasks: ["255.255.255.0"]) ipv4.includedRoutes = [NEIPv4Route.default()] settings.ipv4Settings = ipv4 let ipv6 = NEIPv6Settings(addresses: ["fd00::1"], networkPrefixLengths: [64]) ipv6.includedRoutes = [NEIPv6Route.default()] settings.ipv6Settings = ipv6 let dns = NEDNSSettings(servers: ["198.51.100.1"]) settings.dnsSettings = dns settings.mtu = 1400 setTunnelNetworkSettings(settings) { error in if let error = error { completionHandler(error) return } self.readPackets() completionHandler(nil) } } private func readPackets() { packetFlow.readPackets { [weak self] packets, protocols in self?.readPackets() } } override func stopTunnel(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) { completionHandler() } override func handleAppMessage(_ messageData: Data, completionHandler: ((Data?) -> Void)?) { if let handler = completionHandler { handler(messageData) } } override func sleep(completionHandler: @escaping () -> Void) { completionHandler() } override func wake() { } } ContentView.swift (Main app target) — trimmed to essentials: import SwiftUI import NetworkExtension struct ContentView: View { @State private var excludeAPNs = false @State private var manager: NETunnelProviderManager? var body: some View { VStack { Toggle("Exclude APNs", isOn: $excludeAPNs) .onChange(of: excludeAPNs) { Task { await saveAndReload() } } Button("Connect") { Task { await toggleVPN() } } } .padding() .task { await loadManager() } } private func loadManager() async { let managers = try? await NETunnelProviderManager.loadAllFromPreferences() if let existing = managers?.first { manager = existing } else { let m = NETunnelProviderManager() let proto = NETunnelProviderProtocol() proto.providerBundleIdentifier = "<your-extension-bundle-id>" proto.serverAddress = "127.0.0.1" proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs m.protocolConfiguration = proto m.localizedDescription = "TestVPN" m.isEnabled = true try? await m.saveToPreferences() try? await m.loadFromPreferences() manager = m } if let proto = manager?.protocolConfiguration as? NETunnelProviderProtocol { excludeAPNs = proto.excludeAPNs } } private func saveAndReload() async { guard let manager else { return } if let proto = manager.protocolConfiguration as? NETunnelProviderProtocol { proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs } manager.isEnabled = true try? await manager.saveToPreferences() try? await manager.loadFromPreferences() } private func toggleVPN() async { guard let manager else { return } if manager.connection.status == .connected { manager.connection.stopVPNTunnel() } else { await saveAndReload() try? manager.connection.startVPNTunnel() } } } Steps to reproduce Build and run the sample project with above code on a physical iOS device. Connect to a Wi-Fi network. Set excludeAPNS = true using the toggle and tap Connect. Send a push notification to the device to a test app with remote notification capability (e.g., via a test push service or the push notification console). Observe that the notification is not delivered. Disconnect. Switch to cellular. Reconnect with the same settings. Send the same push notification — observe that it is delivered. Environment iOS 26.2 Xcode 26.2 Physical device (iPhone 15 Pro)

I am trying to migrate an app to use Network framework for p2p connection. I came across this great article for migrating to Network framework however this doesnt use the new structured concurrency. This being introduced with iOS 26, there doesnt seem to be any sample code available on how to use the new classes. I am particularly interested in code samples showing how to add TLS with PSK encryption support and handling of switching between Wifi and peer to peer interface with the new structured concurrency supported classes. Are there any good resources I can refer on this other than the WWDC video?

I'm using NEPacketTunnelProvider to intercept DNS queries, forward them upstream, and inject the responses back via writePacketObjects(). This works correctly for responses under ~500 bytes. For larger responses (~893 bytes, e.g. DNS CERT records), writePacketObjects() returns without error but mDNSResponder never receives the packet — it retries 3–4 times and then times out. What I have verified: IP and UDP checksums are correct UDP length and IP total length fields are correct Maximum packet size (MTU) set to 1500 in NEIPv4Settings/NEIPv6Settings Approaches tried: Injecting the full 921-byte packet — writePacketObjects() succeeds but the packet never reaches mDNSResponder IP-level fragmentation — fragments appear to be silently dropped Setting the TC (truncation) bit — mDNSResponder does not retry over TCP Truncating the response to ≤512 bytes — the packet arrives but the data is incomplete Questions: Is there a supported way to deliver a DNS response larger than 512 bytes through NEPacketTunnelFlow? Does NEPacketTunnelProvider impose an undocumented packet size limit below the configured MTU? Does mDNSResponder silently discard responses larger than 512 bytes when the original query had no EDNS0 OPT record? Is there a way to signal that larger responses are supported? Are IP-level fragments reliably delivered through writePacketObjects()? Tested on iOS 26.3, physical device.

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.

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.