I’d like to apologise to those of you who ended last week downloading two new versions of SilentKnight, instead of the one that I had intended. This article explains how the second came about.

SilentKnight is heavily dependent on discovering key facts about the Mac that it’s running on. One of the first it needs to know is whether it’s looking at a plain Intel Mac, one with a T2 chip, or an Apple silicon Mac, as that determines how it should go about checking which version of firmware it’s running, and much else.

Over the last five years, SilentKnight has relied on the command-line equivalent of the System Information app, system_profiler. Surprisingly that doesn’t have a single field that draws a clear distinction between those types of Mac. The closest it comes to doing that is the information shown for the Controller item, or
system_profiler SPiBridgeDataType
in Terminal:

• Intel Macs without a T2 chip return no information, as they’re not considered to have a controller in this sense.
• Those with T2 chips return a Model Name of Apple T2 Security Chip.
• Apple silicon Macs give the iBoot (or, from 26.4, mBoot) firmware version number.

While that has worked for five years, for SilentKnight version 2.13 I decided to slightly extend the text it looks for, to ” T2 ” to reduce the chance of false positives now that Apple silicon results are becoming more diverse. That worked fine on my two Intel Macs with T2 chips, but broke weirdly in a MacBook Pro tested by Jan, to whom I’m deeply grateful for the early report of this problem. Jan’s MacBook Pro was thoroughly confused, found and reported the correct T2 firmware but told them it should be running a more recent version of iBoot, for Apple silicon Macs.

It turned out that Jan’s MacBook Pro is running German as its primary language, so instead of reporting Apple T2 Security Chip in system_profiler it returned Apple T2-Sicherheits-Chip, and ” T2 ” couldn’t be found to confirm it wasn’t an Apple silicon Mac. The simple fix was to remove the trailing blank from the search term, which becomes ” T2″.

Although system_profiler can return its information in plain text, JSON or XML formats, its content is the same in all three, with localised text that’s dependent on that Mac’s primary language setting. Besides, its XML is exceptionally verbose, squeezing a few lines of information into 262. I was surprised by this five years ago, when I first came across it when trying to parse the list of Apple silicon security settings.

Here you can see those for a Mac using Dutch localisation. Instead of responses like
Secure Boot: Full Security
using Dutch for your Mac’s primary language turns that into
Secure Boot: Volledige beveiliging
When SilentKnight tries to work out whether your Mac is set to Full Security, that means it would have to look up the response in a dictionary containing every possible language.

Not only that, but these localised responses vary between different sections and data types.

The above responses to system_profiler with French set as the primary language demonstrate that has no effect on Hardware data, where core types are given in English, but changes those in Controller’s Boot Policy. To discover which change, you have to test with many different language settings, as none of this is documented, of course.

At that time I spent several days trying to get an unlocalised response by running system_profiler in an English environment, but that had no effect, and there was no way to bypass this localisation. As this language dependency limits the usefulness of the command tool, I argued that its output shouldn’t be localised at all.

Now, five years later, I have been bitten again, and apologise for putting you through two updates to SilentKnight when there should only have been one.

Previously

Bad design makes macOS a Tower of Babel

If you have been trying to use my free utility Providable on a non-English system and have been unable to get it to list apps installed there, you will want to download and use this new version 1.2, which should address that problem.

It’s available from here: providable12
and will shortly be getting its own place in a Product Page, and in Downloads above.

Just to demonstrate that Providable 1.2 does list apps correctly in non-English systems, here’s a screenshot of version 1.1 in the upper left showing no apps found, and 1.2 in the lower right with the three apps it should have identified. That’s in Tahoe 26.2 with Chinese set as the primary language.

The rest of this article explains why previous versions failed to list installed apps on non-English systems, why that has more general significance, and how it’s bad behaviour.

Listing apps

It’s curiously difficult to obtain a comprehensive list of apps installed on a Mac. If you look at proposed solutions, many involve iterating through popular locations such as Applications folders, or other time-consuming schemes. This turns out to be duplicated effort, as Spotlight already does that when indexing, and provides indexes you can search far more quickly.

The common recommendation is to use the mdfind command in the form
mdfind "kMDItemKind == 'Application'"
which should find all items that Spotlight has indexed as being of the kind Application. There’s an equivalent available in the Finder’s Find window that demonstrates how well this can work.

As Apple doesn’t appear to explain any further about how Spotlight classifies items into these ‘kinds’, it’s reasonable to assume they are categories with standard names, although that proves to be incorrect when you try the same on a non-English system. You then realise that a ‘kind’ is just an arbitrary string that may be localised. Run that command in macOS localised to Chinese, and you won’t find any Application at all, and when localised to Italian you’ll need to use Applicazione instead.

The textbook solution to localisation problems like this is to provide a set of localised strings, and to pick the correct one depending on the current localisation setting. That may work when you have specialist teams, and can achieve comprehensive cover of all the possibilities, but here it’s impractical, as it would be when writing a script that uses that search command. It’s much better to cheat.

The most obvious way around this is to use a criterion that’s localisation-invariant such as a UTI. You can then search for .app bundles with the UTI of com.apple.application-bundle. I was disappointed to discover that too isn’t as simple as it could be, as UTIs are available in kMDItemContentType, but according to current documentation that returns a complete UTI ‘pedigree’, for an app something like com.apple.application-bundle/com.apple.application/com.apple.localizable-name-bundle/com.apple.package. That may not be correct, though, as using mdls to list metadata shows that the full pedigree is given in kMDItemContentTypeTree rather than kMDItemContentType.

Preparing for both cases, the correct search command should then be
mdfind "kMDItemContentType == 'com.apple.application-bundle*'"

And that is exactly what Providable 1.2 does now.

Does Spotlight reindex when changing localisation?

My next question is what Spotlight actually indexes for kMDItemKind: is the string localised or not? As we don’t have direct access to those indexes, the closest we can come to inspecting them is by dumping metadata using mdls. Using Italian and English as my examples, when running with English as the primary language, kMDItemKind for an app is given as Application, but with Italian primary, it’s given as Applicazione instead.

This is the only metadata that appears localisation-dependent in this way, so either mdls is lying by returning a localised string, or Spotlight is rebuilding its index for kMDItemKind when the primary language changes. Neither behaviour is documented or expected.

Localisation overreach

This isn’t the first time that I’ve run into problems with localisation in command tools. If you use SilentKnight on Apple silicon Macs running non-English systems, you’ll be only too aware of my previous and apparently insoluble issue, where a major command tool can only return strings in localised form, effectively making their interpretation impossible. In that case it’s one of the many modules in system_profiler, returning key information about an Apple silicon Mac’s security status that isn’t readily available anywhere else.

Localisation is wonderful, and vital for many of us using macOS, but in some cases is now being applied too early. I wonder how anyone scripting with mdfind can possibly make use of kMDItemKind across different localisations. If its kinds were drawn from a set of non-localised strings, there would be no such problems. It makes good sense to localise the strings used in its GUI equivalent, but not for the command tool.

There are many examples of where localisation doesn’t take place, for example in UTIs, and in filename extensions. Can you imagine the consequences of localising the latter?

I’m very grateful to Hill-98 for helping me uncover these problems.