Since the first of June this year, all newly-built apps supplied by developers outside the App Store have been required to be notarized. Although this may not have had as much impact on those using Mojave, notarization is going to be even more important in Catalina when it ships in the next few weeks or so. This doesn’t mean that you won’t be able to run apps which haven’t been notarized – you will still be able to run those which haven’t been signed at all – but any that you download from developers should be now.

Notarization brings with it two main benefits: to be notarized, the app’s developer has to submit it to Apple, who check it for malware. When you first run any notarized app you see a dialog informing you of that check. The other key requirement is that the app has been ‘hardened’. This involves a series of restrictions being placed on that app, which are intended to protect that app’s runtime integrity from certain types of exploits used by malware. These include code injection, the hijacking of dynamically-linked libraries (DLLs), and tampering with the app’s memory space.

For the great majority of apps, hardening causes no conflicts, but for some, such as those which rely on JIT compilation, or unsigned plug-ins or frameworks, hardening would prevent the app from doing its job. So Apple permits developers to opt in to relaxing some specific features of hardening when the app needs to.

Apps also now have to obtain entitlements for them to access protected resources such as your Mac’s camera and microphone, and private databases such as your calendars and address book. These are included in the options for hardened apps.

Developers, and users who are interested in discovering more about how this operates, should read the new documentation provided by Apple. This explains each of the options in detail, and suggests alternative solutions which could ensure more complete hardening.

For the majority of Mac apps, hardening and notarization aren’t onerous. Some builds take a bit of work to get them set up properly so that notarization is successful. I found this getting command tools notarized, but once I had worked out my workflow and run it a couple of times, the effort required to repeat it is fairly low.

Fears about Apple using this as some form of app review, as in the App Store, have proved unfounded, as have delays in waiting for notarization to be completed: the process normally only adds a few minutes to the preparation of each public release. We must hope that Apple has made this security call right, and that hardening and notarization prove beneficial to users, which is after all why we’re doing it.