Dominating many Mac sites last week has been the leaked story about the division of Apple’s beleaguered camel app iTunes into separate media managers. Meanwhile, those who develop and manage macOS software were agonising over two far more consequential changes which Apple has all but confirmed explicitly: the loss of support for 32-bit software, and mandatory notarization. Before worrying about which apps will be playing our music and movies, perhaps we should be getting more concerned about which apps will even run on macOS 10.15.

What is most frustrating about the current situation is that it’s been obvious that both these changes were coming in 10.15 since WWDC ten months ago, although at that time Apple just referred to “a future version of macOS”. We have known all along that Apple intends that to be 10.15.

For many users, the most prominent problem with the loss of 32-bit software in 10.15 isn’t going to be with ailing apps, but QuickTime. In a sense, this is Apple’s choice. The move to exclusively 64-bit software has been steadily becoming inevitable, and Apple chose not to make a clear path for 32-bit QuickTime, making it hard for third parties whose codecs were engineered for it to look to their future.

I’m sure that Apple could have provided a bridge to maintain 32-bit support in 10.15 and beyond. My suspicion, though, is that its engineering effort at that level isn’t looking backwards at 32-bit Intel, but forwards to 64-bit ARM. If ARM-powered Macs are coming in the not too distant future, that’s where its compatibility work will be going.

Having made all this very clear ten months ago, you would have thought that by now every significant software vendor would have this under control. Amazingly, though, there are still an embarrassing number whose current releases remain 32-bit. There is simply no excuse, unless that vendor intends pulling out of the Mac market altogether.

The situation with regard to notarization is even worse. At WWDC in June 2018, ten months ago, Apple announced the availability of hardening and notarization. This was explained in the State of the Union, and later in Session 702, where Garrett Jacobson stated:
“Remember that signing issues, for now, will be warnings but are going to become errors in the future. And when macOS Mojave ships later this year, Gatekeeper will be highlighting notarized applications to users. But then in a future macOS release, Gatekeeper will be requiring notarized apps by default.”

Like King Canute sitting in front of the waves commanding the incoming tide to retreat, many software developers seem to have ignored that. I’m not referring so much to small, independent developers, but to huge and profitable companies like Adobe and Microsoft. Checking this Mac, for instance, the only apps here which are currently notarized are Carbon Copy Cloner, Hopper, TripMode, and my own. Far more expensive products such as Adobe Acrobat ‘Pro’ DC and the whole of Microsoft Office 16 aren’t notarized yet. Indeed, Acrobat ‘Pro’ 19 isn’t even built against 10.14, but 10.13 still.

The last few weeks have served to demonstrate that notarization isn’t as simple as it might seem. Apple has gone a long way to providing a fast, responsive service completely free of charge, and the standard workflow in Xcode for notarizing vanilla builds works excellently. But the more your app deviates from that, the more fragile it all becomes.

My greatest concerns are not with complex build-notarize workflows for commercial developers, who have time to get those workflows right, but for the non-commercial developer who simply shares a few scripted tools from their home page. Some are convinced that 10.15 is going to provide a way to accommodate those unsigned and unnotarized apps, but Apple hasn’t announced or documented that as yet. It would also be open to abuse, which could quickly bring the added protection of 10.15 into disrepute.

The strangest twist, though, has been Apple’s drive to get developers to notarize legacy products which aren’t hardened, and may even be unsigned, according to its latest documentation. This might appear to be a let-out for those non-commercial scripted tools, but can’t be performed (yet) by any friendly app, requiring use of Xcode’s command tools. How any users can put as much trust in an unsigned but notarized app as they should be able to in a fully signed, hardened and notarized app remains to be seen.

Apple has also brought forward the requirement for notarization of kernel extensions to macOS 10.14.5, which is probably only a month or so away. This strikes me as strange, given that kernel extensions are already the most tightly-controlled software in macOS, requiring special certificates and passing through additional security protection before they can be installed. This is already causing anguish to many system administrators, whose Macs are often dependent on key kernel extensions which will shortly have to conform to rules which no one was expecting to apply until the autumn at least.

So forgive me if I can’t get excited about whether 10.15 is going to have separate media managers and players. In any case, judging by Mojave, those new apps will be designed by the same school which brought us the new App Store app, News, and the like. iTunes may have been an ungainly camel, but it might yet look good by comparison.