macOS Network Extension Code Signature Error

We are migrating our iOS app to macOS. On iOS, it works fine. But when I try and run on macOS and connect to the VPN, I am getting an error like failed to fetch /Users/stuart/Library/Developer/Xcode/DerivedData/app-byzvshkqegwzqxgervfswmsughkm/Build/Products/Debug/<app_name>.app/Contents/PlugIns/<network_extension_name>.appex/Contents/_CodeSignature/CodeRequirements-1 error=-10.

If I have Settings -> VPN open, it rapidly is connecting and disconnecting. Is there anything I need to do specific to macOS to make this work? Or is this related to a broken code signature? Thanks in advance!

Answered by DTS Engineer in 824633022
Written by stuartwk in 824465022
Our VPN is open source

Cool. Unfortunately that’s too complex for me to build here. I tried cutting it down myself but that proved to be challenging.

I was able to build a gutted version of the appex target, which allowed me to check its structure. That revealed one obvious problem:

% find URnetworkVPN.appex 
…
URnetworkVPN.appex/Contents/MacOS/URnetworkVPN
URnetworkVPN.appex/Contents/MacOS/__preview.dylib
URnetworkVPN.appex/Contents/MacOS/URnetworkVPN.debug.dylib
…

No good can come from having your appex build with preview support enabled. I fixed that by disabling the Enable Debug Dylib Support build setting on the appex target.

Beyond that I couldn’t spot anything particularly egregious.

Have you tried testing this on a ‘clean’ machine? NE relies on our appex infrastructure which relies on Launch Services, which can get very confused on development machines. That’s especially true if you’re dealing with different ‘flavours’ of the same app, so running the iOS build and the macOS build on the same machine. When I encounter weird problems like this, I usually retest on a VM, just to confirm that the problem is real [1].

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] These days this is simultaneously both easier and harder than it was in the past.

How are you doing this migration?

There are a number of different ways to package and run NE providers on macOS. See TN3134 Network Extension provider deployment for the full list. Which approach are you taking?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hey, thanks so much for the response. I should clarify, we're adding support for macOS. We have a PacketTunnelProvider Network Extension, which we're bundling as an app extension for both iOS and macOS (not Catalyst or iOS app on Mac).

We were originally trying iOS app for Mac, but decided to go with the full macOS app instead. I'm wondering if something got botched in the code signature, having run the iOS for Mac app, then switching to support for macOS?

One other thing I'd like to mention is that it was working a few days ago. At some point, it re-prompted to add the VPN configuration to settings, and then stopped working. Now, the behavior is that it keeps rapidly trying to connect the disconnecting.

Our VPN is open source, and the in-progress desktop branch can be found here.

I'm also repeatedly seeing in the logs Last disconnect error changed from "none" to "The VPN app used by the VPN configuration is not installed"

Accepted Answer
Written by stuartwk in 824465022
Our VPN is open source

Cool. Unfortunately that’s too complex for me to build here. I tried cutting it down myself but that proved to be challenging.

I was able to build a gutted version of the appex target, which allowed me to check its structure. That revealed one obvious problem:

% find URnetworkVPN.appex 
…
URnetworkVPN.appex/Contents/MacOS/URnetworkVPN
URnetworkVPN.appex/Contents/MacOS/__preview.dylib
URnetworkVPN.appex/Contents/MacOS/URnetworkVPN.debug.dylib
…

No good can come from having your appex build with preview support enabled. I fixed that by disabling the Enable Debug Dylib Support build setting on the appex target.

Beyond that I couldn’t spot anything particularly egregious.

Have you tried testing this on a ‘clean’ machine? NE relies on our appex infrastructure which relies on Launch Services, which can get very confused on development machines. That’s especially true if you’re dealing with different ‘flavours’ of the same app, so running the iOS build and the macOS build on the same machine. When I encounter weird problems like this, I usually retest on a VM, just to confirm that the problem is real [1].

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] These days this is simultaneously both easier and harder than it was in the past.

macOS Network Extension Code Signature Error
 
 
Q