Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5273.
Apple doesn’t release information about what security issues this update might add or change. 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.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5273.
If you’ve upgraded to Sequoia and are still stuck at a version number of 0 or 5272, you can either leave macOS to catch up with this in its own good time, or you can force an update by typing into Terminal sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
As promised last week, Apple has released the upgrade to macOS 15.0 Sequoia, together with security updates to bring Sonoma to version 14.7, and Ventura to 13.7. There should also be Safari updates to accompany the latter two.
The Sequoia update is around 6.6 GB for Apple silicon Macs, and 14.7 is around 1.6 GB. For Intel Macs, 15.0 is around 4.9 GB as an ‘update’, and 14.7 is around 860 MB.
Security release notes for Sequoia list around 77 vulnerabilities addressed, including two in the kernel, none of which Apple is aware may have been exploited in the wild. Release notes list 36 vulnerabilities addressed in Sonoma 14.7 here, and there are 30 listed for Ventura 13.7 here.
iBoot firmware is updated to version 11881.1.1, Intel T2 firmware to version 2069.0.0.0.0 (iBridge 22.16.10353.0.0,0), and Safari to 18.0 (20619.1.26.31.6).
After completing the upgrade to 15.0, you are likely to see that the installed XProtect version is 0, in other words that there is no XProtect data. You can leave your Mac to automatically download the required data from iCloud, or manually force it using the command sudo xprotect update
then entering your admin password. That will normally ‘activate’ the XProtect data previously installed, and set the version to 5272, although that will then need to be updated to 5273 separately. Don’t be surprised if you end up repeating the trip to Terminal to get this to work.
Later today, Apple is expected to release macOS Sequoia 15.0. For those interested in planning their immediate or delayed upgrade, these are my forecast dates for its minor versions over the coming year. Like all the best weather forecasts, this is most accurate for the next 5 days, and those for further into the future are likely to be decreasingly reliable.
Minor version release dates for Sonoma have been broadly similar to those of others since Big Sur:
14.0 – 26 September,
14.1 – 25 October,
14.2 – 11 December,
14.3 – 22 January,
14.4 – 07 March,
14.5 – 13 May,
14.6 – 29 July,
14.7 – 16 September.
Ventura differed mostly because it had a later start date to its cycle, in October, resulting in the delay of 13.1 until December. Subsequent versions thus trailed Sonoma by one, for example with 13.5 on 24 July, against 14.6 on 29 July. Although Apple is believed to have some flexibility in the release dates for minor updates, the timetable for the cycle appears to be fixed well in advance, and is probably already at least pencilled in for Sequoia.
Most minor updates bring new versions of firmware, the kernel and key kernel extensions such as APFS. In between those may be patch updates to fix serious bugs or security vulnerabilities that can’t wait for the next minor version, such as 14.3.1 on 8 February, two weeks after 14.3 and a month before 14.4.
According to Apple’s release notes, the current release candidate for 15.0 has no significant bugs that remain unfixed, and we hope that remains the case.
15.1: October 2024
Apple has already announced that this first ‘minor’ update will bring its AI features, including most significantly Writing Tools. Although those have been in beta-testing for almost as long as 15.0, in terms of changes, the step from 15.0 will in many ways be greater than that from 14.6 to 15.0. However, that only applies to Apple silicon Macs that support AI.
For all Macs, this is likely to bring fixes for some more substantial bugs, although because of the short interval between 15.0 and 15.1, few are likely to be addressed until 15.2.
This update is likely to coincide with new Mac products launched at an as-yet unannounced Mac event in October, where Apple is expected to promote its new M4 Macs as being ‘made for AI’, much in the way that it did last week with the iPhone 16 range.
15.2: December 2024
Turnaround time fixing even straightforward high priority bugs makes it likely that most in 15.0 will be addressed not in 15.1 but 15.2, before Christmas. This will also catch the first fixes and any additional enhancements required by AI, so may well be one of the more substantial updates this cycle. The aim is to give engineering teams a chance to catch up with the vacation without leaving too much to await their return in the New Year.
15.3: January 2025
This update is largely constrained by the effects of the Christmas vacation, but should enable most issues arising in 15.0 and 15.1 to be fixed, leaving Sequoia running sweetly.
15.4: March 2025
This is the major mid-cycle update, that is most likely to contain new and enhanced features, often making it the largest update of the cycle. Apple also seems to use this to introduce initial versions of new features intended to become fully functional before the end of the cycle. One example of this was XProtect Remediator, released on 14 March 2022 in Monterey 12.3, but not really functional until June that year.
Unfortunately, these enhancements can also cause problems, and this update in March has a track record of sporadic more serious bugs, including the occasional kernel panic.
15.5: May 2025
A month or so before the first beta-release of the next major version of macOS, this normally aims to fix as many remaining bugs as possible, and progress any enhancements introduced in the previous update. If you’ve reported a bug before April, then if it’s going to be fixed in this cycle, this is the most likely time; any new bugs reported after this update are most likely to be carried over to the next major release.
15.6: July 2025
This really is the last chance for fixes and feature-tweaks before the next major version is released in September. If all is working out well, this should be the most stable and bug-free release, although in some years late changes have turned this update into a nightmare, and Sonoma required a patch update in early August to address those.
When best to upgrade?
If third-party software, hardware and other compatibility requirements don’t apply, there’s no way to predict which is the best version to choose as an upgrade from previous macOS. Every version contains bugs, some of them may be serious, others may be infuriating and intrude into your workflows. But those aren’t predictable. If you’re unsure, wait a few days after a minor update, or even 15.0, check around with others, and decide then. If you’re really cautious and have an Apple silicon Mac, I suggest you might like to consider upgrading a week or two after the release of 15.1, by which time most of any major issues with 15.0 and AI should have come to the surface.
For myself, I already have my designated beta-testing Mac, a MacBook Pro M3 Pro, running 15.1 beta, and my other three Macs (iMac Pro, Mac Studio M1 Max and MacBook Pro 16-inch 2019) will all be running 15.0 by midnight tonight, I hope. I’ll let you know how I get on.
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.
With macOS Sequoia fast approaching from the horizon comes the question as to how to upgrade and update, whether to Sequoia or one of its recent predecessors. If you’re happy to go with what Software Update offers, then that’s usually simplest and most efficient. This article considers what you should do if you want something different, from updating to any previous version, to using a single installer to update several different Macs.
Procedures given here should work with all versions of macOS from Monterey onwards. They may work too with Big Sur, but its installers weren’t always as reliable, so you should there be well-prepared to have to migrate from a backup in case the installation creates a fresh, empty Data volume instead of firmlinking up to your existing one.
Which installer?
As Apple discontinued standalone updater packages when it introduced Big Sur, the choice now is between downloading the full Installer app, and performing the process in Recovery mode. The latter severely limits your choice to what it’s prepared to offer, so you’re almost certainly going to need to obtain the full Installer for the version of macOS you want. Rather than use the Installer app provided in the App Store, download the Installer package from the links given by Mr. Macintosh. Those provide a package that’s easier to store and move around, unlike the Installer app itself. It will typically be a little over 13.5 GB, and works on both Intel and Apple silicon Macs.
Standard procedure
As with any update or upgrade, first ensure you have a full recent backup before starting. If anything does go wrong during the procedure you’ll then be able to perform a fresh install and migrate from that backup.
Unless you want to install everything afresh and migrate from your backup, don’t try erasing either your System or Data volume. You’d have to do that in Recovery mode anyway, limiting your options as to which version of macOS you can install unless you create a bootable installer first.
Double-click the installer package to launch it in the Installer utility. The default is to save the Installer app to your current Applications folder, which should work fine as long as you remember to delete it once you’ve finished. Once complete, launch that Installer app and follow its instructions.
When macOS restarts at the end of the process, check the version now running, confirm that your Data volume has survived intact, and run SilentKnight to ensure that all security data files are up-to-date.
Recovery
Intel Macs have a slight advantage when it comes to installing macOS in Recovery mode, as depending on the keys held during startup, you should be able to coax a choice of versions out of an Intel system. Unless you simply want to install or update to the current version, though, you’ll probably want to avoid doing so in Recovery.
There’s another good reason for not using Recovery, in that delivery of installers to Macs running in Recovery can be painfully slow, and you may well be in for a longer wait than if you downloaded the Installer direct.
However, if you want to erase the current boot volume group on your Mac’s internal storage so you can install a fresh copy of macOS and restore the contents of its Data volume from backups, Recovery is normally the best place to do that. Apple works through the process for Intel Macs, and Apple silicon models. The key step is to select the Macintosh HD boot volume group and click on the Erase tool to perform Erase Volume Group.
When the SSV was first introduced in Big Sur, there were many problems resulting from erasing just one volume in the boot volume group. If that happened to be the System volume, when macOS was installed it created a new firmlinked Data volume, leaving the existing Data volume as an orphan. That was usually done in a misguided attempt to have a fresh install of the System volume and SSV while keeping the existing contents of the Data volume, but doesn’t do that. Every installation of the SSV in any given version of macOS since Big Sur is identical, so it isn’t necessary to erase it, but simply to install or update macOS.
Bootable installer disk
Another traditional way to install macOS is using a bootable installer disk, normally a USB ‘thumb’ drive, although you can also create a small HFS+ volume for the purpose on an external SSD. Apple provides detailed instructions for doing this using a range of versions of macOS.
In many cases, installing a version of macOS older than the one that’s currently running requires this, as old Installers usually fail to run in newer macOS. Unfortunately, on Apple silicon Macs, this isn’t the powerful tool that it once was, as the Mac doesn’t boot fully from the external disk, and as a result it has no role in dealing with problems with internal storage.
Virtual Machines on Apple silicon
Installer apps and Recovery installs both work fine in virtual machines running on Apple silicon hosts. However, there’s one special circumstance you need to beware of. One of the major new features in virtualisation in Sequoia is support for iCloud and some other services dependent on Apple ID. If you want to use those, then the VM must be created new in Sequoia, using a Sequoia IPSW image. You can’t update or upgrade an existing VM from a previous version of macOS and use iCloud services in it.
Summary
If you can, use Software Update to update or upgrade macOS, as it minimises download size and is simplest.
If you want to perform a different update, or run one installer on several Macs, download and use the appropriate Installer package.
If you want to erase the existing system including all your data, use Recovery mode to erase the whole volume group, then install macOS and migrate from your backup.
Never erase only your Mac’s System volume, as that will orphan its current Data volume.
If you want to downgrade to an older version of macOS, you’ll probably need to do so from a bootable installer disk.
If you want a VM to use iCloud, then create a fresh VM using a Sequoia IPSW, as an upgraded VM can’t access iCloud.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 145. The previous version was 142.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-145.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
If XProtect Remediator came of age in macOS Ventura, then it has been XProtect’s turn in Sonoma. Starting from version 2171 with 216 rules in under 3,000 lines in its Yara definitions, it emerged a year later in version 5272 with 347 rules in over 13,000 lines, although mercifully not after 3,100 versions.
I had always assumed that those Yara rules were compiled straightaway into something more tractable for checking executable code, but it seems that each time XProtect performs one of its ‘direct malware and dylib scans’, it first looks for a non-existent Yara file, then uses the rules in the XProtect.bundle, as it reports in the log: com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>
com.apple.xprotect Rule path is not accessible: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect2.yara
com.apple.xprotect Using XProtect rules location: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara
Apparently, to cope with this explosive growth, and potentially support more frequent tweaks to its growing horde of Yara rules, macOS Sequoia is changing the way that XProtect’s data is updated and managed. A chance find by @L0Psec revealed how this has moved beyond those updates delivered by softwareupdate, and a new command toolxprotect handles this separately in CloudKit.
Last week’s update to XProtect’s Yara file was an experience those beta-testing Sequoia 15.0 or 15.1 must have found profoundly confusing, and I quickly became aware of reports that were changing by the minute.
When XProtect 5272 was first made available through softwareupdate, Sonoma and earlier systems found and installed it as usual, as did some running Sequoia betas. That updated the visible XProtect.bundle in CoreServices, but didn’t update XProtect according to its new xprotect command tool, which still reported the local version of XProtect as 5271. Without knowing how XProtect has changed, the user would most likely see this as a bug.
A little later, I saw reports of Sequoia installations apparently updating spontaneously via CloudKit, using its new mechanism, which did change the version reported by xprotect version.
At this stage, I had a 15.0 virtual machine that had updated ‘correctly’ via CloudKit, and its host 15.1 system that had updated its bundle via softwareupdate, but still wasn’t apparently running the new version afterwards. Those of us who didn’t experience a spontaneous CloudKit update were left in limbo. I had originally changed the version databases used by SilentKnight and Skint to show a correct version of 5272 for Sequoia, and hurriedly had to revert that to 5271 before I became inundated with complaints from those whose Macs hadn’t been able to update.
It then occurred to me to try using the xprotect command to force a CloudKit update on my 15.1 system. I first entered sudo xprotect check
only to be told that the version available was still 5271. But when I ran sudo xprotect update
a miracle happened, with the response Update succeeded: Activated update LocalUpdate[5272]
That command had convinced macOS to ‘activate’ the updated bundle in /Library/Apple/System/Library/CoreServices rather than waiting for it to become available from CloudKit, a feature not mentioned in its man page or usage info. I returned to my version databases to change them a third time, back to 5272.
Previous XProtect updates such as 5271 that were obtained through CloudKit are now identified by SystHist as XProtectCloudKitUpdate, while those obtained by softwareupdate and activated using the xprotect command appear as standard XProtectPlistConfigData, as they do in Sonoma and earlier.
With the release of Sequoia due later this month, the xprotect command tool and XProtect’s new CloudKit updates have already encountered troubled water. If Apple stays true to form and doesn’t mention a word about this change, or its effect on XProtect updates, many of the millions of new Sequoia users could end up falling behind. But as we’re not supposed to know what the latest version is, nor which is currently active on our Macs without taking to Terminal’s command line, maybe most won’t be allowed to notice.
I’d like to think that Apple will explain these changes to users, document its new command tool properly, and ensure that users know the current version of XProtect data, and can check whether their Mac is up to date without having to resort to Terminal or third-party products, perhaps in System Information. Will I be disappointed?
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.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5272. Apple has now released this for Sequoia betas as well, using their new update mechanism.
Apple doesn’t release information about what security issues this update might add or change. This makes a small amendment in the Yara definitions to the detection signature for MACOS.d98ded3, and adds another rule to those to detect MACOS.DOLITTLE, in MACOS.DOLITTLE.DOFSTRGT.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5272.
If you’re running a Sequoia beta and are still stuck at 5271, don’t worry if sudo xprotect check
doesn’t offer you the update to 5272. Ignore it and run sudo xprotect update
and with any luck it will update your Mac to 5272.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 142. It appears this version was first released over 12 hours ago, early in the morning GMT, but was then removed from Apple’s update servers. It has just now been made available again.
Apple doesn’t release information about what security issues this update might add or change. For the first time since its release, this update removes a scanning module, for RedPine. Bastion rules remain unchanged.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-142.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
When a solution works once, we tend to keep using it even though it may no longer be necessary, or may no longer be possible in the same way. This article is about one example, how we used to update macOS using Combo updaters in the days before Big Sur. Now those are no longer available, should we perform a fresh install of macOS whenever there’s an update?
How macOS updates worked
Before we upgraded to Big Sur, macOS updates were relatively simple, and based on installer packages, structured collections of files that are copied to the boot volume in accordance with scripts. Once that copying is complete and the boot volume contains the files forming the new version of macOS, the Mac can be rebooted from those.
Take the last of those major versions of macOS, Catalina. In the diagram below, I show in miniature what happened during the course of its first two minor updates, as an example.
Updating from Mojave to Catalina 10.15.0 was performed using installer packages that completely replaced everything in its system, then created in a new System volume, as shown at the top. This was referred to as an upgrade, as the whole system was installed afresh.
Then (skipping a Supplemental Update) came the first minor update to 10.15.1 on 29 October 2019. For the sake of this example, consider that includes a new version of the cat command tool. Rather than that update containing the whole system all over again, it only contains and installs what has changed, including the new cat binary.
Then, on 10 December 2019, Apple released the update to 10.15.2, containing another set of changed files, this time perhaps replacing the cp command tool. There are two ways to install that update, either as a delta update or a Combo. The delta update contains the changes from 10.15.1, here cp; the Combo update contains everything that has changed since 10.15.0, both that in 10.15.1, here cat, and in 10.15.2 with cp.
Combo updates tackled what was then a common problem, when a previous update hadn’t been installed correctly. If the update to 10.15.1 didn’t actually install the new cat and we then installed the delta update for 10.15.2, the latter wouldn’t have worked properly. As there was limited error checking in those old updaters, we would then be using a flawed installation of macOS. By installing the 10.15.2 Combo updater instead of the delta, the chance of errors like that were significantly reduced, and we were thoroughly impressed by updating using the Combo rather than delta update.
In fact, it was seldom necessary to install the Combo update every time, as most updates went well and errors weren’t as common as it seemed. What I have always recommended has been to install the delta update first, and only to resort to the Combo version if that didn’t work properly.
Big Sur and the SSV
Catalina’s novel boot volume group, with its separate System and Data volumes, was only an intermediate step to Big Sur, which brought the greatest structural change in Mac operating systems since the introduction of Mac OS X twenty years earlier. Here, the great majority of macOS runs from a mounted snapshot with a read-only file system separate from that of user files on the paired Data volume, and requires a fundamentally different method of installation and updating.
In addition to updating the contents of the system, from Big Sur onwards installers and updaters have considerably more to do. Those tasks include creating the new snapshot to contain the bootable copy of the system, firmlinking that System snapshot with its paired Data volume, building a tree of cryptographic hashes so that the snapshot can be sealed, and verifying the signature of its seal against Apple’s requirement.
If we follow Big Sur’s first couple of updates, you’ll see how they have changed. On 14 December 2020, the update to 11.1.0 might have gone through similar changes to Catalina, with the replacement of its cat command tool. Once that had been installed on the System volume, a snapshot was made of that System volume, hashes were computed for all its contents, and assembled into a tree. At the top of the tree, a hash of all the hashes in the next layer down forms its seal, which is then hashed again to form the signature of the Signed System Volume (SSV). The signature is compared against that set by Apple for the whole volume, and only if they’re identical is the System snapshot accepted for use.
There’s no room here for the slightest error if the signature on the Signed System Volume (SSV) is going to match its requirement. Within the SSV are additional changes, such as large dyld caches, which serve to make this more complicated, and more recently this includes cryptexes containing system components like Safari that are kept outside the SSV so they can be updated outside full macOS updates.
When that was updated again to 11.2.0 on 1 February 2021, perhaps with a new version of the cp tool, the new installer repeats this process of creating a new snapshot, building its tree of hashes, sealing them, creating the signature, and comparing that with Apple’s signature. This means that each and every update is verified to be perfect, and no errors can be tolerated.
No Combo updates
In the new system, from Big Sur onwards, Apple only provides Combo updates for those updating from versions of macOS older than the previous version, and only when required. If you were to update straight from 11.0 to 11.2, then your Mac downloads all that it requires for that update. If your Mac is already running 11.1.0, there’s no option to install the changes in 11.1.0 again, nor could you need to, as its installation on 11.1.0 has already been verified as being identical to Apple’s reference.
If you felt that wasn’t adequate, then the only option is to install the whole of 11.2.0 from scratch, and running the Big Sur Installer app will do that for you. However, there’s no point in doing that, as the outcome will be identical, as verified by its signature match against Apple’s. All that would do is take longer, and increase wear on your Mac’s internal SSD.
That’s why Apple doesn’t provide the user with Combo updates any more, because they’re now superfluous.
I’ve been a trackpad warrior since Apple introduced its first Magic Trackpad back in 2010. I was a bit tentative at first, as I had been using mice for well over 20 years by then, but I soon became hooked. While I still keep a mouse by my Macs just in case, I’ve happily stroked and tapped my way through those last 14 years, and have come to rely on one key diagnostic, the Force Click. When Macs have frozen or collapsed in a snotty heap, loss of Force Click in the trackpad has told me that a restart is required. Not that I generally use Force Click, as I invariably opt to tap to click instead.
A couple of weeks ago, the Magic Trackpad for my iMac Pro lost its Force Click, and now feels dead in the same way that it used to when my Mac was in trouble. It occurred at some time around the Sonoma 14.6.1 update, so I restarted my Mac, and restarted the Magic Trackpad. Nothing changed, and there’s still no Force Click. I can still press its pad firmly to achieve the same effect, but there’s no click, no haptic feedback, and it just feels solid and dead.
I thought I had discovered the cause when I compared that trackpad, now on version 3.1.1 of its firmware, with that on my Mac Studio, which was strangely still on 1.9.2. The latter has retained its Force Click, tempting me to conclude that the firmware update must have been the cause of the missing Force Click. This was apparently confirmed when I swapped trackpads: that from my iMac Pro, with firmware version 3.1.1, had no Force Click when wired to my Studio, and the Studio’s trackpad, stuck on 1.9.2, retained its Force Click when connected to my iMac Pro.
When I had returned the two trackpads to their correct Macs, and before writing this article, I checked their firmware versions again, and discovered that they were now both on version 3.1.1, but one of them was still missing its Force Click, just as it had been all the way along.
Firmware updates for Apple’s keyboards, trackpads and mice are among its most closely guarded secrets. The last time there was a keyboard firmware update, back in mid-January, I wrote “This update flew so far below the radar that it wasn’t available through Software Update, and made no record of its installation except in the firmware of Apple’s Magic Keyboards. The only way to tell if your keyboard has been updated is to check via Bluetooth settings.”
Like that keyboard firmware update, there’s no record of any update on either Mac. Even my app SystHist draws a complete blank. Neither is there any mention of this update on Apple’s support site, and all I’ve been able to find is a report from @aaronp613 on 18 June 2024 that Magic Mouse and Magic Trackpad firmware had been updated to 3.1.1, as passed on by Filipe Espósito of 9to5 Mac.
Although Apple did announce its Magic Keyboard Firmware update 2.0.6 in January, there’s no mention of any Magic Mouse or Trackpad firmware update at Apple’s support site for keyboards and trackpads, although that may simply mean that its doesn’t address any security vulnerabilities, or that Apple has no intention of telling us. As there appears to be no way to obtain the update, and automatic installation is clearly neither timely nor predictable, Apple also appears uninterested in whether our Magic Trackpads and Mice are updated or not.
In the grand scheme of Macs, firmware for Apple’s comparatively expensive wireless keyboards, mice and trackpads may seem minor, but losing Force Click for no apparent reason after 14 years isn’t a good experience. There’s no good reason for these updates to fly under the radar, if and when they fly at all, nor for Apple to keep them such a secret.
So today’s announcement is that Apple released updates to the firmware of its Magic Mouse and Magic Trackpad devices in mid-June, to bring them to version 3.1.1. Apple hasn’t stated what has changed in this new version, and hasn’t released any account of any security issues that it might address. No one appears to know how this update finds its way into your Mac, nor how it’s installed in the peripherals. The only way you’ll discover whether your Mac’s devices have been updated is through the Bluetooth section in System Information, and if that still shows a previous version, there’s nothing you can do to force or even encourage an update.
Should you discover that your Magic Trackpad lost its Force Click as a potential consequence of this update, please let me know in the comments. And if you find a Force Click out there looking for its trackpad, please point it in my direction.
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.
Earlier this year, I wrote about the changes that had taken place in the System between Mojave and Sonoma 14.2.1. Now that 14.6 is out of the door and Sonoma is about to enter its two years of security-only maintenance, this article looks at how it progressed through its year as the current version of macOS. Those still running Monterey or earlier and wondering whether to upgrade now might like to take notes.
Over the last year, Sonoma has continued in the tradition of expanding the contents of the macOS System. Compared to late versions of Mojave in 2019, the number of bundles in the System library folder at /System/Library has increased by 175%, from 4,774 to 8,392, as shown in the chart below.
Steep rises in the number of bundles took place with the appearance of the boot volume group in Catalina, then again shortly before the release of the first M1 Macs, and their M3 successors in later 2023, but less so prior to the M2.
This is shown more clearly in the numbers of kernel extension bundles. New hardware often requires new kernel extensions for support, as well as their delivering architecture-specific features such as lightweight virtualisation on Apple silicon Macs. The total number of kernel extension bundles has risen from 680 in 10.15.6 to 772 in 14.6. Ironically, this is the same period over which Apple has been deprecating third-party kernel extensions, which are now decidedly uncommon on Apple silicon Macs.
Comparisons between folders within the /System/Library folder, between the last full releases of Catalina (10.15.6) and Sonoma (14.6), provide deeper insights as to just where that growth has taken place.
Greatest growth has been in Private Frameworks, which have almost doubled in number, from 2,055 to 3,803, now accounting for 45% of bundles in /System/Library. Those form the private API in macOS; public Frameworks have only risen from 600 to 772, now accounting for less than a tenth of all bundles. Thus the major increase in macOS has come in code that isn’t accessible to third-parties, only to Apple.
If you’re running a Sequoia beta, you might like to compare the figures for Extensions and the total number of bundles in /System/Library to see whether there’s any sharp increase to support the introduction of the M4 chip, or for Apple Intelligence in 15.1. I’m putting my money on the next Macs being from the M3 family, and expecting sudden rapid growth in bundles coming slightly later to support the introduction of AI.
There’s finer detail that you might have missed. During Sonoma’s year, Contact Key Verification was introduced for Messages, to ensure that your messages only reach those intended, although it requires all devices using the same Apple ID to be running recent versions of macOS/iOS/iPadOS. In lightweight virtualization, a bug was fixed that had prevented the VMs of older versions of macOS from updating with their security releases.
Among the new kernel extensions are some apparently supporting a new kernel architecture feature of Exclaves. Those include ExclaveSEPManagerProxy and ExclavesAudioKext, which might be concerned with those enhancements to virtualisation supporting the use of Apple ID in Sequoia.
Sonoma 14.4 in particular brought many new Private Frameworks, some with intriguing names include CascadeEngine, CascadeSets, Dendrite, DendriteIngest, several Poirot frameworks, SemanticPerception, and SonicKit. In other updates there were Cosmo and Tabi.
Since its release, updates to Sonoma appear to have brought mostly minor enhancements and new features, together with clearing a substantial backlog of bugs. This seems to have been a good opportunity to evolve and consolidate rather than rushing ahead with changes.
When Apple introduced the Signed System Volume (SSV) in Big Sur, the size of macOS updates rose to their highest ever, as the overhead required for each update reaching 2.2 GB for Intel models and 3.1 GB for Apple silicon. Since then, they have steadily improved in efficiency. This article shows how they have performed in Sonoma, and asks whether Apple has abandoned its Rapid Security Responses (RSRs).
To keep my charts clearer, I here show the two architectures separately.
Total update size
This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. That has made a significant difference for some updates for Apple silicon Macs, where the first reported update size has excluded additional architecture-specific overhead. RSRs have been excluded, as they’ve been duplicated in subsequent patch or minor updates. Lines shown are best fits by linear regression.
Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.
Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.
Big Sur took a total of 36.7 GB on Intel, and a remarkable 50.07 GB on M1; Sonoma has taken 14.1 GB on Intel, and 21.2 on M1. On Intel, Sonoma required 38% of the update size as Big Sur; on M1, that proportion was slightly higher at 42%. Apple silicon updates were 136% the size of those for Intel models in Big Sur; in Sonoma that ratio has risen to 150%.
Minimum update sizes were about 400 MB for Intel, and 820 MB for Apple silicon, which must be close to the overhead required for macOS updates for the two architectures. These reflect the size of the ‘Update Brain’ required to install each update, and all bundled firmware updates. The latter have been steadily reducing as Intel updates have supported fewer models without T2 chips, but have remained the same if not grown for the substantially larger firmware updates for Apple silicon’s Secure Boot.
Unscheduled updates
Sonoma reached version 14.6 without an excessive number of patch updates. The number of patch versions released between the x.0 and x.6 scheduled versions ranges from 4 (Monterey) to 6 (Bug Sur, Ventura), with Sonoma taking just 5, although 14.6 has been closely followed by 14.6.1 in what appears to be a bug fix rather than the first security update.
What has been surprising is that Apple has released no RSRs for Sonoma, not one. The last RSR was the second released for 13.4.1 more than a year ago, on 12 July 2023. RSRs were introduced to Ventura in May 2023 as a method of replacing some components of macOS that aren’t installed in the SSV but in separate cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. They were intended to let Apple promulgate important fixes to vulnerabilities in Safari, WebKit, and some other bundled components without waiting for a full macOS update. Unfortunately, Apple’s second RSR in July last year was fumbled badly when it broke Safari access to many popular websites including Facebook, and had to be replaced three days later.
Although it’s never clear when a patch update could have been issued as an RSR, Sonoma 14.1.2 should have been a candidate as it’s only reported to have fixed two vulnerabilities in WebKit, that appeared to have been addressed in Safari-only updates for macOS 12 and 13. It looks now as if Apple’s initial enthusiasm for RSRs has cooled, and they’re unlikely to be significant in the future.
Standalone updaters
Updates to macOS Catalina and earlier were also available in downloadable standalone installer packages. Apple discontinued those, amid much protest from users, when it introduced Big Sur. Although there were some suggestions that they might return in the future, as the new update mechanism matured, there has still been no sign of them. Currently the only form of updater available is the full macOS Installer app, typically over 13 GB in size. This remains a shortcoming compared with Catalina and earlier, but it appears that standalone updaters aren’t missed by most Mac users, or at least that Feedback to Apple has been insufficient to produce a response.
Major updates
Prior to macOS Ventura, upgrading to the first release of the next major version of macOS required downloading its full installer app. Although larger than necessary to perform the upgrade, it was relatively error-proof, as the user had to intentionally start the app’s installation process, which could also be cancelled once it was in progress.
Ventura was the first major version for which Software Update used a mechanism similar to that for minor updates, and didn’t download a discrete macOS installer app. As Apple hadn’t warned of that, it caught some users by surprise, when they found their Mac was being upgraded almost automatically. This was repeated with the release of Sonoma, and the problem compounded when some users appear to have been upgraded without their consent.
As Tom Bridge has pointed out, this requires smaller downloads that install considerably faster, but, on Intel Macs at least, don’t require user consent or authentication.
Apple is likely to employ the same update mechanism when it releases Sequoia and takes us on to the next cycle.
It’s the middle of August, the time when, if you’re not an Apple engineer or third-party developer, you’re most likely to be on holiday. To help you enjoy that, today I’m going to engage you in a little game I call What’s the time, Mr. APFS?
To play along with me, all you need is a copy of the latest version of Precize, version 1.15, available from here: precize115
from Downloads above, from its Product Page, or via its auto-update mechanism.
Precize update
Thanks to some questions from applice, who should really be spending more time watching the Olympics than worrying about file systems, this new version of Precize comes with significant enhancements in its datestamp reporting. First, it now gives datestamps with decimal seconds, for those who want to be truly precise, and it adds two new time fields, for Attribute Modification, and Access, as shown in the screenshot below.
Once you’ve downloaded the Zip archive, unZip it where it is, and move the Precize app from its folder into one of your Applications folders (that ensures it doesn’t undergo app translocation). Keep the Zip archive it came in, as we’ll use that in the game, whose rules are simple: all you have to do is roughly guess the times in each of Precize’s datestamp fields, for different files and bundles.
What are the times?
APFS stores four datestamps for each file and directory in its volumes, and the four fields shown in this version of Precize correspond to those four datestamps. There is a fifth that the Finder can display, the date and time that an item was added to its current location. That’s not derived from the file’s attributes, but from directories, and isn’t shown in Precize.
The four datestamps are:
Created, taken from the create_time value, the time that this item was created, given as the clock time corresponding to an unsigned 64-bit integer giving the number of nanoseconds since January 1, 1970 at 00:00 UTC, disregarding leap seconds.
Modified, taken from the mod_time value, the time that this item was last modified, likewise.
Attr Mod, taken from the change_time value, the time that the item’s attributes were last modified, likewise. Those attributes include permissions, for example, and changes made to extended attributes should also update this value.
Accessed, taken from the access_time value, the time that this item was last accessed, likewise.
By default, APFS is relaxed over how it records the last of these. Some other filesystems are strict, and change the access_time value every time a file is read. Instead, APFS only updates this if its value is prior to (earlier than) the mod_time value. You can change this behaviour by setting an APFS volume’s APFS_FEATURE_STRICTATIME flag, for instance when mounting it by using a command like mount -u -o strictatime
However, that’s not the default for APFS volumes. For example, inspect your Mac’s Data volume using the command mount | grep '/System/Volumes/Data '
and you should see something like /dev/disk6s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse, root data)
without any mention of the strictatime flag. List all mounted volumes using mount
and you’re unlikely to see any using strictatime.
File datestamps
Open the new version of Precise, so it’s poised waiting for you to drop a file onto its icon in the Dock. Then take a screenshot, and drop that file onto Precise’s icon. What do you expect the four datestamps to be?
This is an easy one for starters: the four times should be very close, and almost match the time given in the screenshot’s name. The first two should be Created and Modified, the latter perhaps a thousandth of a second behind, reflecting the time it takes from creation of the screenshot file to completing the save. Next comes Accessed, when macOS opened the file to perform its animation of the screenshot sliding away. Last of all should be Attr Mod, recording when all its attributes such as permissions were set in its destination folder.
Now copy that file to another volume. What do you expect those four datestamps to be there?
Created and Modified should remain the same, as those are preserved when the file is moved around in local file systems. But Attr Mod and Accessed should record the time that file arrived on the second volume, reflecting its new attributes and its access for the copy.
Now try a couple of harder questions. Drop the Zip archive that contained Precize onto the running app’s icon. What do you expect those four datestamps to be?
All four datestamps should record times close to when you downloaded that Zip file from here. Just as with the screenshot, Created leads, closely followed by Modified, with Accessed and Attr Mod trailing. Note that they’re all four very recent, subsequent to its download to your Mac.
Unzip that Precize Zip archive again and drop the Precize app within it onto the running app’s icon. What do you expect those four datestamps to be?
Now the Created and Modified values are taken from that app when it left my Mac here, but Attr Mod should be more recent, and Accessed is likely to be older unless you have accessed the app bundle since then.
What’s the time, Mr. APFS?
All the best games involve learning. I hope these have shown you how those four datestamps are set and changed. In summary:
Software like the Finder, when copying between local volumes, also copies most of a file’s attributes, including Created and Modified datestamps for consistency, even though it creates a new file in the destination. Attr Mod and Accessed are linked to the copy event, though.
Software like browsers, when copying from a remote server to a local volume, don’t preserve the file’s attributes, so all four datestamps correspond to the local arrival and creation of the download.
Archives such as Zip files preserve most of a file’s attributes, and reconstitute its Created and Modified values to those saved when the archive was created.
As a final exercise, using Precize, determine whether copying files by AirDrop between Macs behaves conservatively like copying between local volumes, or resets datestamps as downloading from the internet does. Why do you think that Apple designed it to work that way?
Despite the worst efforts of Elon Musk to destroy everything good that remains of Twitter, it came to my rescue yet again when I recalled a tweet from @L0Psec from 12 June. That had announced a new command tool he discovered in early macOS Sequoia betas that also solved the mystery of what had gone wrong last week in my MacBook Pro’s security data updates.
I hadn’t had time to investigate the new command back in June, but when I noticed that my beta-test system had failed to update to XProtect version 5271 and wouldn’t even offer that update, it occurred to me a tool named xprotect might cast light on this mystery. Sure enough, when it assured me that the update had been installed after all, I could piece together what had happened and search Apple’s release notes unsuccessfully for an explanation. At some time between 23 July when version 5270 was released, and 6 August when it was replaced by 5271, Sequoia’s mechanism for updating XProtect’s data had changed completely without so much as a brief warning.
In that period of a fortnight, XProtect stopped behaving as it had for the last 15 years, since it was introduced in Mac OS X 10.6 Snow Leopard in August 2009. The version number of XProtect.bundle in CoreServices became a relic of the past, and didn’t show that actually installed. Software Update and softwareupdate, which had happily delivered hundreds of previous updates, had now fallen silent about XProtect.
Macs running older versions of macOS still found and installed the latest version, but not those running Sequoia. When it did appear, among the many listed by System Information in Installations, it was named as XProtectCloudKitUpdate, implying it had been downloaded from iCloud using CloudKit. I have later confirmed that obtaining this update doesn’t require the user to be signed in to iCloud, and it has joined the army of maintenance services using iCloud servers.
Updating XProtect in Sequoia
If you’re not using the latest version of SilentKnight, which now does this automatically, you can check the version of XProtect data installed on your Mac using the command xprotect version
If that or SilentKnight reports an older version than expected, and you want to manually check and install any available update, rather than using softwareupdate, use sudo xprotect check
Then, if there is an update available, obtain and install it with sudo xprotect update
both of which will require you to authenticate, as they must be run with elevated privileges.
I am working on a new version of SilentKnight that will save you the trouble of using Terminal to do that. Details of this new command tool xprotect are available in its man page, or from xprotect -h
although neither explains how this has changed, or why.
Why change?
The early years of XProtect saw emphasis on blocking vulnerable and exploited versions of Adobe Flash Player, and its Yara detection rules developed only slowly. When Adobe finally killed Flash Player at the end of 2020, attention turned to XProtect’s role of detecting and blocking other malicious software when it was first launched.
Its Yara rules grew steadily, as did the size of its XProtect bundle. Version 2109 from 27 September 2019 was 228 KB, and had risen to 2.5 MB by the update to 2178 of 4 January this year. This growth has accelerated lately, and version 5271 released on 2 August reached a total of 3.2 MB. The number of Yara rules contained in that bundle has exploded since the start of this year, with version 2192 on 23 April adding no less than 74 new rules tackling Adload malware, all in a single update.
Releasing new versions through Software Update is a slow and complex process, geared better to low frequencies. Before 2020, XProtect had usually been updated every month, but this year alone there have been 20 updates in less than eight months. Updating XProtects’s Yara rules using iCloud should be quicker, more efficient, and capable of promulgating changes more frequently. Apple could issue new rules as they’re developed and tested, then provide summary updates for Sonoma and older macOS to catch up every 2-4 weeks.
Presumably, these new iCloud updates transfer their payload as binary data rather than verbose Yara text definitions. If they do use CloudKit, then they could directly update a Mac’s security database, much as apps using CloudKit already do, and as used to update notarization data.
Older macOS
Alongside its sibling XProtect Remediator (XPR), XProtect is the front line of Apple’s campaign against malware. XPR was introduced in macOS Monterey two years ago and backported to Catalina and Big Sur. As it’s more of a standalone service, that doesn’t appear to have required much change in those older versions.
This new delivery mechanism for Sequoia is more likely to require internal surgery to security sub-systems, and appears less likely to be offered in Sonoma or Monterey. There are still many Macs running older versions of macOS no longer receiving macOS security updates, and I expect Apple will want to continue offering them more traditional updates for the foreseeable future. Those will also enable security researchers to keep a watch on which malware XProtect can detect using the rules in its Yara file.
Informing beta-testers
I’d like to thank @L0Psec for being the only person to draw attention to what would otherwise have appeared a worrying situation, and to remind Apple of the need to keep beta-testers informed. We’re all keen to keep our test systems well-protected, and should have been warned of this change, and told of the new command tool, rather than hearing about it in the scarred remains of what used to be Twitter. I hope this will be rectified for the next public beta-release, or there could be an avalanche of Feedback reports.
It’s no good telling us that XProtect “uses YARA signatures, a tool used to conduct signature-based detection of malware, which Apple updates regularly”, then those updates are obfuscated.
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.
Apple has just released patch updates to bring macOS Sonoma to version 14.6.1, and Ventura to 13.6.9. There’s no update for Monterey, though.
There are no entries for these updates in Apple’s security release notes, which simply report “no CVE entries” for both. However, the matching updates for iOS apparently refer to important bug fixes, including one that prevented changing Advanced Data Protection settings. Whether that’s the same for Sonoma and Ventura is anyone’s guess.
There are no updates to firmware on T2 Intel models, or on Apple silicon, and Safari’s version and build numbers haven’t changed either.
The 14.6.1 update is just over 650 MB to download on Intel systems, and around 1.4 GB on Apple silicon.
Looking through the contents of the /System folder shows small build increments in the Security framework and some keychain-related files such as Keychain Circle Notification app. There are no other changes in /System or the bundled apps at all.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 141, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5271.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions add two further signatures to its long list of those for MACOS.DOLITTLE, these being qualified as DOFNPXR and DOFDLMARM.
XProtect Remediator adds a new scanning module for Dolittle, the same codename that has just had a family of 14 detection rules added in XProtect. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-141 and XProtectPlistConfigData_10_15-5271.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
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.
As I forecast only yesterday, Apple has today released macOS Sonoma version 14.6. According to its previous calendar, this should be the last release of the cycle featuring general bug fixes and any remaining enhancements. In previous years this has been released in September, just before the first release of the new version of macOS. This year, in September we could see either 14.7 or 14.6.1, Sonoma’s first security-only update.
Apple hasn’t provided any release notes at all for 14.6, although it did for the release candidate, where it stated that this fixes app crashes when running iPhone and iOS apps on Apple silicon Macs, and a complex bug resulting in the hardware video decoder not being used when it should have been.
Security vulnerabilities addressed total 54, of which several are bugs in open source code. These are detailed in Apple’s security release notes.
There are firmware updates for all Macs with T2 or Apple silicon chips, and probably several other recent Intel models. T2 Macs should now be running version 2022.140.5.0.0 (iBridge: 21.16.6074.0.0,0), and Apple silicon Macs iBoot version 10151.140.19. I will analyse other models and update the firmware tables here, and SilentKnight’s expectations, later in the week, to allow time to update.
Sonoma 14.6 has a build number of 23G80.
Looking at changes in the System volume, there are many minor increments in build numbers, including both public and private frameworks. Of the bundled apps, in addition to several minor build increments, the following appear more substantial:
Music updated to version 1.4.6
News to version 9.5
Photos a large build increment
Safari to version 17.6 (19618.3.11.11.5)
Stocks to version 6.2.3
TV to version 1.4.6.
In the /System/Library folder, APFS is updated to version 2236.141.1 and the FileProvider framework has a significant build increment.
These confirm that many small general bug fixes are included with the long list of security fixes, although there’s no sign of any new kernel extensions or private frameworks with exotic names.
Apple has just released the update to bring Sonoma to version 14.6, together with security updates to Ventura (13.6.8) and Monterey (12.7.6). I expect that there will also be a separate update to Safari for Ventura and Monterey.
The 14.6 update is around 2.2 GB for Apple silicon Macs, and 1.8 GB for Intel models.
iBoot firmware for Apple silicon Macs is updated to version 10151.140.19, firmware of Intel Macs with T2 chips is updated to version 2022.140.5.0.0 (iBridge: 21.16.6074.0.0,0), and Safari to version 17.6 (19618.3.11.11.5).
Significant bugs fixed include app crashes when running iPhone and iOS apps on Apple silicon Macs, and a complex bug in video decoding in which the hardware decoder wasn’t used when it should have been.
Security release notes for Sonoma reveal a total of 54 vulnerabilities have been addressed, including several in open source code, but none is reported as having been known to be exploited yet. Those for Ventura list 36, and for Monterey 32.
I’ll update this article with further details as they arrive.
Last Tuesday, as the uproar over the CrowdStrike catastrophe was still subsiding, and alongside the fourth developer beta of Sequoia, Apple quietly provided its first release candidate for macOS 14.6. Don’t be surprised if that ships early next week, alongside Ventura 13.6.8 and Monterey 12.7.6, making it the earliest release of the sixth minor version in the annual macOS cycle since Mojave. For the last four years, from Catalina to Ventura, the last full update marking the start of two years of security-only maintenance has taken place in September.
To put this into context, it’s worth revisiting how Apple numbers macOS versions and how that fits into its annual release cycle:
The first digits in the version number indicate the major version, currently 14 for Sonoma, which changes around September-October of each year with the start of each new cycle.
The second digit indicates the minor version, currently 5 for Sonoma, and starts from 0 with the first major release in September. Minor updates are scheduled well in advance, and culminate in the sixth as the last regular update (Catalina was an exception in running to 7), and the start of that version’s first year of security-only updates.
The third digit indicates the patch version, used for urgent unscheduled fixes between those minor versions. The previous release of Sonoma before 14.5 was 14.4.1, which fixed a few urgent bugs and security vulnerabilities. For security-only updates after the x.6 release, this marks each security update.
Thus the first year of Sonoma is expected to run from its first release as 14.0 on 26 September last year, through 14.1 to 14.6, its last full update, shortly before the release of Sequoia. Sonoma then enters its first year of security-only updates in 14.6.1, and its second year in the autumn/fall of 2025 with versions 14.7, 14.7.1, and so on, until it becomes unsupported after a total of three years.
Sonoma has been running early throughout its release cycle, starting with its first release, and squeezed in 14.2 well before Christmas. While this could indicate that Apple doesn’t intend putting it into security-only maintenance until after version 14.6.1 or even 14.7 in September, around the time of Sequoia’s initial release, that would mark a significant change in the annual cycle. You also have to wonder how many non-security fixes could be prepared for release during August, when most of Apple’s software engineers are fully extended in finishing off the major new versions of macOS, iOS, iPadOS, watchOS, tvOS and visionOS for release the following month.
I expect next week will bring the release of Sonoma 14.6, the last general update and start of its two years in security-only maintenance, together with Ventura 13.6.8 as the end of its first year of security-only fixes, and Monterey 12.7.6, its swan song as it becomes unsupported. Those should pave the way for Sequoia 15.0 in September, bringing support for a batch of new Macs featuring M3 and M4 chips, to include an updated Mac Studio, Mac mini, and MacBook Pros.
If your Mac is still running Ventura or Monterey and is supported by a more recent version of macOS, now is the time to make a decision about whether and when to upgrade. Even if Monterey does get one more final security update, it’s almost certain to fall well short of that provided for Ventura and Sonoma. If you were intending to upgrade to Sonoma, then it’s not likely to have any further general fixes after this forthcoming update, but only to receive security updates from August onwards.
It may seem strange, but each new version of macOS brings a hidden feature that determines which older versions of macOS are supported by software. That’s largely set by those targeted by the new version of Xcode that supports the new macOS, in its minimum deployment target. This article explains how that works, and why you’ll see an increasing number of updates that require Big Sur or later over the coming year.
The largest developers like Microsoft and Adobe operate their own policy for supporting older versions of macOS, and in most cases follow Apple’s unwritten rules, in supporting the current macOS release, and the two previous versions. So, once their apps are fully compatible with Sequoia, you should expect them to support macOS 13 Ventura and later.
Smaller and independent developers usually try to support a wider range of macOS versions, but as most use Xcode to build their software, they’re dependent on the deployment targets supported by Xcode. This is where it gets more complicated.
Xcode support
Alongside Sequoia in beta-testing is Xcode 16, due for release at about the same time. That runs on late versions of Sonoma (14.5 or later) and Sequoia, and is the first version of Xcode that can build apps that make use of new features in Sequoia, the latest SDK (software development kit) supported by Xcode 16. Apple doesn’t update older versions of Xcode to support newer macOS, so a developer who’s still using Xcode 15 generally can’t use features introduced in Sequoia in their apps.
To make this a bit more complicated, that isn’t always so. For example, my macOS virtualisation apps Viable and Vimy are built using Xcode 15, but when they’re used in Sequoia they can now create VMs that support Apple ID, a new feature in Sequoia. However, other new virtualisation features such as support for USB devices will only be available to virtualisers built using Xcode 16, as they require the Sequoia SDK, which isn’t available in Xcode 15. Similarly, we don’t yet know whether Sequoia’s new AI Writing Tools will work with existing apps built for Sonoma rather than Sequoia.
Each version of Xcode has four compatibilities:
The minimum macOS required to run that version of Xcode; for Xcode 16, that’s macOS 14.5 or later.
The latest SDK it supports; for Sequoia support, that’s Xcode 16.
The hardware architectures it supports; Apple silicon was first supported by Xcode 12 (ish), so that’s not important here.
The minimum deployment target, or the oldest version of macOS for which it has an SDK; for Xcode 14 and later, including version 16, that’s macOS 10.13 High Sierra.
Of those, it’s the last that determines which older versions of macOS can be supported by apps built with that version of Xcode.
Minimum deployment target
Xcode versions 12 and 13 have a minimum deployment target of macOS 10.9, so apps built with them could support macOS as old as Mavericks from 2013. When Apple introduced Xcode 14 there were many complaints that its minimum deployment target rose to macOS 10.13 High Sierra. Apple appears to have listened, and the new Xcode for Sequoia, version 16, keeps the same minimum deployment target of 10.13.
However, it’s still not that simple. Apple recommends that developers using Xcode 16 build for macOS 11 Big Sur, the oldest version provided in the popup menu used to set the minimum deployment target. To build for older versions of macOS, the developer has to type the version in. Surprisingly, at present at least, Xcode 16 is happy to build for macOS 10.12 Sierra as a target, although whether that would work in reality isn’t clear.
Thus, when a developer is picking the minimum deployment target, the oldest version of macOS supported by a new app or update, the new Xcode can still support 10.13, but nudges the choice to Big Sur.
Code in an app also has to be compatible with all versions of macOS from its minimum deployment target. If a developer sets that too low, then they may well have to write conditional code to cater for differences in features across the whole range of target versions of macOS. That’s determined by what the app does, and how it does it: an app working with a newer feature such as Live Text can’t use that in macOS older than Monterey, as that’s when it was introduced. Feature support becomes most critical with SwiftUI, which wasn’t introduced until Catalina, and has changed greatly since.
SwiftUI
Like all precocious youngsters, SwiftUI has seen extensive changes since its introduction in 2019. Prior to macOS 13, support for key features in macOS apps is sufficiently limited to make it quite a challenge for a substantial app to rely largely or completely on SwiftUI. Even more recent versions of macOS use different calls to the API. For example, adding colour to Text in macOS 13 and earlier is performed by setting its foregroundColor; from macOS 14 onwards, that has to be its foregroundStyle instead. That can be accommodated with conditional code if the developer wishes.
Don’t be in the least bit surprised if apps that have switched to using SwiftUI for their interface require a minimum macOS version of 13 or 14, and it may not be long after the release of Sequoia that you start coming across the first relying on macOS 15.
Summary
Apps from major vendors like Microsoft and Adobe are likely to limit support to macOS 13, 14 and 15 once they’re fully compatible with Sequoia.
Other developers should still be able to support back to High Sierra, although Apple is encouraging all to build for Big Sur and later.
Support for older macOS also depends on whether an app requires features only available in more recent versions of macOS.
SwiftUI apps are likely to be the exception, and require Ventura or Sonoma.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 140, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5270.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions have a single change, adding a DOFMVAD signature to its long list of those for MACOS.DOLITTLE.
No new scanning modules are added to XProtect Remediator, and there are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-140 and XProtectPlistConfigData_10_15-5270.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
XProCheck is one of my unique utilities, to the best of my knowledge the only app that checks whether your Mac has been running its XProtect Remediator (XPR) anti-malware scanner, and reports the results of its scans in full detail. I’m delighted to release a new version of XProCheck that improves both its checks and reports.
Apple introduced XPR two years ago, as a greatly enhanced replacement for its Malware Removal Tool, MRT, which is no longer maintained. XPR is installed on all Macs running Catalina or later, and normally performs two sets of scans, one as the user and the other as root, every 24 hours or so. It currently contains scanning modules for 22 different types of malware, and one to cover those previously included in MRT’s checks. Its scans will not only detect known malware, but will also try to remove (‘remediate’) those that it does detect.
Strangely, XPR doesn’t report detections or remediations to the user, but can report them to third-party security software using Endpoint Protection (Ventura and later). As far as I’m aware, though, few if any security products make use of that, leaving XProCheck as the only way to monitor XProtect Remediator scans and reports.
XProCheck version 1.6 brings one major improvement, in changing the method used to check log entries for XPR’s reports. Previous versions have used the log show command, but this new version now reads the log directly using the OSLog API. Although this does have a small memory leak that would only be significant if you were to run dozens of checks in succession, it brings considerable improvements in speed, particularly when checking scans over longer periods, and on Apple silicon Macs.
This version of XProCheck typically takes less than 60 MB of memory before running any checks, rising to less than 70 MB after it has completed its first check. That may rise by less than 1 MB with each subsequent check made before quitting the app, so is almost unnoticeable.
There are two more cosmetic improvements: XProCheck reports now also give the time of its checks in local time as well as GMT/UTC, and the width of the scanner name field is a little greater, to better accommodate CardboardCutout.
XProCheck version 1.6 runs on all Intel and Apple silicon Macs in all versions of macOS from Catalina to Sequoia betas, and is available from here: xprocheck16-1
from Downloads above, from its Product Page, and through its auto-update mechanism.
Login
