If you’re intending to upgrade to Catalina, even early next year, perhaps, one of the first questions you need to ask is whether your important apps will run in macOS 10.15. In many previous macOS upgrades, this hasn’t been such an important question, and the answer has usually been far simpler. One of the problems with upgrading now is that some apps won’t just be a bit rough, but will stop working altogether when you upgrade.

Apps you’ve already run

When you’ve already installed and run an app, the situation is more clear, as it has already undergone that crucial ‘first run’ in which it undergoes full Gatekeeper checks, if it was downloaded from the Internet. Therefore the most important consideration is whether the app is fully 64-bit compatible.

Although tools like St. Clair Software’s free Go64 and my own free 32-bitCheck will scan for potential problems, the only app that I know which will test a specific app is my free ArchiChect.

The next question is whether the app runs fine on Mojave. If it does, and contains no 32-bit code, it’s looking good to go in Catalina. Unfortunately, there are still some pitfalls which can catch the occasional app. If it relies on a kernel extension, it’s possible that could cause problems, although once that’s been installed successfully that should be unlikely.

More worrying are some recent behaviours in which Catalina has taken exception to some third-party System Preferences panes, LaunchAgents, and other ‘executable’ files including scripts, according to reports from beta testers. This doesn’t appear to correlate with any of the announcements or details provided to developers at WWDC, so I’m unable to provide any advice on this other than to be wary and watchful.

New apps

Any app newly-purchased in the App Store should stand a very good chance of running properly in Catalina, although apps which haven’t been updated in the last year could still prove a problem because of straightforward compatibility issues. Apple stopped accepting new 32-bit apps for the App Store in January 2018, and all updates since June 2018 have been required to be fully 64-bit. Check the Version History and Compatibility information provided on the app’s product page.

Apps which aren’t delivered through the App Store are rather more complex to assess.

First, they still need to be completely 64-bit, something which should be clear from their website. If you’re unsure, download a demo version and drop it onto ArchiChect to find out. There’s no mechanism by which Apple can control whether Mac apps offered outside the App Store are 64-bit, so you may still find current versions on offer which won’t run at all in Catalina because they still rely on 32-bit code.

Next, they need to run fully in Mojave. If you’re able to try a demo out, that should help you decide whether they’re a bit wobbly in 10.14, thus more likely to run into trouble in 10.15.

The more complex issues revolve around Catalina’s security. If you’re going to download this app from the Internet, it will be given a quarantine flag, and when you try to open it for the first time, will undergo full Gatekeeper checks. That involves several distinct issues, starting with notarization.

Notarization has changed

Until a couple of days ago, the situation on notarization was fairly simple: apps signed (by the developer) before 1 June 2019 didn’t, in general, need to be notarized. If they weren’t, it shouldn’t have made much difference. However, any app signed using an Apple developer certificate after that date was ‘required’ not just to be signed, but to have been notarized by their developer. This doesn’t mean that you cannot opt to run unsigned code in Mojave, but that apps which had been signed previously were now required to be notarized as well.

Apple has offered two basic paths to notarization for developers: for earlier versions, signed before 1 June 2019, developers were encouraged to get a retrospective or historical notarization performed, but that was wholly optional, as users should still be able to install and run those apps in Catalina. For current builds, developers were asked to submit their built software to Apple for checking, and if it complied with their stringent rules on ‘hardening’ and signing, Apple issued a ‘ticket’ which could then be ‘stapled’ to the app or its installer.

A few days ago, this all changed. From early September until January 2020, Apple has removed those stringent rules: hardening is no longer required, and apps can even include components which aren’t signed by the developer’s own certificate.

Whilst Catalina does require developers’ apps to be notarized, that notarization can mean any of three different things:

• retrospective, on an old build which may be incompatible with Catalina;
• strict, on a current build which is likely to be compatible with Mojave and Catalina;
• relaxed (not hardened, etc.), on a build which could be incompatible with Mojave or Catalina.

So, although a new installation of a non-App Store app will need to notarized, notarization itself is not a good indicator of compatibility with Catalina. It’s also very difficult to discover whether an app is notarized (let alone under which class of notarization) using macOS alone. There are two good tools which can tell you this: Max Inspect from the App Store, and my own free Taccy from here.

It’s also worth noting that some developers have reported that apps which have been successfully notarized don’t always complete Catalina’s first run Gatekeeper checks successfully, and as a result Catalina may refuse to open them.

So has security

Another major change in late versions of Mojave and Catalina is additional stringency over kernel extensions, and, as I mentioned above, unforeseen behaviour with respect to third-party System Preferences panes, LaunchAgents and more.

In Catalina, newly installed kernel extensions are required to be correctly signed using a special certificate for the purpose, and then to be notarized. If your app relies on a kernel extension to function, its installer will need to cope with this, and the fact that, before that extension can be loaded, your Mac needs to be restarted. Some apps cope very well with this – a good example is Parallels Desktop 15 – but for others the interrupted installation could cause problems. And if the kernel extension hasn’t been properly notarized, you could find Catalina declining to install it at all.

Conclusions

Many good developers have put a great deal of effort into preparing their software for Catalina. These include many of the smaller ‘indie’ developers, and plenty of big names too. It’s heartening to see how many apps were notarized and ready to use before Apple’s recent changed notarization requirements.

However, others appear unprepared, with no useful information in their support pages about current compatibility or any plans. This may be a good time to re-examine alternatives which are clearly better-prepared.