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.

At the end of this year, my free utility SilentKnight will celebrate its eighth birthday (including its time as LockRattler), hopefully by then in its third app and third version. It originated after a gaffe when a whole batch of brand new MacBook Pros were delivered with their System Integrity Protection (SIP) disabled. At that time the only way to test that was at the command line.

By December 2016, LockRattler version 2.0 was already running a suite of nine checks including SIP status. In those days, XProtect had little to do with checking for known malware, and was mainly concerned with ensuring the latest version of Adobe Flash Player was installed.

With version 4.0 a year later, LockRattler had assumed its familiar layout, and had begun checking settings for Software Update, although it couldn’t run them itself.

Another year had passed when LockRattler reached version 4.1, and could both check for and install all pending updates.

Version 4.18 of December 2018 added the use of red text to draw attention to changes and discrepancies, and LockRattler hasn’t changed a great deal since.

The following year, I pursued goals to automate checking for updates and firmware versions, and simplify LockRattler’s interface in a new app, initially named EFIcienC.

By the time it had reached version 1.0b2 in July 2019, it was recognisable as SilentKnight, its name when it was released later that month as version 1.0.

Support for Apple silicon Macs was incorporated early, and finalised in version 1.14 in November 2020.

SilentKnight 2.0 was released in October 2022, and continues to support macOS up to Sequoia.

As I have explained, macOS 15 changes the management of XProtect and its updates, requiring substantial internal changes in SilentKnight, so I’m now working on version 3. I think the time is right to revisit and redesign its interface, and if possible implement it using SwiftUI so that it becomes more dynamic and adaptive. I have already been experimenting with that, and offer these ideas for your debate.

Both LockRattler and SilentKnight overwhelm with information that is often duplicated or redundant. Their fixed view layouts operate the same for all models of Mac, with the sole exception of information about Studio Displays. I’m keen to move to a more dynamic interface that delivers important information cleanly and clearly, without repetition.

When you first open SilentKnight 3, it should inform you what is right, and what isn’t, so categories in which all entries are as expected are left unexpanded, and only the one that has an unexpected result is automatically expanded, for you to see the abnormal result, shown with the result that SilentKnight expected. These functional groupings correspond closely to those in Skint.

Expanding all the entries shows a complete summary of information about that Mac at the time that SilentKnight last ran its checks, as given in the footer. These are set in a scrolling view and expand within the window as you prefer.

It’s my intention that this new version will list available updates by their label, and allow you to select which you want to download and install, with an easy option to install all of them. That should work around the problems of updating security data updates without updating or upgrading macOS itself. It should also do away with the Install Named Update feature in previous versions, without risking confusion.

Version 3 will also come with a refreshed app icon. The current one identifies EFI and MRT, both of which are increasingly becoming historical remnants now.

Finally, despite what I said earlier, I hope to make this available with support for late versions of Sonoma, as well as Sequoia.

I welcome your comments and suggestions, please.

Imagine my surprise earlier this week when I went to ensure my MacBook Pro had successfully installed new versions of XProtect and XProtect Remediator. SilentKnight informed me that XProtect was still at version 5270, and there was no update available to take it to 5271. I then manually checked the version of XProtect.bundle in CoreServices, and that confirmed it hadn’t been updated, but SilentKnight still couldn’t find any update, despite XProtect Remediator updating as normal.

My next visit was to the list of Installations in System Information, where it informed me that XProtect had been updated to 5271, thanks to XProtectCloudKitUpdate, instead of the usual XProtectPlistConfigData installation downloaded through softwareupdate. After a little jiggling with the new xprotect command tool I realised what had happened, and why SilentKnight was awry.

After an unfortunate delay, described later, I’m at last able to offer a new version of SilentKnight that won’t make this same mistake when run in recent beta-releases of Sequoia. Version 2.10 now detects whether it’s running on Sequoia; if it is, instead of inspecting the version of the XProtect.bundle in CoreServices, it now uses the official method of
xprotect version
instead.

Sadly, things get more difficult if XProtect is out of date. SilentKnight can’t use its normal call for update installation to softwareupdate, as that doesn’t handle XProtect updates any more in Sequoia. The official method is first to check whether an update is available using
xprotect check
then perform the update with
xprotect update
Although that might seem simple enough for SilentKnight to handle, both of those calls need to be made with elevated privileges. In Terminal, you’d just preface them with sudo, but apps can’t do that, and should normally use a privileged helper app, running with root privileges, something none of my apps do yet.

There’s another problem for SilentKnight in that it now needs to use two separate methods of checking for updates, and that in turn requires its code to be completely rewritten, a task I’m deferring to a whole new version, SilentKnight 3, which will only run on Sequoia. Until that’s available, bear with me and use the xprotect commands above as you need (remembering to sudo them); at least SilentKnight will now indicate when that might be necessary.

SilentKnight version 2.10 is available from here: silentknight210
from Downloads above, from its Product Page, and through its auto-update mechanism. Apart from fixing any remaining bugs, I intend this to be the final release of SilentKnight 2 with support up to and including macOS Sonoma, when updating remained so simple.

You can see the effect during one of my tests in a freshly made Sequoia VM.

At first, there’s apparently no XProtect installed at all, and the command tool returns a version of 0. Although there are updates offered for MRT (really?), Gatekeeper Compatibility Data and XProtectPayloads (XProtect Remediator), none is offered for XProtect.

I then manually updated XProtect using the command tool, and ran SilentKnight 2.10 again.

Immediately afterwards, XProtect is at the current version number of 5271 even though there’s no XProtect.bundle in CoreServices, and there’s no record of that update in the list of latest updates. That’s listed in the new version of SystHist, though, giving its mysterious XProtectCloudKitUpdate origin.

This update has been released a day later than I intended, because of a disorientating bug that caused the app to crash early whenever it tried to start up, complaining of an unreachable file path when it was starting to run its main code. I suspected a problem in the structure of the app and chased many red herrings before I realised this was the result of overenthusiastic code.

I have put the call to the xprotect command tool into conditional code, with an if to check whether it was running on Sequoia or earlier macOS. Apparently the path to the command was being checked before the instructions discovered whether that code would be run. As the path to the command tool doesn’t exist on earlier macOS, when it was being checked before determining which macOS was running, that was failing in Sonoma, as expected. Once I had worked out where this was occurring, without any clue from the errors, I had to change the type of conditional test used so the code didn’t check a non-existent path on older macOS.

Soon after the first beta-release of macOS 15.0 Sequoia, I noticed a post on X (formerly Twitter) reporting a new command tool xprotect, but never got the chance to take a look at it. With recent updates to the beta versions, its purpose has become clear: Sequoia uses a different mechanism to update its XProtect data. And that’s not compatible with any of my security update utilities, LockRattler, SilentKnight, Skint, or even SystHist.

The reason for this is that, in all previous versions of macOS going back many years, XProtect data are stored in a bundle named XProtect.bundle, where you (and my apps) can check its installed version number. But in Sequoia that bundle is neither used nor updated when XProtect data are updated. Indeed, Software Update and its command tool equivalent softwareupdate, used by my apps, can’t even see XProtect updates any more, as they’re checked and installed using a different mechanism, which is where the xprotect command tool comes into play.

Run any of those apps on a recent version of Sequoia, and they’ll dutifully report the version of XProtect found in that bundle, which will now be out of date, but the update is apparently not available, although in many cases it has already been installed and protection is up to date!

Unfortunately, as is so often the case, searching Sequoia’s release notes and other Apple sources fails to discover any information about this change, or the xprotect command tool.

SystHist was due its annual update anyway, so its new version 1.20 now handles Sequoia updates and (as well as it can) reports those it can find to XProtect. This new version is available from here: systhist120
from Downloads above, from its Product Page, and through its auto-update mechanism.

Skint (and its menu bar companion SkintM) version 1.08 now checks correctly for the XProtect version in Sequoia, and is available from here: skint108
from Downloads above, from its Product Page, and through its auto-update mechanism.

I’m not proposing updating LockRattler to address this issue, as SilentKnight and Skint are now capable of handling most needs. If this distresses you, please let me know and I’ll see what I can do in the coming weeks. However, without major internal surgery it’s never going to work fully with Sequoia, I’m afraid.

I was hoping to release a new version of SilentKnight today too, but Xcode gremlins are currently blowing that away, and I fear I have some reconstruction needed before it will do anything other than crash! As soon as I have a stable release, I will make it available.

These changes are sufficient to make it unwise to continue with the current major version of SilentKnight, as all its update code needs to be reworked so that it handles other updates through softwareupdate, as it does at present, and has a privileged helper app to obtain updates using the new mechanism for XProtect alone. My intention therefore is to provide one final update to SilentKnight 2 that will work without being able to update XProtect in macOS 15. That will be the final release to support macOS Catalina to Sonoma. The new version will be SilentKnight 3, will require Sequoia, and I hope will be released before Sequoia 15.0 hits the streets.

I apologise for this, and for the mess it’s causing for SilentKnight in Sequoia, but as you’ll appreciate this is all way beyond my control. I will also be writing further about what appears to be happening with XProtect for the weekend.

It’s common knowledge that Apple supports each version of macOS for a full year of updates, then a further two years of security updates. But for how long does it support the firmware in each model? Now that the only way to update a Mac’s firmware is by installing a macOS update, how does that affect the support period? This article tries to answer those questions, and in doing so unearths a bit of a mystery that happened just over a decade ago.

Data

Apple doesn’t release any information about firmware versions or updates, and they very seldom even get a mention in its release notes for security updates. Fortunately, as I have been tracking firmware versions for each model since the release of High Sierra seven years ago, I have my own records derived from the versions contained in macOS updates. I’ve matched those against the model introduction and discontinuation dates given in Ian Page’s Mactracker database, and here summarise the results.

How updates work

Each macOS update may bring firmware updates, although pure security patches during the first year of support tend to bring fewer. Firmware updates are the same across all three macOS updates normally released at the same time. So those brought in the recent update to 14.6 are the same as those in 13.6.8 and 12.7.5, for models supported by each, but each update only installs updates for those models it supports. This becomes clearer with the aid of examples that also reveal the inner mystery of these updates.

On 15 July 2020, the main update brought macOS 10.15.6, and alongside it security updates (SU) for macOS 10.13 and 10.14. Those included the following EFI firmware versions:

• for iMac12,1 version 87.0.0.0.0 of 14 June 2019
• for iMac13,1 version 292.0.0.0.0 of 10 June 2020
• for MacBookPro8,1 version 87.0.0.0.0 of 13 June 2019
• for MacBookPro9,1 version 233.0.0.0.0 of 10 June 2020.

The two firmware versions dated 2019, for iMac12,1 and MacBookPro8,1, were a year old at that time, as Apple had discontinued releasing new firmware versions for those two models in June 2019. However, iMac13,1 and MacBookPro9,1 models received a new version of their firmware if they had macOS 10.15.6 or either of the security updates installed.

A year later, on 21 July 2021, Apple released the update to macOS 11.5, and with it Mojave SU 2021-005. As the iMac12,1 and MacBookPro8,1 were no longer able to run a supported version of macOS, neither had a firmware update, leaving them running the versions from June 2019. The two more recent models then had the following updates:

• for iMac13,1 version 422.0.0.0.0 of 4 June 2021
• for MacBookPro9,1 version 422.0.0.0.0 of 4 June 2021.

Another year later, on 20 July 2022, both those models could still run supported macOS, and had the following firmware updates in Catalina SU 2022-005:

• for iMac13,1 version 429.0.0.0.0 of 18 Mar 2022
• for MacBookPro9,1 version 429.0.0.0.0 of 18 Mar 2022.

But those weren’t new in that SU, as by that time firmware updates for those two models had been discontinued, and in Big Sur 11.7.7 on 18 May 2023, neither model had any firmware available as they were no longer supported by a version of macOS that still received updates.

The stark fact revealed in this example is that, for consecutive models of iMac and MacBook Pro, released just over a year apart, there had been almost three years difference in the last firmware update released:

• for iMac12,1 last release June 2019, for iMac13,1 last release March 2022
• for MacBookPro8,1 last release June 2019, for MacBookPro9,1 last release March 2022.

How long?

I therefore compiled data for 40 different model designations of Intel Macs without T2 chips introduced from October 2009 to the present, each of which had apparently passed its final firmware update. That excludes the few models that are still receiving firmware updates now.

This chart shows the dates of each model’s last firmware update by the date of introduction of that model. There’s a large cluster of Macs introduced before 2012 that received their final firmware update in June 2019, then a gap of almost two years during which all later models received further firmware updates, before the next batch of older models, this time from 2012-13, received their final updates. There’s an outlier visible at the top right, the iMac19,1, introduced in March 2019, but which appears to have undergone its final update in February 2024, exceptionally early. Although that has received no firmware updates since, it’s plausible that it may yet receive more in the future.

This chart shows the total length of firmware support in years by the date of introduction of that model. There are three distinct groups:

• models from before 2012, forming a steep line at the left, with support times ranging from just under 8 to nearly 10 years;
• more recent models, forming a less dense scatter with support times from just under 7.5 to almost 10 years;
• the iMac19,1 outlier at the bottom right, with its exceptionally short support time of about 5 years.

This is the same chart with superimposed labels giving each model’s designation. There doesn’t appear to be any association between model range (e.g. iMac) and length of support.

Thus, for most Intel models without T2 chips introduced since 2009, support for firmware updates has extended to at least 8 years since their introduction. As the period between introduction and discontinuation of models varies widely, there is greater scatter when these are expressed in terms of the date of discontinuation.

The gap

There are several possible reasons that might account for the gap between Macs introduced before 2012 and those introduced more recently. These include:

• the transition from Sandy Bridge to Ivy Bridge in Macs introduced in 2011-12;
• an intended period of stability in Intel Macs during the introduction of Apple silicon models;
• a choice by Apple not to discontinue firmware support during the Covid pandemic, although I don’t recall that ever being articulated;
• an arbitrary change in Apple’s firmware support policy.

Of those I favour the transition away from Sandy Bridge, which is known to have had problems that may have resulted in firmware support being curtailed earlier than would have been intended.

It’s important to note that this gap doesn’t mean that firmware updates weren’t released during that period, merely that models still being updated during that time continued to do so, with none being terminated then.

T2 and Apple silicon

These more recent models, introduced from 2017 on, change firmware updates completely. All Macs with T2 chips receive what appear to be identical firmware updates. Instead of further updates being abandoned despite a Mac still being supported by macOS updates, as happened in some cases, it appears more likely that T2 firmware updates will only cease when a model is no longer supported by macOS updates.

With Apple’s complete ownership of hardware and operating system in Apple silicon Macs, it’s within its gift to determine how long each will be supported.

Conclusions

• For most Intel Macs without a T2 chip, Apple has provided firmware updates for at least 8 years after that model’s introduction. For many models, that occurred before they became unable to run a supported version of macOS.
• Some Macs introduced before 2012, with Sandy Bridge chipsets, had firmware support withdrawn early. The reason for that isn’t clear, but may relate to their chipset.
• T2 and Apple silicon Macs will be different.

If you want to check that your Mac is running the current firmware, my free app SilentKnight does that, and has now been updated to use those versions released in macOS 14.6, 13.6.8 and 12.7.5. Alternatively you can check manually using the lists at:
Which firmware should your Mac be using? (version 8) – for Sonoma
Which firmware should your Mac be using? (version 7) – for Ventura
Which firmware should your Mac be using? (version 6) – for Monterey
Which firmware should your Mac be using? (version 5) – for Big Sur
Which EFI firmware should your Mac be using? (version 4) – for Catalina
Which EFI firmware should your Mac be using? (version 3) – for Sierra, High Sierra, Mojave
Which EFI firmware should your Mac be using? (version 2) – for El Capitan and earlier

Now that the first public beta of Sequoia is available, I thought it might be helpful to detail which of my most popular apps are compatible with versions of macOS from El Capitan to that Sequoia beta.

Update and security utilities

Skint runs daily check on key security systems. Skint 1.07 runs on Monterey and later, and appears fully compatible with Sequoia.

SilentKnight runs automatic checks of firmware and security systems. For El Capitan to Mojave you should use SilentKnight 1.21, but for all versions of macOS from Catalina onwards use SilentKnight 2.9. This appears fully compatible with Sequoia, although at present it will report TCC Not found, which you can safely ignore. Apple doesn’t release new versions of some of its security databases until late in the beta phase, when I expect that will be put right.

LockRattler provides manual checks of firmware and security systems, similar to those in SilentKnight. For El Capitan and Sierra, use LockRattler 4.35, but for all later versions of macOS from Mojave onwards, use LockRattler 4.37 instead. This too appears fully compatible with Sequoia, although it reports TCC Not found for current betas.

SysHist lists full system and security update installation history. In El Capitan and Sierra, use SystHist 1.17, but for High Sierra and later, use SystHist 1.19 instead. This currently doesn’t show any Sequoia updates, but I will release a revised version in the coming weeks to address that. This is because it has to be able to recognise macOS updates by name, and that isn’t stable until later during the beta-testing phase.

XProCheck checks on XProtect Remediator scans completed and reported in the log. Use XProCheck 1.5 in all versions of macOS from Catalina onwards, that support this new variant of XProtect. I intend to release an updated version in the coming weeks, but this version appears fully compatible with Sequoia.

Rich text and PDF

DelightEd is a Rich Text (RTF) editor with special Dark Mode features and support for interlinear text. The latest version to run on Sierra is DelightEd 2.0b4, but for all more recent versions of macOS I recommend using DelightEd 2.2. This appears fully compatible with Sequoia, although I don’t know yet whether it will support Writing Tools, because of conflicting documentation.

Podofyllin is a lightweight PDF viewer and analysis utility. Podofyllin 1.2 is compatible with High Sierra and later, and appears to be fully compatible with Sequoia too.

Log and technical utilities

T2M2 provides quick but thorough checks of Time Machine backing up. When backing up to HFS+ backup stores, or to a NAS, use T2M2 1.19, but when backing up to APFS stores or NAS in Big Sur or later, use T2M2 2.02 instead. Although I haven’t tested this yet with Sequoia, I believe that it should work well.

Mints is a multi-purpose utility that produces custom log extracts, including iCloud, extensive system info and more. Sierra is still supported by Mints 1.9, but for all more recent macOS from High Sierra onwards, use Mints 1.19. This also appears fully compatible with Sequoia.

xattred is a full-featured extended attribute editor, which can also add quarantine xattrs. For El Capitan and Sierra, use xattred 1.2, and for High Sierra and later, use xattred 1.5 instead. This appears fully compatible with Sequoia.

Precize 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. El Capitan and Sierra are still supported by Precize 1.12, but for High Sierra and later use Precize 1.14, which also appears fully compatible with Sequoia.

Ulbow is a log browser designed for ease of use. Ulbow 1.3 runs on Sierra, the first version of macOS to support the new Unified log. Use Ulbow 1.10 on High Sierra and later versions, and it also appears fully compatible with Sequoia, except that it currently can’t create logarchives, a shortcoming in all more recent versions of macOS.

Virtualisation

Viable creates and runs macOS VMs on Apple silicon Macs. Viable beta 12 (1.0.12) works on all versions from Monterey on, and on Sequoia it will now create VMs with Apple ID support. However, it doesn’t yet support the suspension and quitting of VMs (you still have to shut down the guest macOS), and doesn’t give access to external USB devices, a feature new to Sequoia. This article explains how to virtualise Sequoia on a host running either Sonoma or Sequoia.

Vimy runs macOS VMs on Apple silicon Macs from a double-click, and is the runtime companion to Viable. Vimy 0.7 (fourth beta) runs on all versions from Monterey on, including Sequoia, and supports all the features in VMs created using Viable.

Other apps of mine that remain available, many supporting versions of macOS back to El Capitan, are detailed here.

Enjoy, and please report any issues, particularly those with Sequoia betas, so that I can fix them before Apple releases macOS 15 in a couple of months.