Somehow, I was expecting to do DoH right away using pre-resolved IPs are provided. It caused a bit of confusion, since we were not handling UDP properly at the time, so had to enable this explicitly. As for when it changed - can't really tell, sorry. I'll just handle UDP properly so plain DNS won't cause issues and as long as macos eventually switches to DoH it's all fine. Thank you for clarifying!

Sysex train it is. Few follow-up questions: Is it really necessary to disable SIP in order to be able to conveniently test system extensions signed with Apple Development cert and automatic code signing? Entitlement names for Release build vs Debug would differ if we're planning to re-sign Release build with Developer ID, right? It seems that for local development appex might be better, if practically there's almost no difference besides tweaks in entitlements/xcodegen configuration, main function and sysex activation code. While trying to get sysx working locally with SIP disabled, I ended up with the following error message: System extension activation failed: Invalid extension configuration in Info.plist and/or entitlements: System extension <SYSX_BUNDLE_ID>.systemextension does not appear to belong to any extension categories Entitlements and overall configuration seem in order. What could that be?

Looking into the sysex vs appex, thanks. We probably want to support both eventually, but at the moment the app is distributed on our own with Developer ID signing + notarizing. Also, somehow the issue in the post was cause by a previously installed (6 months ago or more) iOS version of the very same app (same identifier for the app and NE). TestFlight iOS app was also somewhere in /Applications and probably affected developer build of the mac version. After deleting the iOS TestFlight version of the app we managed to finally run in Debug mode on the failing device.

Failing device is mentioned in provisioning profiles for both app and appex (matching Provisioning UDID). This log also appears on another device where everything's fine, not sure if it's relevant or what to make of it: (NetworkExtension) [com.apple.networkextension:] Provider is not signed with a Developer ID certificate For now assuming it's just noise and the true issue is in signature/smth else validation. Noticed an interesting thing: if I try to run .app built and signed on the failing device after allowing it via security settings ("Open Anyway") and removing quarantine, then NE gets registered and also started successfully. I also compared entitlements, signatures and provisioning profiles for both app and appex. They all seem to match for .app bundles done on both devices.

App is not sandboxed, NE is sandboxed. Network extension entitlements (packet-tunnel) are specified for both targets.