It’s only when the hype of events like WWDC have faded and you get the chance to look at what is really happening that a bigger picture emerges. Last week this came with two of the more important announcements for macOS: notarization and SwiftUI. What they tell us about Apple is significant.

In principle, SwiftUI looks excellent. It’s a new declarative way of building the interface to apps, whether that build is going to run on macOS or any of the other operating systems in Apple’s growing stable. In essence, the programmer tells the runtime what they want, and leaves frameworks to implement that as appropriate to the platform. For an app which is going to run on two or more of those operating systems, that seems an excellent solution.

In Xcode, this isn’t just implemented in code, but you can use a graphical interface designer as well. Previously, there was a clear distinction between Interface Builder (IB) with its GUI, and interface objects created using code. The former are loaded in Storyboards and ‘nibs’ which Xcode creates from the windows, views, controls, etc., which you assemble graphically; the latter are compiled from source code files and only come into existence when that code is running.

The snag with SwiftUI at present is that, as far as macOS is concerned, it’s too incomplete to do anything useful. Most of my utilities feature, somewhere among their windows and views, a scrolling text view, in which results are displayed in text form. It’s one of the fundamental parts of the existing class library AppKit, but – for the moment at least – doesn’t exist at all in SwiftUI. So if I were to port any of my apps to the brave new interface of SwiftUI, in pretty well every case I’d have to embed at least one scrolling text view from AppKit. That’s fully supported, thankfully, but is it worth the effort of handling two very different interface class libraries with contrasting approaches?

The real sting comes in system requirements: the moment that you choose to use SwiftUI, your app can’t run on Mojave or earlier, it’s committed to Catalina. macOS users are generally rather slower to upgrade to the latest operating system than are iOS users. Read the comments to articles on this blog and you’ll find that there are plenty of advanced users here, with Macs perfectly capable of running Mojave, who are still running High Sierra or Sierra, and a few who are back on El Capitan or earlier. This isn’t because Mac users are stick-in-the-muds, but because many are in complex situations which have to wait for key software and other requirements to change before they can upgrade.

Assuming that half of you here were to upgrade to Catalina by the start of 2020, which could be optimistic, would I want to invest my time and effort into building apps which the other half couldn’t run until they too had upgraded?

If there were other compelling reasons to upgrade, as there are in Mojave’s much-improved APFS, maybe. But for most users, the major trade-off coming with Catalina is going to be whether its better security and speed outweigh the loss of all 32-bit software. I’m not convinced that will lure many to upgrade early. Are you?

That brings me on to two other concerns with Catalina and what we have been told about it so far: notarization and security.

The shock of WWDC 2019 was that, after Apple had already provided its first beta-release to developers, it was announced that all executable code including command tools would have to be notarized. We had been warned that apps had that requirement last summer, and many of us have been preparing diligently for that. But notarizing command tools isn’t just complex, it’s actually incomplete: there’s no way to ‘staple’ a notarization ‘ticket’ to a standalone Mach-O executable file like a command tool. Apple has implemented this requirement before its engineering solution has been made available.

There were other surprises in Apple’s announcements on security, including increasing use of malware scans to detect malware, even on apps and code which have been previously run and don’t have a quarantine flag attached. At present, the only tool in macOS which appears to perform those scans is XProtect, which has languished largely unattended for far too long. Rumours are that the equally-neglected malware removal tool MRT isn’t going to be part of Catalina, although no one has yet identified a likely replacement. Maybe both XProtect and MRT will be superceded during the beta phase, prior to Catalina’s first full release.

It’s this that forms the bigger picture: Catalina is looking good, but there’s a great deal which remains far from complete, rushed out for WWDC, and needs considerably more work before it’s going to be anything more than a taste of what’s to come. That includes SwiftUI for macOS, notarization for standalone code, malware detection, and of course Time Machine backups on APFS. I wonder how many of those we’ll have this time next year.

None of this is intended as any criticism of the many Apple engineers who have devoted so much time and effort to the development of Catalina. Your work and sacrifices are greatly appreciated. I’d also like to note that the originator of Xcode’s Interface Builder, Jean-Marie Hullot, died recently: we all owe a great debt to him for that and his other achievements for Apple.