After switching to the new DNS Proxy system extension extension point, I’m seeing a mismatch between the current Info.plist on disk and what nesessionmanager reports during validation. Current Info.plist of the installed system extension: plutil -p "/Applications/MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension/Contents/Info.plist" { "CFBundleIdentifier" => "com.example.agent.MyMacProxy.dnsProxy" "CFBundlePackageType" => "SYSX" "NSExtension" => { "NSExtensionPointIdentifier" => "com.apple.dns-proxy" "NSExtensionPrincipalClass" => "com_example_agent_MyMacProxy_dnsProxy.DNSProxyProvider" } "NSSystemExtensionUsageDescription" => "SYSTEM_EXTENSION_USAGE_DESCRIPTION" ... } There is no NetworkExtension key in this Info.plist. However, when the host app tries to activate the DNS proxy system extension, I still get: Validating system extension com.example.agent.MyMacProxy.dnsProxy System Extension validation failed: Error Domain=NetworkExtensionErrorDomain Code=2 "The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid NetworkExtension key in its Info.plist: the value for the NetworkExtension key must be a non-empty dictionary." Spotlight does not show any other copies of this bundle ID: mdfind 'kMDItemCFBundleIdentifier == "com.example.agent.MyMacProxy.dnsProxy"' no results Is there any known caching behaviour in nesessionmanager or in the NetworkExtension validation logic that could cause it to keep expecting a NetworkExtension dictionary, even when the current Info.plist only declares the com.apple.dns-proxy extension point?

Thanks for the clarification about Developer ID vs Apple Development and for the links. Per your advice, I’ve switched both the host app and the DNS Proxy system extension to Apple Development signing and the legacy dns-proxy entitlement. Current setup macOS: 15.7.3 (24G419) Xcode: 26.2 (17C52) Host app bundle ID: com.example.agent.MyMacProxy DNS Proxy system extension bundle ID: com.example.agent.MyMacProxy.dnsProxy System extension entitlements: <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy</string> </array> System extension Info.plist (built .systemextension inside the host app): <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.system_extension.network_extension</string> <key>NSExtensionPrincipalClass</key> <string>MyMacProxy.DNSProxyProvider</string> </dict> There is no NetworkExtension key in this Info.plist (confirmed with plutil -p on the built .systemextension in both DerivedData and /Applications). The system extension is embedded at: MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension The host app (from /Applications) configures the DNS Proxy via NEDNSProxyManager with: providerBundleIdentifier = "com.example.agent.MyMacProxy.dnsProxy" What happens If I add a NetworkExtension dictionary with NEProviderClasses and try different keys like: <key>NetworkExtension</key> <dict> <key>dns-proxy</key> <array> <string>MyMacProxy.DNSProxyProvider</string> </array> </dict> (or DNSProxy, or NEDNSProxy as the key), I consistently get Code=4 errors, for example: Validating system extension com.example.agent.MyMacProxy.dnsProxy System Extension validation failed: Error Domain=NetworkExtensionErrorDomain Code=4 "The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid extension point in its NetworkExtension key in its Info.plist: dns-proxy." If I then remove the NetworkExtension dictionary entirely (leaving only the NSExtension dictionary shown above), the Code=4 error goes away, but nesessionmanager still reports Code=2 about NetworkExtension needing to be a non‑empty dictionary, even though that key is no longer present in the current Info.plist. To try to reset state, I’ve done the following: Remove standalone product, keep only embedded systemextension (reconfigured build to only embed) systemextensionsctl uninstall <TEAM_ID> com.example.agent.MyMacProxy.dnsProxy systemextensionsctl reset killall nesessionmanager killall systemextensionsd Reboot and reinstall host app into /Applications The behaviour does not change: either Code=4 if NetworkExtension is present, or Code=2 complaining about NetworkExtension even when it’s not in the current plist. Questions For a DNS Proxy implemented as a Network Extension system extension under Apple Development signing, is the intended pattern to have no NetworkExtension dictionary at all (only NSExtensionPointIdentifier = com.apple.system_extension.network_extension plus the dns-proxy entitlement), or should DNS Proxy system extensions still declare a NetworkExtension dictionary with NEProviderClasses? If a NetworkExtension dictionary is required, what are the currently valid keys for a DNS Proxy system extension? dns-proxy, DNSProxy, and NEDNSProxy all trigger NetworkExtensionErrorDomain Code=4 with “invalid extension point” in my tests. Do you have a minimal, known‑good DNS Proxy system extension sample (Info.plist + entitlements) that passes this validation on current macOS (15.7.3 / Xcode 26.2)? A small reference example would be extremely helpful to compare against my configuration. Share and Enjoy, and thanks again for your time!

Thanks for the clarification about Developer ID vs Apple Development and for the links. Previously I started with Developer ID and the dns-proxy-systemextension entitlement, but per your advice I’ve now switched both the host app and the DNS Proxy system extension to Apple Development signing and the legacy dns-proxy value. Current Apple Development setup macOS: 15.7.3 (24G419) Xcode: 26.2 (17C52) Host: com.example.agent.MyMacProxy DNS Proxy system extension: com.example.agent.MyMacProxy.dnsProxy System extension entitlement: xml com.apple.developer.networking.networkextension dns-proxy System extension Info.plist (built .systemextension inside the host app): xml NSExtension NSExtensionPointIdentifier com.apple.system_extension.network_extension NSExtensionPrincipalClass MyMacProxy.DNSProxyProvider There is no NetworkExtension key in this plist (confirmed with plutil -p on the built .systemextension in both DerivedData and /Applications). The system extension is embedded at: MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension The host app (from /Applications) configures DNS Proxy via NEDNSProxyManager with: swift providerBundleIdentifier = "com.example.agent.MyMacProxy.dnsProxy" What happens If I add a NetworkExtension dictionary with NEProviderClasses and try different keys like: dns-proxy DNSProxy NEDNSProxy I consistently get Code=4 errors such as: text Validating system extension com.example.agent.MyMacProxy.dnsProxy System Extension validation failed: Error Domain=NetworkExtensionErrorDomain Code=4 "The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid extension point in its NetworkExtension key in its Info.plist: dns-proxy." If I then remove the NetworkExtension dictionary entirely (leaving only the NSExtension dict shown above), Code=4 goes away, but nesessionmanager still reports Code=2 about NetworkExtension needing to be a non‑empty dictionary, even though that key is no longer present in the current Info.plist. I’ve tried: removing the standalone .systemextension product (keeping only the embedded one) systemextensionsctl uninstall com.example.agent.MyMacProxy.dnsProxy and systemextensionsctl reset killing nesessionmanager / systemextensionsd rebooting and reinstalling the host app into /Applications The behaviour doesn’t change. Questions For a DNS Proxy implemented as a Network Extension system extension under Apple Development signing, is the intended pattern to have no NetworkExtension dictionary at all (only NSExtensionPointIdentifier = com.apple.system_extension.network_extension plus the dns-proxy entitlement), or should DNS Proxy system extensions still declare a NetworkExtension dictionary with NEProviderClasses? If a NetworkExtension dictionary is required, what are the currently valid keys for a DNS Proxy system extension (given that dns-proxy, DNSProxy, and NEDNSProxy all trigger Code=4 for “invalid extension point”)? If you have a minimal, known‑good DNS Proxy system extension sample (Info.plist + entitlements) that passes this validation on current macOS, that would be extremely helpful as a reference.

I updated the App ID for the DNS Proxy system extension and noticed that Developer Portal only exposes the legacy dns-proxy value under Network Extensions. There is no option for dns-proxy-systemextension. My extension’s entitlements currently contain: xml com.apple.developer.networking.networkextension dns-proxy-systemextension When I create a Mac App Development provisioning profile for this App ID and try to use it for signing the system extension target, Xcode fails with: Provisioning profile "Dev-Mac-App-DNSProxy" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. So at this point the entitlements and the Developer Portal capabilities cannot be made to match: the profile only knows about dns-proxy, while my extension needs dns-proxy-systemextension. Is dns-proxy-systemextension the correct entitlement value for a DNS Proxy packaged as a system extension today, and if so, how should this be represented/configured in the Developer Portal so that the Mac App Development profile matches the entitlement?

Thanks for the pointers and links. To answer your question: this is actually the first time I’m bringing up this NE system extension. I started directly with Developer ID because the final goal is MDM deployment, but I haven’t yet verified the setup with Apple Development signing. I’ll now switch both the host app and the DNS Proxy system extension to Apple Development signing, follow the “System Extension Hints” and “Debugging a Network Extension Provider” flow (post‑build copy to /Applications, run from there, first‑light log in main.swift, attach debugger, etc.), and see if the provider can be started successfully in that configuration. If I still get OSSystemExtensionErrorDomain error 9 / “extension category returned error” with Apple Development signing on a clean dev machine, I’ll update this thread with the exact steps, logs, and configuration.