For fifteen months, since its unveiling at WWDC in June 2018, Apple has been preaching the virtues of the improved security to come with notarization. Then in one short announcement to developers last week, it abandoned much of this grand plan until January next year, over a quarter of the way through Catalina’s release cycle.

The plan revealed to developers last year was simple and ambitious. From a future version of macOS onwards, there would be two ways for third-party developers to distribute their software:

• through Apple’s App Store, which requires sandboxing and imposes strict limits on what apps can do;
• independently, which will require every app to have additional limitations known as ‘hardening’ as well as complying with much stricter rules on signing of code, and for Apple to check every app for known malware through its free Notary Service.

Although Apple provided good tools for those with simple build workflows within its Xcode SDK, many independent developers don’t use Xcode, and discovered that the command line tools didn’t integrate well with their workflows. In some cases, code signing requirements have proved impossible to achieve. For example, I’ve heard from developers whose code integrates with cross-platform apps which will never be signed, let alone notarized, who have just hit a brick wall in their search for solutions.

Even what should have been simple tasks such as notarizing a command tool have become complicated because, well over a year since notarization was introduced, Apple still hasn’t worked out how to ‘staple’ the ‘ticket’ to a single file of executable code, which is something of a fundamental feature.

One underlying issue is that notarization doesn’t affect any of Apple’s own software products. They’re signed using Apple’s certificates, which exempt them completely. So hardly any Apple engineer knows what it’s like to prepare complex software and get it notarized. Indeed, there are times when I wonder if Apple realises how many developers don’t use Xcode at all.

Earlier this year, Apple introduced another form of notarization which it encouraged developers to use for existing releases of products, which I’ll refer to here as ‘legacy notarization’. The idea was to submit previous releases of your products to Apple, so that they could be checked for malicious software, and awarded notarization ‘tickets’. This seemed a bit odd, as it now meant that there’d be two types of software going around with their tickets:

• software which had been thoroughly signed according to stringent rules, hardened, and submitted to Apple’s Notary service;
• older software which wasn’t signed to the same standards, wasn’t hardened, but had been checked by Apple for malicious code.

The presumption was that newly-built and -signed products wouldn’t fall into that second class of legacy notarization, which seemed fair enough, as many of the latter wouldn’t even support recent features such as Dark Mode, and may not be particularly compatible with Catalina anyway.

Then Apple changed its mind again, and on 3 September, only 3-4 weeks away from the release of Catalina, it suddenly announced that developers could submit almost anything for notarization, including apps which weren’t hardened, didn’t comply with the signing requirements, and more. This creates a third class:

• software which doesn’t conform to the original rules for notarization, but which has been checked by Apple for malicious code.

In one announcement, Apple blew away previous claims as to the importance of satisfying the requirements which had been giving so many developers so much trouble over the last year or more. And those requirements aren’t going to be re-imposed on new notarizations until January of next year. I’m sure that the many developers who have struggled to ensure that the entire contents of their app bundle have been correctly signed using their developer ID and have been hardened are delighted to know that, had they waited until the last minute, they wouldn’t have needed to bother.

Short of abandoning the requirement for notarization altogether, at the last minute Apple has signalled that its only real value is in its own malware checks. Maybe all the rest, the advantages of the hardened runtime, of deep code signing, were nothing more than security theatre as some have claimed?

So why this sudden about face?

The most likely answer must be in non-compliance. Imagine if Apple were to know that, of the many (hundreds/tens of) thousands of third-party apps for macOS which aren’t distributed through its App Store, only a small proportion had been notarized? Or, even more importantly, if some major developers weren’t going to be ready to notarize key products until well after the release of Catalina?

For those of us who now realise that we’ve been suckered for the last year, this doesn’t build confidence. I take no comfort in knowing that, come January next year, my apps will be well-prepared for notarization becoming serious again. And we all know now that installing a notarized app means precious little, other than the fact that Apple has checked it for malware and didn’t find any. Does that alone really mean much in terms of security?

Despite this, I remain committed to notarizing all my apps which you might want to run on Mojave or Catalina. I will also help you distinguish between those apps which are properly hardened and notarized under the original strict rules, and those which have been notarized only by virtue of not being known malware.

It’s only appropriate that January is the traditional season for pantomime. I think by then we’ll have earned our places in the front row of the Security Theatre.