Code signing and notarizing macOS app

Question

Created May ’21

Replies 1

Boosts 0

Views 1.3k

Participants 2

I recently joined the developer program in the hope that i could finally get my installers to pass gatekeeper.

it looks like this is way more complex than i imagined due to the additional step of notarization, although im also not sure if i even got the code signing right, as there is no way to check on the machine im building on (?)

My installers are made with Whiteboard Packages and each installer consists of a standalone app as well as plugins (dynamic libraries) in several formats.

First concern is that when i select Enable Automatic signing. I dont have the option to select my Apple Distribution certificate. I only see if it i uncheck the automatic mode. Is that normal/ok? (I *think* im supposed to be signing the app/plugins with that certificate but actually i dont know)

i assume I then need to sign the installer with a Developer ID for installer certificate. I have added that to Packages seemingly ok.

after downloading onto a different machine, the installer still triggers gatekeeper. i guess i have to notarize it but dont now how to do that as im not using the archive system.

lastly my release builds are scripted including building the installer. i would need notarization to be scripted too, for this to be in anyway feasible.

Boost

Answer 1

DTS Engineer OP

Apple

May ’21

First concern is that when i select Enable Automatic signing. I dont
have the option to select my Apple Distribution certificate. I only
see if it i uncheck the automatic mode. Is that normal … ?

That’s certainly normal. Whether it’s OK or not depends on your perspective (-:

My general advice is that you use automatic signing and that means that you’ll use an Apple Development signing identity for day-to-day development. You should then use an archive and export workflow to create your final product. Which brings us to this:

lastly my release builds are scripted including building the
installer. i would need notarization to be scripted too, for this to
be in anyway feasible.

Absolutely. You can notarise from the command line using altool. See Customizing the Notarization Workflow. Better yet, you can combine this with your archive and export workflow to create a single step that spits out a finished product. More on this below.

each installer consists of a standalone app as well as plugins
(dynamic libraries) in several formats

Are those plug-ins for your app? Or are their plug-ins that you install to be loaded by other apps?

This matters because it controls how you manage this process. In the first case you’d do something like this:

Configure your Xcode project for day-to-day developer, as I discussed above. Configure the app target to build the plug-in targets and embed the resulting plug-ins.
For distribution, use the archive action in xcodebuild to create an archive for your app target.
Then use the -exportArchive option to export that archive for Developer ID.
Use productbuild (or, if you must, a third-party tool) to build the installer from the exported app.
Use altool to notarise.

If, however, your plug-ins are standalone products, things get a little more complex. The basic structure is the same but you run into problems because -exportArchive can only export apps. To fix this:

In step 1, run multiple archive actions to archive each target.
In step 2, use -exportArchive to export your app from its archive but also write a custom script to export each of your plug-ins.

I realise that this can be a bit hard to grok, so I’m going to point you at this thread, where I worked through this process with another developer.

Finally, some references to a couple of other keys DevForums posts:

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

0