We don't typically use Xcode for development of this app (our build environment uses CMake and Ninja for the most part), but adding --identifier org.mozilla.macos.FirefoxVPN to the codesign arguments to the daemon binary seems to have gotten the service to run successfully across the upgrade.

Yes, the code signing identifier of the daemon changed as a part of the upgrade. We split the application from a monolithic binary into separate GUI and daemon executables. The designated requirement of the monolithic GUI hasn't changed: Executable=/Applications/Mozilla VPN.app/Contents/MacOS/Mozilla VPN designated => identifier "org.mozilla.macos.FirefoxVPN" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "43AQ936H96" And the designated requirement of the daemon has a different identifier: Executable=/Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon designated => identifier "org.mozilla.macos.FirefoxVPN.daemon" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "43AQ936H96" Is there a way to tell launchd about the change? We have also tried using a postinstall script to unload the daemon using launchctl bootout system/org.mozilla.macos.FirefoxVPN.service to no avail. There does appear to be some way to get launchd to accept the upgrade. For example, the following steps get back to a working machine after the upgrade: Disable our app's Allow in the Background permission in the Login Items settings. Delete the app bundle off disk and empty the trash. Close and re-open the System Settings to the Login Items page and wait for our app's entry to disappear. Re-install the application again and it works as expected.