Signing application with app extensions

We have developed an electron app which we want to extend with an action extension. The action extension is written in swift in Xcode. Our plan was to build the .appex file and insert it into the PlugIns folder in our electron app, but I don't think this is the right way to do it?

If we insert the .appex file before notarization then we get an error that we are "replacing existing signature".

If we manually insert it after the notarization then we get an error with the app is damaged and can’t be opened.

Can anybody provide a procedure for this kind of merge I would imagine that it goes something like:

  1. Sign app
  2. Sign extension
  3. Add extension to App
  4. Notarize app

For signing the app we use electron-builder.

Answered by DTS Engineer in 803247022
If we insert the .appex file before notarization then we get an error that we are "replacing existing signature".

That’s not an error; it’s just codesign telling you about the action it took. Consider:

% cp /usr/bin/true MyTrue
% codesign -s - MyTrue ; echo $?
MyTrue: is already signed
1
% codesign -s - -f MyTrue ; echo $?
MyTrue: replacing existing signature
0

The first codesign failed because the program was already signed; the second worked, because of the -f flag, but you then get the replacing existing signature message.

Taking a step back, it’s critical that you insert the app before the final signing step of the container app. That way the appex is sealed over by the code signature. If you insert it after, you break the seal on the existing code signature and, as you’ve seen, bad things ensure.

For general advice on how to sign code manually, see:

Share and Enjoy

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

If we insert the .appex file before notarization then we get an error that we are "replacing existing signature".

That’s not an error; it’s just codesign telling you about the action it took. Consider:

% cp /usr/bin/true MyTrue
% codesign -s - MyTrue ; echo $?
MyTrue: is already signed
1
% codesign -s - -f MyTrue ; echo $?
MyTrue: replacing existing signature
0

The first codesign failed because the program was already signed; the second worked, because of the -f flag, but you then get the replacing existing signature message.

Taking a step back, it’s critical that you insert the app before the final signing step of the container app. That way the appex is sealed over by the code signature. If you insert it after, you break the seal on the existing code signature and, as you’ve seen, bad things ensure.

For general advice on how to sign code manually, see:

Share and Enjoy

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

Ohhh, I might have looked at the wrong thing, the error is actually "valid or unsupported format for signature In subcomponent: X.app/Contents/PlugIns/Y.appex"

OK, well that’s an entirely different kettle of fish (-:

I recommend that you double check the on-disk structure of Y.appex. I suspect that the process you used to insert it into the app has broken it in some way.

For example, I sometimes see this when folks copy code using cp rather than ditto. cp ‘expands’ symlinks, which can break a bundle’s structure.

Also, as explained in Creating distribution-signed code for macOS, you have to sign code from the inside out. In this case that means signing Y.appex before you sign X.app.

Share and Enjoy

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

Signing application with app extensions
 
 
Q