If there’s one quality we expect of our Macs it’s predictability. That doesn’t mean they can’t improve, but when they start to behave in ways that we neither expect nor want, we lose confidence in them. Learning their behaviour is greatly aided by their conforming to simple rules, among those being how apps can be run. We know that we can copy or move apps in the Finder, and wherever we move them to, we expect them to behave as before, and run when we want them to. But that’s no longer true, as they now follow complicated and largely unwritten rules.

Check mate

Let’s say I want a copy of the Chess app to run from an external drive. Instead of the Finder copying it to the drive, dragging the app there merely makes a Finder alias instead. If I copy it, when I try to paste it into that drive, that command isn’t available. Let’s say that somehow I do manage to copy the Chess app, and then try to run it, I’d discover that it wouldn’t run because its code signature is deemed to be invalid. Yet other apps in my Applications folder copy and run just fine, suggesting this behaviour may be random, or at least the result of unwritten rules.

Apple’s support documents aren’t any help either. Sonoma’s guide suggests this could be the result of incorrect permissions, but when I check those in the Finder’s Get Info dialog, I can’t see why the Chess app can’t be copied in that way.

Undeterred, if smarting slightly, I then download a third-party chess app, unZip it and move its folder into Applications. That behaves oddly, and can’t seem to update itself properly. Its developer helpfully explains that my Mac’s security requires me to move the app from that folder before running it, although I can’t find any support information from Apple telling me that.

When I come to install the updated version, as I have a couple of other downloaded apps to install at the same time, I drag the three apps together into the Applications folder, before copying that chess app to my external drive. But those three apps don’t seem to install properly, and none of them can update itself, but the copy I made on my external drive works better and updates automatically too.

This confirms my original suspicions: macOS behaves quite randomly at times, and I can well understand how some have become so critical. At least I’m spoilt for choice of apps supporting ChatGPT in the App Store. I wonder if any of them can explain how to run apps on macOS, and why my apps don’t appear to work properly.

The mess macOS is in

Of course you and I know better, that the behaviours described above are part of macOS security, and intended to protect our Macs from malicious software. Among those responsible are the Signed System Volume (SSV), introduced in Big Sur in 2020, launch constraints (Ventura, 2022), and app translocation (Gatekeeper path randomisation, Sierra, 2016).

One way to see how complicated this has become is to chart out how to run an app for the first time in Sonoma. For many years, the answer could be given in a handful of words: double-click the app. To perform this reliably now, without running the risk of problems, you first need to know whether the app is bundled with macOS (including Safari) or supplied from the App Store. If it is, then you can go ahead and double-click it, and it should launch without any problems.

This leaves those third-party apps that aren’t supplied through the App Store. For those, you need to know whether the app was copied from a signed disk image; if it was, then it shouldn’t cause any further concerns, and should launch and run fine. Apps that were supplied in Zip archives and other presentations are more tricky, as they’re liable to be translocated by Gatekeeper unless they have been handled correctly, according to rules that Apple doesn’t spell out anywhere.

This chart summarises the most common circumstances, although it doesn’t cover edge cases of presentations that you shouldn’t come across, such as unsigned disk images and installer packages, that may need special treatment before they can even be used to install an app.

Should good security impair usability?

Successful malicious software exploits weaknesses not only in code, but also in human behaviour. For over a decade, multiple malware posed as Adobe Flash Player updates, because the genuine Flash Player suffered a long succession of serious vulnerabilities and needed frequent updating. As users expected to be prompted to download and install yet another Flash Player update, malicious software seized the opportunity to satisfy those expectations with a malicious imposter.

Clean and highly usable human interfaces are harder for malicious software to exploit, as the slightest deviation from user expectations draws attention to their malicious activity. If a user is only rarely prompted to enter their password, then they’re more likely to consider a malicious request as suspicious.

Impaired usability therefore aids the malicious, and security protection that’s considered to be troublesome, such as app translocation, encourages some to deliberately bypass it, for example by stripping quarantine xattrs, or using transfer clients that don’t apply them. As the most popular means of distribution of malware already involve risk-taking and rule-breaking user behaviour, this should come as no surprise.

macOS is currently in need of substantial improvement to its usability, and a return to simple, consistent behaviours that conform to explicit and generally understood rules. That need not involve abandoning the great achievements of the SSV, Gatekeeper, or launch constraints, but improvements in their presentation using human factors.