Which do you prefer: a vivacious sketch of a landscape dashed off in an hour, or the painstakingly polished painting with the finest detail captured to perfection? What you’re getting in macOS is increasingly like that sketch, and not so finished in its detail.

Last week this hit home when I stumbled across a family of buglets in handling Finder Aliases. The biggie is serious, and will freeze the Finder in circumstances which are by no means uncommon. But alongside it there are two other bugs which you’re less likely to bump into. Chances are that those two will never be fixed, except by eventual replacement.

The serious bug means that the Finder can’t properly handle Aliases to folders which have become broken. Select such an alias in a window which doesn’t try to list the linked folder’s contents, and nothing seems wrong. If you use Column view instead, when trying to list that folder’s contents, after a few seconds grace, the Finder becomes unresponsive. You then have to press Command-Option-Escape and force the Finder to relaunch.

Next to appear, and apparently going back before Mojave, was a tendency for Finder windows to close abruptly when handling the dialog to delete or fix a broken alias. This isn’t as consistent, but trying to open a broken Alias produces a dialog offering you a choice of three buttons, to delete the broken alias, to fix it by finding a new target for that alias, or to dismiss the dialog. Choosing the latter is likely to close the window, which isn’t intended.

The third is more arcane, very unlikely to occur in normal use, and highlights a shortcoming in design. It’s possible, if you’re very careful, to ‘spoof’ a Finder Alias to point to an identically-named file which is different from the original. But when you select that Alias in the Finder, because it normally caches both thumbnails and previews of files, QuickLook may not recognise that the target document has changed, and display the original instead.

What is important about these three bugs is that none affects the core feature which resolves an Alias. Anyone claiming that this phenomenon is ‘core rot’ should reconsider that term, as the great majority of bugs in Mojave don’t affect its core functions. The end result is not deterioration in macOS itself: after more than three months working in Mojave’s release versions, overall it is the best version of macOS that I have used since before El Capitan.

Your mileage will, of course, vary. But my newish iMac couldn’t run El Capitan for longer than a few days without freezing completely in a kernel panic, it had to be restarted every week or two in Sierra because it stopped making Time Machine backups, and its Fusion Drive couldn’t run High Sierra’s APFS at all. For all its surface blemishes, Mojave has been a walk in the park.

Given the sheer size and complexity of macOS with all its supporting components and libraries, is it realistic to expect it to ever become free of noticeable bugs? We don’t have figures for macOS, but when Linux kernel 1.2.0 was released in 1995, its source was a little more than 300,000 lines. Last September, the source code of version 4.14.14 was estimated to contain over twenty million lines, and would have cost more than $14 billion to rewrite.

Our expectations of software haven’t changed, though. We judge by comparison with far simpler products, such as apps, consumer goods, and cars. Although these might seem complex, a better parallel would be a sizeable city. At any given moment, there will be buildings in disrepair, potholes in the roads, and dysfunctional zones. Some we even view as quaint or atmospheric because of those flaws, much as in the aesthetics of the painterly sketch.

I’m not advocating acceptance. Where apps are severely dysfunctional, as the App Store is in Mojave, we need to tell Apple that they need substantial further investment. When Photos was first released, it was shockingly underpowered and unreliable, but has steadily evolved into an app which many of us trust with tens of thousands of our images. It’s still far from perfect, and I regularly recommend those who are pushing it to its limits to consider alternatives, but Photos has gone from weed to staple.

A large part of the problem is the annual development cycle for macOS and iOS, but that is also their salvation. When Apple gets it right, troubled apps and components within macOS will be re-engineering in the next cycle, and most of those old problems should disappear – some to be replaced by new bugs, inevitably.

The biggest difference between macOS and a city is our insight into what’s going on with the latter. Before an area is redeveloped, plans are put before the public and debated. When work starts, we can see what is going on, and follow it through to the finish. At present, all those using Time Machine know that it needs to be revised to make its backups on APFS volumes, in what I have dubbed Time Machine 2.0. We have no idea whether Apple’s engineers are tackling that yet, or when it’s likely to appear in macOS.

Some changes coming in the future, such as loss of 32-bit support, have been announced, but we’re not told of when they will happen, nor whether macOS will offer any option to be able to run 32-bit apps in the future. Any city planner doing the same would face public outrage.

The closest that we get is the annual WWDC at the start of June, although it places greatest emphasis on introductions rather than redevelopment. Wouldn’t it be good if Apple spent more time and effort showcasing more of the efforts of its engineers in revising and improving existing areas within its operating systems? We know, for example, that many components have been ported to use Apple’s new lingua franca Swift, an investment which Apple should be as proud of as it is of new features.

In the nineteenth century, the Impressionists and others convinced the public to pay for sketches which in previous eras wouldn’t have left their studio. It was a major change in aesthetics, something which Apple could achieve with macOS too.