“It’s not clear what can be notarized”

When you’re new to distributing macOS apps outside the store, the topic of notarization may be foreign to you. Put simply, notarization is about registering your binary to Apple. Unlike uploading for App Store, the process is entirely automatic on Apple’s end – there is no human reviewer to approve or reject your application. Apple would then scan your binary for potential malware (like how most anti-virus software works) and then provide its stamp of approval – the notarization ticket to your binary. If it turned out that in the future your app proved to be malicious, Apple would have a way to stop users from launching the app. There is no download process – users would still download the app from your website, not Apple’s.

Failing to notarize your app would prevent users from launching the app after downloading it. When the user double-clicks the app in Finder, it would show a “… cannot verify that this app is free from malware” dialog similar to the following:

Users can choose to bypass this warning–by holding down the command key while double-clicking the app icon, in which the dialog would have an “Open” button to launch the app anyway. However only power users would know this workaround; normal users would get scared right away and think that your app is no good.

Deliverables to Notarize

You should notarize all executable code that you distribute to others via channels apart from the Mac App Store. These includes:

• Application bundles
• Kernel extensions
• Preference panes
• Screen savers
• Flat installer packages (.pkg)
• Disk images (.dmg)

All bundles would need to be archived into zip files, installer packages, or disk image files in order to upload them to the notarization service.

A successful notarization process results in a notarization ticket. This is a small binary data signed by Apple stating that your binary was notarized successfully. A notarization ticket is public information; anyone can download the ticket given a notarized archive. You should staple this ticket back to the installer package or disk image so that your users’ computer doesn’t need download it again. Moreover, if you don’t staple the ticket and the user’s mac is offline, it would show a similar “cannot check for malware” dialog as if the archive wasn’t notarized.

However you cannot staple the resulting notarization ticket back into .zip files. The workaround is to extract the archive, staple the ticket to each top-level bundles within it, and the re-zip the bundle(s).

Pre-requisites

There are several pre-requisites for binaries to be notarized successfully. These are the most prominent ones:

• The binary would need to be signed with the “Developer ID” signature. This also means that you would need to be an Apple Developer Program member in good standing.
• The binary would need to have hardened runtime enabled. This would prevent code injection to your app at runtime or debugging it, among other tings.
• The code signature must include a secure timestamp. Xcode would only include this during the archive process, and not part of a standard build. Nevertheless you can include one when signing the binary using the codesign utility.

Refer to Resolving Common Notarization Issues for more details.

Next Steps

I’ve provided a complete example on how to deliver apps as a disk image, including notarizing the deliverable and stapling the notarization results. You can also consult Customizing the Notarization Workflow from Apple’s developer documentation library for more information.

---