Whatever you do with your Mac, there are two major changes which are coming in macOS 10.15 Catalina, and one of them already applies to Mojave.

The most obvious is the loss of all 32-bit software, which only applies to Catalina, and was all but pre-announced. Apple has confirmed that no 32-bit software – app, command tool, or anything else – will run in Catalina. There’s no let-out or special configuration which will allow it. If you need to run 32-bit software when you have upgraded to Catalina, then probably the best way is in a VMWare virtual machine running Mojave or earlier.

The other change which was also effectively pre-announced is the requirement for notarization of software. In this article I’m going to look in more detail at what this means for both Mojave and Catalina, based on Apple’s excellent presentation for developers at WWDC, by Robert Kendall-Kuppe and Garrett Jacobson. Most importantly, this doesn’t just affect macOS 10.15 when it ships this autumn/fall.

What is notarization?

It’s the next step beyond code signing. To get software notarized, you have to be a signed-up developer with an Apple-issued developer certificate, and submit the software to Apple for checking to ensure that it doesn’t contain malware.

It’s also more complex than that, as there are two different routes to notarization. Developers can submit existing apps under a legacy process, or they can build a new version and submit that for a new notarization. In the latter case, the software also has to be hardened, a new security setting which I’ll explain later.

New notarizations normally attach or staple a special ‘ticket’ to an app (but not to some other types of executable code), which is checked when they undergo their first run with the quarantine flag set. Legacy notarizations don’t usually come with a ticket attached. But in all cases, when macOS puts them through first run checks, if the quarantine flag is set, macOS should verify their notarization and signature with Apple’s servers. What isn’t clear at present is how that behaviour works if your Mac can’t connect with those servers, but you want to run that app.

Where notarization goes a significant step further is in checking not only the signature, but the version and approval of that app. Prior to notarization, any developer who had a code signing certificate which was valid could sign any app or other software that they liked, including malware, and they still can. So long as my developer certificate remained valid, I could re-sign and distribute a specially doctored release of Microsoft Word, for example. Notarization doesn’t allow that, and is specific to developer, software, and that particular version. If any of those don’t check out at first run, the app should be crashed out immediately.

When is notarization required?

Most of us were expecting it to become a requirement for apps downloaded from the Internet rather than the App Store, getting a quarantine flag, and undergoing their first run in Catalina. It isn’t as simple as that, and already partly includes Mojave 10.14.5.

Software built before 7 April 2019, even when being first run with a quarantine flag, shouldn’t require notarization in Mojave or Catalina.

Two types of software built from 7 April 2019 do require to be notarized, even when being installed on Mojave 10.14.5, according to Apple:

• kernel extensions, but only new extensions and new versions signed from 7 April 2019 onwards. If they aren’t notarized, there’s a workaround which bypasses checking of notarization, at least on Mojave;
• apps signed by new developers, whose first use of their code signing certificate occurred from 7 April 2019 onwards. This is likely to apply to very few products, and is apparently enforced in 10.14.5, although you can probably bypass it by using the Finder’s contextual Open command.

This article discusses how you can check whether an app, kernel extension or other code is notarized.

This changes again as of 1 June 2019 with respect to Catalina, but not (as far as we know) in Mojave. From that date onwards, all newly-signed apps and other executable code which undergo first run checks (because of a quarantine flag) are required to have been notarized. You can still run apps which haven’t been notarized or even remain unsigned in Catalina, though.

What benefits does notarization bring?

In Mojave, although there are mechanisms for checking notarization, there might appear to be no direct benefits to the user other than the added confidence of knowing that Apple has checked them for malware, as their first run dialog states.

In fact, both Mojave and Catalina are quite different from High Sierra. In addition to undergoing first run checks, hardened (thus all newly notarized, but not legacy) apps run in a protected environment which isn’t a sandbox (already used for App Store and other apps), but which severely limits the ability of malware to hijack them.

Code which they run is subject to signature checking, and their own integrity may be checked at times too. Their code signatures aren’t going to be largely ignored after first run, and some kinds of tampering with a hardened app should make it impossible to open without it crashing immediately. These additional layers of security are provided by the SIP mechanism. Where they need to, hardened apps can opt out of some of that protection, but by default they should benefit from it. Notarization is for life, not just first run.

Protections claimed by Apple include:

• code can’t create executable memory without it being associated with a code signature;
• when read from storage, all code and data mapped into the running code must match their code signatures;
• code which is modified in memory and doesn’t match its signature can’t be executed;
• protection from code injection and dylib hijacking.

Do your own apps need to be notarized too?

If you build your own apps, using Automator, AppleScript, another scripting system or even Xcode, you don’t need to acquire a developer ID, code signing certificate, and start notarizing them unless you provide them to others via the Internet. Catalina still runs apps which haven’t been notarized or even signed, including those built after 1 June 2019. But you may find them more complex to run, and they don’t of course benefit from any of new security protection unless they’re signed and hardened.

Apple has, though, announced that it intends that a future version of macOS (possibly 10.16) will not run unsigned code so readily. How that will affect those who build their own apps isn’t yet clear. Let’s get notarization sorted first.

One other factor which might have played a role in all this is the version of Xcode and its SDK which software is built with, but Apple doesn’t suggest anywhere that might be the case. It is of importance when considering Catalina’s new privacy protection – a subject I will cover here soon.

Thanks to Rosyna Keller @rosyna for corrections to the benefits of the hardened runtime given above, pointing out that these also apply to Mojave and haven’t changed in Catalina.