I believe that it’s a good option. Good to know, thanks! I’ve seen a lot of folks bump into weird problems doing this, so I’m not a huge fan. Yeah, myself included. The sample project worked fine out the box for a LaunchAgent, but adapting it to a LaunchDaemon didn't work. The SMAppService.register call went through fine, but it didn't automatically approve it in System Settings, so it was obviously not a complete installation.

What I've gleaned from this thread is that if you need your LaunchDaemon to be installed via MDM, you need to use launchctl from an installer, and that you can't use SMAppService at all? We've been using SMAppService (and GUI prompts to approve it) on the assumption it behaves similarly to Network Extensions, where they can be preapproved by MDM - but it's become clear that's not the case. Is our only option in supporting MDM installations to switch to launchctl in an installer and no longer distribute a dmg or zip?

That's very unfortunate. We might have to do away with the network extension altogether and create a TUN device from a LaunchDaemon.

Thanks for the resources. We did some testing today, and the only way we were able to send packets down another utun interface was when we explicitly set the interface using the IP_BOUND_IF socket option. We had to query an AF_ROUTE socket to determine which interface to set based on the destination IP, and this seems to work. One issue with any approach that involves modifying how we create sockets, or manually setting sockopts, is that our Go codebase creates sockets in hundreds of places. Finding and patching everywhere we do so would be a huge amount of work. Is it possible a solution to this exists that doesn’t require patching all this code?

One natural conclusion to reach here is that this is an XPC service cache invalidation issue. Whatever system component maps the service name to the system extension isn't aware of the new system extension using that service name when the app attempts to connect. One thing that appears to workaround the issue in it's entirety, without any extra admin prompts on reinstall is using a different NEMachServiceName for each version of the app, specifically, something of the form: <key>NEMachServiceName</key> <string>$(TeamIdentifierPrefix)com.company.bundleName.VPN.$(CURRENT_PROJECT_VERSION)</string> In my initial tests, I couldn't find any issues with this, but scouring the web and inspecting the Info.Plists on my device, I haven't found any instances of other apps doing this. Are you aware of any sharp edges that might arise as a result of this workaround, or if Apple doesn't recommend modifying the service name every build? (We use X.Y.Z.N for CFBundleVersion/CURRENT_PROJECT_VERSION, where N is the build number, the number of commits since the X.Y.Z release) One issue I forsee is if we ever wanted a program not bundled with the app (and therefore not aware of the sysex version) to connect to the XPC service, but I think in that case we would just create another listener anyway?

However, I’m surprised that connection:didWriteData:totalBytesWritten:expectedTotalBytes: is not being delivered. I can’t see any good reason for it to be suppressed when you use the convenience methods. Feel free to file a bug about that. And, if you do, please post your bug number. This is still the case. Is there really no other way to get the progress of the download when using the async versions of URLSession functions?

This continues to be frustrating for our users, yet I'm still unable to reproduce the issue exactly as described by those users in whilst working in a 15.4 VM. In that VM, I'm only able to reproduce the issue if the System Extension replacement occurs whilst the VPN is enabled in System Settings. Our preinstall script now consistently ensures the the VPN is disabled before installing, and the postinstall script does not restart the VPN. I can only hope resolving the issue in the scenario where I could reproduce it also resolves it in other scenarios. Please let me know if there's any other work I can do to help. In the meantime, I'm going to apply a workaround where we always return cancel for actionForReplacingExtension, and implement our own replacement logic. This has the unfortunate downside of requiring two administrator permission prompts (one to deactivate, another to activate) and one regular prompt (to re-add the VPN configuration, since it gets deleted alongside the extension). It's a pretty horrible UX, but it seems preferable to continuing to direct users on how to manually do this.

That’s a surprise. AFAIK Xcode isn’t capable of correctly exporting a Developer ID-signed NE sysex We generate our xcode project file using xcodegen, which lets us modify the entitlements (adding the system extension suffix) just before building using environment variables. Then, during the build, we also set the two different provisioning profiles using environment variables. Source available. If it works, this bug isn’t as simple as we’re suspecting, and we should talk more. Alas, I was not able to reproduce the issue exactly as described in a fresh VM. I'll copy-paste from the feedback assistant comment, where I attached three versions, and the sysdiagnose bundle. There was no XPC connection invalidation when upgrading from the attached Version 2 to Version 3. Version 3 being just a few hours old. However, when upgrading from Version 2 to Version 3 on my personal macbook running macos 15.3.1, the issue occurred. In both cases, the VPN was stopped before the upgrade. Interestingly, when upgrading from Version 2 to Version 3 for a second time on the same macbook, the issue does not occur, also leading me to believe it has something to do with the ingesting of the notarization ticket. I initially tested an upgrade from Version 1 to Version 2 on another fresh VM. What I didn't realise is that the VPN configuration applied by Version 1 had a different slug to that expected by Version 2. So, when upgrading, the VPN was not stopped by the .pkg preinstall scutil, and so Version 2 replaced the network extension whilst the VPN was running. Following this, the XPC connection was consistently invalidated between the Version 2 app, and the version 2 NE. Attached is a sysdiagnose (with NE debug logs enabled) captured right after the issue occurred. But to sum up: On an end-user device, an upgrade from Version 2 to 3 causes the issue. The network extension is not replaced whilst the VPN is running. This tracks with what our users are reporting. The issue only appears to occur when upgrading to Version 3 for the first time. On a fresh VM, an upgrade from 2 to 3 does not cause the issue. I could not reproduce it in 5+ attempts. On a fresh VM, an upgrade from 1 to 3 does cause the issue, as the network extension is replaced whilst the VPN is running. I could reproduce this consistently, but only on a fresh VM. Like on the end-user device, the issue only occurs in the VM when upgrading to Version 3 for the first time, and only if the VPN is running when the NE replacement happens.

@kithrup Were you ever able to fix this, or did you ever get a response on your feedback ticket?

I'm also having a similar issue - were you ever able to fix this?