This is the time of year when macOS keeps offering you the upgrade to the new version of macOS, but you may not want to go there yet. This article explains how you can stay running your existing version of macOS, while keeping it up to date.

Skint and SkintM

By default, SilentKnight is intended to download all the latest updates from Apple’s software update servers. Although you can configure it to behave differently, as I explain below, you may like to look at Skint or its menu bar sibling SkintM. Those don’t check for updates, they only check installed versions. They will warn you when your Mac has fallen behind with updates, and let you decide what you want to do.

Skint and SkintM do check that your Mac is running the latest version of its major release of macOS, and is happy if you’re still running Monterey, Ventura or Sonoma, as well as Sequoia, but it will advise you when they fall behind with their security updates; after all, that’s what it’s for.

Switching SilentKnight to manual

For many, SilentKnight’s button to Install all updates is most worrying, as that might inadvertently upgrade macOS to Sequoia. In fact, it isn’t dangerous at all, but before I explain why, you can remove that button altogether. Open SilentKnight, and its Settings, and set them to look as below.

This will still download and install the updates you want, but you won’t be tempted to inappropriately install the lot of them.

Once you’ve done that, click the Set button, quit SilentKnight, and run it again. Now when it tells you there are updates to be installed, you can’t click on a button to bring upgrade disaster.

In fact, after testing SilentKnight with macOS updates and upgrades, they don’t work like that anyway. If SilentKnight were to download a macOS update or upgrade, it can’t complete its installation. macOS first tells you that the update couldn’t be installed, then offers to install it in Software Update. All you have to do is shut your Mac down at that point, then start it up in Safe mode and the update will be stopped.

However, for your comfort and safety, I recommend unticking Allow Install All Updates, just in case.

Installing only the updates you want

Having avoided the update you don’t want, you now need to download and install those that you do. Scroll the lower text view to the bottom, to reveal all the updates available. Each has an opening line that declares it’s a Label, like
* Label: XProtectPayloads_10_15-142
It’s that label you use to identify each update.

In the File menu, select the Install Named Update… command to open the manual updating window. One by one, copy and paste the label from the main window into the Name of update box and click on the Install Named Update button. SilentKnight will then tell you that it has been downloaded and installed. It only takes a few seconds to work through a list of updates like XProtect that you do want, and bring your Mac up to date without inadvertently upgrading it to Sequoia.

Further information

SilentKnight has a wealth of additional information that will help you solve problems like these. The most common are explained in its short text SilentKnight Help, in the Help menu, and there’s also a detailed Help Reference in the same menu.

Key points

Open Settings, and untick Allow Install All Updates, click Set, then quit the app. Open it again, and install each named update one at a time using that command in the File menu, pasting the Label in for each wanted update and clicking the Install Named Update button for each.

This assumes that you are running the latest version of SilentKnight, 2.11. If you’re still running version 1 you need to update for Catalina or later.

Many of you still seem puzzled as to how XProtect installs and updates in macOS Sequoia. This article tries to make this clear, so you can keep XProtect up to date.

Sonoma and earlier

Until this changed in Sequoia, XProtect has been straightforward: its data is stored in a bundle named XProtect.bundle, in the path /Library/Apple/System/Library/CoreServices, which is on the Data volume so it can readily be updated. When you or macOS downloads an XProtect update, it simply replaces that bundle with the new one. This is shown in the diagram below.

Sequoia

XProtect in macOS 15 prefers not to use the XProtect.bundle in its old location of /Library/Apple/System/Library/CoreServices (although it can do if there’s no alternative). Instead, it looks for XProtect.bundle in its new location, /var/protected/xprotect.

However, when you or your Mac use the old update system, including Software Update, softwareupdate or SilentKnight, that still installs the update in the old location, where it won’t normally be used by XProtect when making its checks. What’s supposed to happen is that at least once a day, macOS checks whether there’s a newer update in the old location. If there is, then it should automatically prepare and move that to the new location in /var/protected/xprotect for XProtect to use.

If you want that to happen immediately, then you can run the following command in Terminal:
sudo xprotect update
then enter your admin user’s password. The xprotect command tool will then complete the installation of that update from its old location in /Library/Apple/System/Library/CoreServices into its new location in /var/protected/xprotect.

There’s also a second way that XProtect in Sequoia can be updated, and that’s over a connection to iCloud. If that’s used, then the update is installed straight into its new location, and doesn’t change the XProtect bundle in the old location at all. Although Apple has used that earlier, all XProtect updates since the release of Sequoia have come using the old Software Update system, so have needed to be completed using the xprotect command in Terminal.

This is shown in the diagram below. The blue boxes show the old Software Update system, and the pink boxes are the new parts that ensure the update is installed in the new location.

SilentKnight

SilentKnight still works using softwareupdate, and can’t use the new xprotect command for updates yet, because that requires structural changes in the app that will be available in version 3. However, in Sequoia it reports the version of XProtect installed in the new location, as that’s the one that XProtect now uses.

When SilentKnight discovers a new version of XProtect via softwareupdate, it therefore installs that in the old location, in the path /Library/Apple/System/Library/CoreServices. It has no choice but to do that. Once that’s been installed to the old location, the version shown for XProtect won’t change, as that requires macOS to complete the second stage of the installation. You can then either:

• leave macOS to complete the installation itself, which should happen over the next day or so, or
• run sudo xprotect update in Terminal, which will complete that update immediately. SilentKnight will then show the updated version number correctly.

Key points

In Sequoia, when XProtect is updated by Software Update, softwareupdate or SilentKnight, you should either leave macOS to complete that installation, or run sudo xprotect update in Terminal if you want it to be updated immediately.

This only applies to macOS Sequoia: Sonoma and earlier still work as they always have done.

One of my greatest regrets in life is that I never invested in a stock of cards with just four words on them: I told you so. Although I’m often wrong, when I see an obvious problem on its way, it’s disappointing how often it’s ignored. Instead of last week being all about Sequoia, I ended up spending most of my time trying to discover what the hell was going on with XProtect and its updates.

My feeling of unease started before last weekend. My fourth and last-ditch fallback Mac is a lovely MacBook Pro 16-inch 2019. It doesn’t see much use, so in the days before the release of Sequoia I charged it up and updated it to 14.6.1. It was still running an old version of XProtect, 2195 from the end of May, so I was surprised when it didn’t update XProtect, and no update was offered. At roughly the same time, my MacBook Pro M3 Pro running 15.1 beta updated from 5272 to 5273, and other beta-testers reported the same.

Bearing in mind that Apple had told nobody what was going on with XProtect or its updates, when last Monday came and my three other Macs that had been running 14.6.1 were upgraded to 15.0, I was still none the wiser. As with everyone else upgrading to Sequoia, any existing XProtect bundle was ignored by the new version of XProtect, and when asked what version of its security data it was running, it replied 0 (zero), indicating that it had no such data. That was a surprise to many, and something not anticipated by any information from Apple.

If you weren’t using SilentKnight, you’d then have to guess either that macOS would somehow fix that before you ran any newly downloaded apps, or that there would be a new command tool named xprotect, whose man page also doesn’t provide any guidance as to what to do.

For those who checked their new Sequoia installation with SilentKnight may have been just as surprised to see the XProtect version of 0, but at least they were guided to run the xprotect command tool, and force an update. Even then, confusion reigned when some Macs were updated to 5273 while others were left at 5272. Either has got to be better than 0, though.

Meanwhile, those who had updated to 14.7 or 13.7 got no XProtect update at all. If those Macs had already installed 5272, then that’s where they stayed, with no sign of 5273, which appeared exclusive to those who had ventured up to Sequoia. But if those Macs were still using an older version of XProtect’s data, there was no update available to take them to 5272, which others had installed when it had been released at the end of last month (28 August).

By the end of the following day, 17 September, this was the state of play with XProtect data:

• those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273;
• those running Sonoma 14.7 or any earlier version of macOS could have 5272 if they had updated before 13 September, or any older version if they hadn’t.

Then late on 17th, or early on 18th depending on your time zone, everything changed again. Apple’s software update servers started offering 5272 to everyone, and as an added bonus, those running Sequoia might also be offered 5273, although the new iCloud update service seemed content just to offer 5272. Within 24 hours, Apple released yet another XProtect data update, to version 5274, only this time it wasn’t made available to Macs running Sequoia. By the end of 18 September, the state of play had changed to:

• those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273, but not 5274;
• those running Sonoma 14.7 or any earlier version of macOS could have 5274 if they had updated on 18 September, or any older version except 5273 if they hadn’t.

Does any of this make a difference, though: just what came in the updates to 5273 and 5274?

For Macs running macOS Sonoma or earlier, 5274 is just a renaming exercise, and doesn’t materially affect XProtect’s ability to detect malware. Perhaps it was a placebo after all.

The new Yara definitions added to 5273 are very different, though. As I described in my announcement here: “This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.” Here’s a short excerpt:
rule XProtect_MACOS_SOMA_CT
{
meta:
description = "MACOS.SOMA.CT"
uuid = "DA584E59-A152-4E5B-A906-D354144DCA69"

condition:
hash.sha256(0, filesize) == "59e01f6f925af0643f4751191d28eab11ffb014412cd66ece8e5c77ba082977a" or
following which are a further 3,123 hashes, whereas MACOS.DOLITTLE.CT has just six.

Clearly, Sequoia’s XProtect is quite a different beast from that in Sonoma. It looks like Apple has forked XProtect data files, the Yara definitions in particular. It’s now likely that each future XProtect data update will either be destined for Sonoma and earlier, or specifically for Sequoia. Keeping them in the same version numbering sequence is only going to lead to greater confusion, unless Apple only intends releasing further updates for macOS 15 and later.

As Apple continues to provide absolutely no information about this, I fear that we’re just going to be left stumbling on in the dark, wondering what’s going on with one of the primary security defences in macOS. It must be time to order a new batch of I told you so cards.

Apple will release macOS 15.0 Sequoia on 16 September, that’s next Monday, alongside iOS and iPadOS 18.0, and upgrades and updates for lesser mortals. Among the latter are Sonoma 14.7 and Ventura 13.7, as I’ll explain later. Sequoia introduces two important changes to security data checked and updated by SilentKnight, for which I have built and notarized another new version of that app, 2.11, which is essential for anyone intending to upgrade to Sequoia, and worthwhile for all running Catalina or later.

What’s coming next week

Apple has just provided release candidates for the following three new versions of macOS:

• Sequoia 15.0, its first full release,
• Sonoma 14.7, its first security-only update,
• Ventura 13.7, the first of its security-only updates for its final year of support.

There’s not expected to be any update to Monterey 12.7.6, which is no longer supported, even with security updates.

The minor version numbers of Sonoma and Ventura will then be the same, the first time this has happened. In previous release cycles, the start of the first year of security-only updates has been with x.6, as it was with Ventura, and proceeded through the year with versions x.6.1, x.6.2, and so on. Over the coming year, we can expect 14.7.1 and 13.7.1, then 14.7.2 and 13.7.2, continuing until Ventura reaches the end of its third and final year of support in a year’s time.

Sequoia 15.1, the first release with AI support, is now expected in October, and continues in beta-testing, alongside AI-enhanced versions of iOS and iPadOS in versions 18.1.

TCC in Sequoia

The TCC database in /Library/Apple/Library/Bundles/TCC_Compatibility.bundle was introduced in Mojave (when it had a different location, of course), and has been updated with each new major version of macOS since. That has now vanished, and I can find no trace of it, nor any apparent substitute. If you run SilentKnight 2.10 in Sequoia, that will be reported as an error, so version 2.11 addresses that by omitting that result both from its display box and the text report below.

XProtect in Sequoia

Since it was first introduced many moons and versions of macOS ago, there has been a bundle named XProtect.bundle in CoreServices, most recently in the path /Library/Apple/System/Library/CoreServices/XProtect.bundle, that has provided data for XProtect scans of executable code and other security services. That bundle has been updated frequently in downloads labelled XProtectPlistConfigData. Although that can still be present in Sequoia, XProtect now uses a completely different source for its data, that is normally updated through iCloud’s CloudKit rather than Software Update.

The result is that your Mac can have an up-to-date XProtect.bundle in the normal location, but XProtect itself may not be up-to-date at all. For example, in fresh installs of Sequoia, XProtect.bundle is usually absent, and the new tool to check its version may report a number of 0.

SilentKnight versions 2.10 and 2.11 have been updated to cope with this major change, which Apple has apparently not seen fit to document (yet). They check the correct current version using a new command tool, and report that version number faithfully. At present, though, SilentKnight isn’t able to update this new form of XProtect. You can either leave macOS to do that itself in its own time, or you can run a command in Terminal to force the update immediately:
sudo xprotect update
following which you’ll need to authenticate with your admin user password.

I intend to address this more completely in SilentKnight version 3, but for the time being this is fully documented in SilentKnight’s Help book and Help Reference, in these latest versions.

SilentKnight, Skint, SystHist, LockRattler

SilentKnight version 2.11 is strongly recommended for anyone intending to update to Sequoia this year, and, as it also fixes a bug in reporting Studio Display firmware in VMs, is worthwhile for those remaining with Sonoma for longer. It’s available from here: silentknight211
from Downloads above, on its Product Page, and through its auto-update mechanism.

Thankfully, as Skint doesn’t check TCC, the current version 1.08 remains fully compatible with Sequoia. The current release of SystHist, 1.20, works well with Sequoia too, and usefully distinguishes between the two different types of XProtect update, XProtectPlistConfigData delivered through Software Update, and XProtectCloudKitUpdate the new one obtained through iCloud instead.

I don’t intend to update LockRattler for the time being. It won’t report the true version of XProtect, but does report that it can’t find TCC or the GKE data. Otherwise it should continue to function as expected in Sequoia.

More to come in Sequoia 15.0

These changes to XProtect are but one of the significant changes that Apple hasn’t yet mentioned. Once 15.0 has been released, I’ll be delighted to provide fuller details of others.

Summary

• On Monday 16 September, Apple will release macOS 15.0, and security updates 14.7 and 13.7.
• Monterey is no longer supported.
• Download and install SilentKnight 2.11 if you’re intending to upgrade to Sequoia this year.
• Skint and SystHist remain fully compatible with Sequoia.
• Watch here for further news on Sequoia once it has been released next week.
• Sequoia 15.1 with AI will be released next month (October).

Every autumn/fall, the current version of macOS changes, and with it there are changes great and small that can affect the apps we run. If you use any of the free apps that I provide here, now is the time to check that you’re running the correct version to support both your current macOS, and any that you might aspire to in the coming months.

SilentKnight

Although most of my apps have auto-update mechanisms that inform you when their updates are available, there are some notable pitfalls that can lull you into a sense of false security. Most importantly, SilentKnight was upgraded to version 2 two years ago to ensure its compatibility with Catalina and later. Every few days I come across someone who is still using version 1 with a newer release of macOS and seeing incorrect results. If you use SilentKnight in any version of macOS from Catalina onwards, then please ensure that it’s updated to the current version 2.10:
SilentKnight 2.10 (Universal App for Catalina to Sequoia)

This is particularly important if you intend upgrading to Sequoia, because of the changes it brings in how XProtect is updated. If you’re still running 2.9 or earlier, then SilentKnight will give you incorrect versions for XProtect, and at worst could report a version of 0 (zero) as it might not be able to find XProtect at all.

Skint and SystHist

For the same reason, Skint should be updated to version 1.08:
Skint 1.08 (Universal App for Monterey, Ventura, Sonoma and Sequoia only)

SystHist lists full system and security update installation history, a task that invariably requires an annual update to cope with the quirks of the new version of macOS. If you’re aiming for Sequoia at some stage, ensure that you have updated it to version 1.20:
SystHist 1.20 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Writing Tools

Although Apple isn’t intending to release any of its new AI features in the initial version of Sequoia, 15.0, but is delaying them for 15.1, you might like to prepare for that by updating my rich text editor and PDF viewer in advance. Their latest versions should prove fully compatible with Writing Tools when they’re released.

DelightEd is a Rich Text (RTF) editor with special Dark Mode features and support for interlinear text, and version 2.3 should work fully with Writing Tools:
DelightEd 2.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Podofyllin is a lightweight PDF viewer (without any editing capability, so it can’t alter original PDF files) and shows source code and more. Version 1.3 should work fully with Writing Tools:
Podofyllin 1.3 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

XProCheck, Nalaprop, Precize

Other recent updates you might have missed include the following.

XProCheck to check on XProtect Remediator scans completed and reported in the log:
XProCheck 1.6 (Universal App for Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Nalaprop for multilingual natural language parsing, now compatible with Writing Tools:
Nalaprop 1.3 (Universal App for Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Precize, which looks deep into files, bundles and folders to show their full size including extended attributes, provides macOS Bookmarks and volfs paths as enduring file references, and detailed information contained in Bookmarks and Aliases:
Precize 1.15 (Universal App for High Sierra, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia)

Key points

• For Catalina or later, particularly Sequoia, use SilentKnight 2.10.
• For Sequoia in particular, use Skint 1.08.
• For Sequoia in particular, use SystHist 1.20.
• Older versions of those apps will give incorrect results when run in more recent versions of macOS.

Although we won’t know for sure until Apple releases the upgrade to macOS Sequoia next month, once again it will probably be presented as an update rather than a macOS upgrade. This means that, instead of Software Update downloading a complete Sequoia installer app, if you do choose to upgrade, it will be run through Software Update the same way that it might have updated from 14.5 to 14.6.

Although this is more efficient, resulting in a smaller update and faster completion, it also opens up the possibility of human error: what if you accidentally opt to upgrade, or click on SilentKnight’s Install all updates button? This article explains how you can stop that upgrade from completing, and how you could upgrade using SilentKnight instead of Software Update.

Updating or upgrading macOS

When SilentKnight has completed checking for updates, if there’s a macOS update or upgrade available you can install it if you wish, from within SilentKnight. Although my personal preference is to hand macOS updates over to Software Update in Settings, SilentKnight should also work fine, up to a point.

To test this, I opened a VM running Sonoma 14.6, with XProtect 5270 and XPR 140. When it had found all three updates available, I clicked on the Install all updates button, just as I have always advised you not to! SilentKnight proceeded to download the macOS 14.6.1 update, but once that was complete it failed to install it. It then proceeded to download the XProtect and XPR updates, which it did successfully install on its own.

There was a vague notification that “Some updates could not be installed”, and the VM was left in 14.6, with XProtect and XPR correctly updated.

At that stage, Software Update stated the 14.6.1 update was available, offering a Restart Now button. When I clicked on that, the VM restarted and installed the 14.6.1 update successfully.

SilentKnight doesn’t provide the handy progress indicator that Software Update does, but just turns its busy spinner until the updates have finished. So you may still prefer to install macOS updates using Software Update. However, the end result should be just the same if you let SilentKnight do it, and finish off the installation using Software Update.

Downloading updates

Using another copy of the same VM running Sonoma 14.6 with outdated XProtect and XPR, I set SilentKnight’s settings to download but not install updates, then clicked the Download all updates button.

This left all the updates uninstalled, but there was no sign of them in the standard /Library/Updates folder as documented for softwareupdate. I looked high and low for those updates, but was unable to find them anywhere. I therefore recommend that you don’t use this option until someone has worked out where those downloaded updates are kept.

Unwanted macOS updates

If you click either the Install all updates or Download all updates button and one of the updates is for macOS, that will leave Software Update poised to complete the installation. If you didn’t want to install that macOS update, there is a way that you can now persuade Software Update to forget that it has been downloaded and is waiting, ready to install. This is most useful if you didn’t intend updating macOS, and now want to undo the process.

Shut your Mac down, then start it up in Safe mode. Leave it there for a minute or so, then restart it back into normal mode. Those uninstalled updates should now have been flushed, and Software Update is back to where it started.

Summary

• You should now be able to install macOS updates using SilentKnight if you wish. When warned that some updates weren’t installed, open Software Update settings and complete the installation there using the Restart Now button.
• Don’t use SilentKnight’s setting to only download but not install updates, as the downloaded updates can’t be found and used.
• If you inadvertently click the Install all updates button and want to reverse that for a macOS update, let the download complete, shut down, start up in Safe mode, wait a minute, then restart in normal mode.
• These apply to Apple silicon Macs, and are untested in Intel Macs, although there’s no reason to believe they should differ there.