Apple Gatekeeper notarised distributables



Apple looks to be furthering gatekeeper protection with additional checks on distributed binaries, we can see some details about it here: and a little more from Ars here:

It seems Apple wants to perform some kind of basic review of signed binaries and to then act as a notary on the developer’s signature, vouching for it not containing malware etc, so they can be less dramatic when warning people about the dangers of using programs they’ve downloaded. It’s optional at the moment, but Apple says: “in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple.”

Feels a bit like typical Apple nannying/over-reach, but I can see the benefit to consumers and the platform as a whole, so I’ll just go along with this without too much resistance.

I’m wondering if anybody has any experience of this with audio plug-ins, maybe somebody has tried it if they knew about it a while ago, and/or knows what the future implications for audio plug-ins is likely to be when it becomes mandatory.



Feels a bit like making non-app store deployment more of a hassle to me.


Yes, it will be, but that’s the most likely place for people to unwittingly download a security problem into their Mac so Apple wants to tie it down and I think that’s a fair thing to do as long as we’re not overly inconvenienced as devs (which is what I’m trying to establish).


i guess it depends what the process is and how long it takes? my immediate concern is it adding time to beta releases for testers, but from what I can see it’s an automated process rather than requiring human intervention, so that shouldn’t be bad hopefully.


Does anybody have success with notarisation via command line tools (xcrun altool) ? (For distribution outside the App Store)


Yes xcrun altool worked fine here to notarize installer packages. Make sure your binaries inside (vst, au, aax etc.) are all signed otherwise it will be rejected.


Is this an automated process with a fast verified vs rejected response?


okay it feels a little bit like entering unknown terrain …

I was able to notarise a zip file which contains my (previously signed) plugin.component (AU)

crun altool --notarize-app --primary-bundle-id "com.mycompany.notarizationtest1" --username "" --file

i had to create an app-specific apple password before (never used this feature before, to use this notarisation tools.

you can check the current state with this command
xcrun altool --notarization-history 0 -u

You can also use the keyChain to store the password, and download a log-file from the notarisation process, better described here:

according to apple:

You should also attach the ticket to your software using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection isn’t available.


While you can notarize a ZIP archive, you can’t staple to it directly. Instead, run stapler against each individual item that you originally added to the archive.

Which I did for the component file:

But I getting this weird message: (for an AudioUnit!!!)

xcrun stapler staple MyPlugin.component

Processing: /Users/username/cpp_projects/MyPlugin/Builds/MacOSX/build/Release/testSign/MyPlugin.component

Stapler is incapable of working with Pro Tools Plug-In files.

currently I ignored the fact the the the “runtime hardened” feature for signing, I’m wondering if the notarisation process “sees” the plugin-binaries as executables at all :-/

Also I checked the verification of the plugin-files, and wasn’t successful

spctl -a -v MyPlugin.component/

MyPlugin.component/: rejected (the code is valid but does not seem to be an app)


If this is failing on plug-ins does it suggest we should be only doing it for the installers?


I don’t know, the notarisation IS successful, but I wonder if apple detects the binaries as executables, or just as plain data-files.

Notarisation of the installer/pkg can’t be wrong.

Probably I do something wrong, what ever …