By the time we get to the third release of each major version of macOS, we expect it to be fairly feature-complete with its most serious bugs fixed. In that respect, Monterey has fallen behind the cycle, as we saw last week in the 12.2 update.

Its most glaring omission is Universal Control, which I find heartening. Although the demos at WWDC last June were simply stunning, during the beta phase it became clear that what we had seen was far from ready for us to try. Rather than release something fragile and unreliable, Apple was prepared to give its engineers more time. From what I hear of those testing the first beta-release of 12.3, it looks as if it will be good for release in that next update, probably in April.

Shortly after I had updated to 12.2, I checked a couple of bugs which hadn’t been fixed in the previous update, and disappointingly discovered that they remain unchanged three months and two updates after Apple let them loose in 12.0.1.

The lesser of the two is so obvious that I couldn’t imagine any engineer or quality controller letting it past. It must plague tens of thousands of Apple’s own Macs, every few days reminding their users how inadequate its quality management is. I’m referring to the bug in the Bluetooth menu which can’t show a Magic input device’s charge when it’s being recharged.

Every time that I recharge either my Magic Keyboard or Magic Trackpad, I can’t tell whether it has reached full without taking it off charge. How obviously daft is that?

But we learn to live with such everyday annoyances. What I find unacceptable about Monterey 12.2 is that it still – three months and two updates after 12.0.1 – suffers a large and severe memory leak which is easily reproducible and renders a key feature in the Finder almost unusable. I explained this bug in detail in this article, and bwillius was kind enough to report it in Feedback on 22 November 2021, over two months ago.

Not only is this unacceptable in 12.2, but no release version of Finder should ever suffer such a reproducible memory leak. There is no excuse for this happening.

Reasoning what’s likely to be happening here suggests that there may be multiple problems involved. When one or more characters are inserted into the search box, a live Spotlight search is triggered. If just one character is inserted and the search covers This Mac, the number of hits is likely to be very large, even on a fairly minimal installation. Results arrive in the Finder over a period of many seconds, and its use of memory grows as it stores the results and builds them into the contents of its window.

If you then destructively backspace and type another single character, the first find should be terminated, its results discarded, and the new find initiated. What appears to happen is that the existing results are set aside, but the memory that they occupy isn’t freed. If the user continues to perform searches, that leaked memory accumulates without limit.

This is most noticeable with find operations that return a very large number of hits, such as those using a single character. If the characters entered in the search box result in less than about 1,000 hits, leaked memory is sufficiently small, around 5 MB, to have little impact on the total used by the Finder, unless a great many such searches are performed.

This still doesn’t necessarily make this a bug, though, as it’s plausible that the Finder retains those old find results for a purpose, even if it’s not immediately apparent. If that were the case, then the memory used to store those old results should be freed on closing that window, which it isn’t. Indeed, the only way to free that memory is to quit and reopen the Finder, which is disruptive to the user.

Memory leaks like this are well-recognised as common and serious errors, and any code review of the Finder conducted before release to beta should surely have picked this up. Even if that didn’t, this is exactly the type of bug which should be detected during testing before proceeding to beta. Xcode includes powerful tools to make this straightforward.

I don’t know whether this memory leak was reported to Apple during beta-testing, or soon after the release of 12.0.1, but we know that it was reported on 22 November 2021. Yet on 26 January 2022, Apple was content to release 12.2 knowing that this hadn’t been addressed, yet it didn’t provide any release note warning that there was still a severe memory leak in the Finder.

There’s stark contrast between Apple’s cautionary approach to Universal Control, delaying a major new feature until has been fully baked and thoroughly tested, and its lackadaisical treatment of Finder’s memory leak. I eagerly look forward to Universal Control and proper Bluetooth charge information in 12.3, and rather hope that Apple might see its way to fixing the Finder in 12.2.1, please?