This summer it will be five years since Apple introduced notarization, and four since it started to be enforced. Yet there’s still a lot of confusion and some misinformation about notarization and how it can and should be used. This article tries to clarify.

Approval and disapproval

There are three preferred ways to provide software to other users, regardless of whether you’re a commercial or hobby developer:

• the App Store, which has its own requirements for code review and certification;
• pre-built executable binaries, which should be provided notarized even if they’re free;
• open source code, supplied as source code for the end-user to build.

These ensure that someone independent of the developer approves that code as being non-malicious. Inevitably, that isn’t perfect, and some malicious products have ended up in the App Store or being notarized. In those cases, it’s less about approval than disapproval: should any signed and notarized product be found to be malicious, Apple quickly revokes its certificate and notarization, and every copy of macOS will then automatically block that code from running.

No matter how careful and well-intentioned, a supplier who tries to mix the second and third ways doesn’t have the same powers of revocation. In the event that a pre-built binary without an Apple signing certificate and notarization turns out to be malicious, it can’t be blocked from running on macOS, and could therefore spread uncontrolled. That’s the real power of signing and notarization, in the consequences of disapproval.

Requirements

Apple details these here. In short, they require that the app or executable:

• is fully signed using an appropriate Developer ID certificate,
• includes a secure timestamp with its signature,
• has the Hardened Runtime enabled for apps and command tools,
• is linked against the macOS 10.9 SDK or later,
• mustn’t claim a com.apple.security.get-task-allow entitlement,
• if it has entitlements, they’re correctly encoded and formatted,
• to be submitted to Apple for checking and approval.

Items submitted for notarization can be disk images, installer packages, or Zip archives.

Checking notarization

Successful notarization results in the issue of a ticket, which can be ‘stapled’ into an app or other bundle. However, that ticket isn’t necessary for macOS checks on notarization to succeed. When Gatekeeper checks code for notarization, it doesn’t need to find that ticket present, as that will be checked with Apple anyway. If there’s no ticket present, as there won’t be in the case of a command tool, Apple will confirm if that file or bundle has been notarized, and whether that remains valid, or has been revoked.

Tickets can be stapled to app and other bundles, disk images, or flat installer packages, but not Zip archives or Mach-O binaries.

Notarizing command tools

I notarized a command tool for the first time in June 2019, and since then have notarized all the command tools that I offer here. In those days, the procedure started with adding the code signature into the binary, incorporating the built binary into a flat Installer package signed with a Developer Installer certificate, then submitting that package for notarization using the altool tool, as detailed here.

Although an embedded Info.plist isn’t necessary, it can be worthwhile. That and other improvements are explained here. A later account for Universal binaries is here. Most recently, Apple has replaced altool with notarytool, and its current instructions are here. Note that altool will be going away later this year: if you still use it, now is the time to switch to notarytool.

Third-party notarisation

Apple has long made it clear that the developer submitting software for notarization can be different from that signing the original code, provided that all the other requirements are met. This is perhaps most useful in enterprise and similar environments, where it may be important to deploy a command tool or app that hasn’t been notarized by its developer.

This has a strange effect, in that once notarized by one developer, all other identical copies of that software are also recognised as being notarized. This used to happen in Apple’s early campaign for notarization of legacy products, when users noticed that an old app which couldn’t have been notarized at the time of release was reported as being notarized later. At first this appeared sinister, but turned out to be valuable to everyone using that product.

The extra effort of notarization is well worthwhile even for command tools. Users can still ignore any installer package if they prefer, as notarized command tools don’t need their tickets to be present for macOS to recognise and accept their notarization. And you and your users can have confidence in the effects of disapproval should the need ever arise.