macOS Notarization and multiple embedded tools/bundles

Viewed 662

My product is a System Pref Pane which contains multiple embedded apps to do its job, including:

  • A background-only renderer.
  • An app to handle a Menu Status Item.
  • An app to check for updates since System Preferences might not be running.
  • An installer that simply copies the System Pref Pane into place (needed because of a code-signing bug that prevents direct distribution of the prefPane).
  • A unix executable relaunch tool to handle loading into System Preferences during an update. This one seems impossible to staple a notarization to.

I have a nice script in Xcode that packages all this together. With Notarization, will I now need to notarize each of these individually starting at the deepest point? That sounds like a total hassle since automating it is difficult with the delay/polling required at Apple.

Will just Notarizing the outter-most container be enough?

I'm looking for suggestions from others that have multiple executables in a single app package as to dealing with Notarization.

2 Answers

Each nested helper app may be codesigned first, and the outer app is deep codesigned using --preserve-metadata. Then the outer app may be notarized. The unix executable can be codesigned if you make a mini bundle folder containing the executable, an Info.plist, and possibly Entitlements.plist. You can notarize a ditto .zip of the bundle, and stapler staple the mini bundle. But I find with inherited security, just the outer app needs the notary as long as the inner apps have their individual sub-app codesigning metadata preserved.

You can notarize top level package(zip, dmg , pkg) From Apple Document:

The notary service accepts disk images (UDIF format), signed flat installer packages, and ZIP archives. It processes nested containers as well, like packages inside a disk image.

Related