If you read Apple’s latest article about notarization of software, you could be forgiven for assuming that the ominous words “in a future version of macOS, notarization will be required by default for all software” apply to macOS 10.15. If that were literally true, the problems brought would make dropping 32-bit support look trivial in comparison.

If you want to take a quick look at how few apps are currently notarized, and Xcode installed with its command tools, open Terminal and run this little script, written by @tperfitt at Twocanoes Software:
for i in /Applications/* ; do stapler validate "${i}"|grep -B 1 worked;done

Thanks to Al (in his comment below) for providing a version for those who don’t have Xcode installed, but do have its command tools:
for i in /Applications/* ; do /Library/Developer/CommandLineTools/usr/bin/stapler validate "${i}"|grep -B 1 worked;done

Unfortunately, there isn’t an equivalent tool bundled with macOS Mojave itself, although you can inspect signatures using spctl, something which my free app Taccy does.

That should list all the apps in your Applications folder which are currently notarized. In many cases, you’re likely to find less than half a dozen, and those from major vendors such as Adobe and Microsoft won’t be among them. What if some of the tools you have are your own apps and scripts: how on earth are you going to keep them running in macOS 10.15?

Of course, the answer is that Apple’s words are quoted out of the context of the rest of that article, which is aimed at developers who distribute their apps over the Internet, outside the App Store. If they’re not responding now and getting their apps notarized, then they may have a problem when 10.15 arrives. But recall my summary of a couple of days ago:

• Notarization is only checked when you first run an app which has been downloaded from the Internet and has gained a quarantine flag as a result.
• None of this affects your existing apps, provided that they have already been run, even if migrated from an older Mac.
• This affects apps and executable code bundles, including kernel extensions, but not command tools, nor apps installed from the App Store.
• This also affects updates to existing apps and kernel extensions which are downloaded from the Internet.

So if you’ve got folders full of your own apps which haven’t gained a quarantine flag because they weren’t downloaded from the Internet, or which have already cleared quarantine following download, they will continue to open and run fine in 10.15. Apple hasn’t announced that it’s changing the way that Gatekeeper works, and if it were even to consider that, the penalties would be seismic.

That does, though, leave many wondering how they’re going to be able to share tools as they have in the past. Unfortunately, the news for them isn’t good at all. If you want to make such apps available to others via download, the only way that this will work in 10.15 and later is for you to go through the whole process of signing them with a developer ID and notarization. Probably.

I write probably because Apple’s article glosses over many issues, some of which surfaced in exchanges of tweets with @tperfitt, Jeff @lapcatsoftware, Michael Tsai @mjtsai and others, and some live experiments by them. This concerns the apparent contradictions in Apple’s instructions in the section headed Prepare Your Software for Notarization, notably:
Apple’s notary service requires you to adopt the following protections:
Enable the Hardened Runtime capability for your executable targets
and
Apple recommends that you notarize all of the software that you’ve distributed, including older releases, and even software that doesn’t meet all of these requirements or that is unsigned.

How on earth can an app be hardened, something only available in recent versions of Xcode, to meet the first requirement, but remain unsigned?

The answer seems to rest in what built the app in the first place. If the app declares that it was built using a recent version of Xcode, which supports hardening and notarization, then the latter will expect it to comply with the new and rigorous rules, including code-signing and hardening. If your app is built with an older version of Xcode, or a different tool, then legacy rules apply, as described later in that article.

The problem with trying to get an app notarized under the latter legacy rules is that you can’t use the sleek and simple process built into Xcode 10, but must use its command tools instead. Apple’s account seems fairly straightforward, but Rich Trouton gives a fuller account from his recent experience in notarizing some Automator workflows. But don’t worry: you’ve got this to look forward to every time that you build a new release version!

There is another catch in Apple’s glib recommendation “that you notarize all of the software that you’ve distributed, including older releases” which you should think through carefully. I have been progressively notarizing my free apps here since 1 August last year. If I were to notarize old versions from before that date, as Apple recommends, would I really want users downloading, installing, and trying to use those old versions in macOS 10.15?

If you’re still distributing apps which were last built before the introduction of notarization, you might like to think about whether they would benefit from a fresh build for 10.15, and use your time notarizing that instead.

Postscript

Another valuable resource for those struggling to integrate notarization into their workflow is Twocanoes Software’s account here.