The administration often criticizes journalists, but the treatment of Shirish Dáte, a reporter for HuffPost, stands out.

© Doug Mills/The New York Times

Apple has just released an additional out-of-cycle update to XProtect, bringing it to version 5321. As usual, it doesn’t release information about what security issues this update might add or change.

This version has no changes from 5320 in its Resources property lists or Yara file. Indeed, the version number given in XProtect.meta.plist remains 5320, although those given in the bundle’s Info.plist and version.plist are 5321.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5321

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5321 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update

Apple has just released its weekly update to XProtect, bringing it to version 5320. As usual, it doesn’t release information about what security issues this update might add or change.

This version adds a single new Yara rule for MACOS.SOMA.OCENB, another for the vast Soma/Amos family.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5320

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5320 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update

As I explained a couple of weeks ago, log entries come in four flavours: regular, activity, boundary and signpost. These types have previously been distinguished by a single digit in the entry. Although the latter two aren’t commonly used, boundaries because they’re uncommon, and signposts because they’re seldom useful, activities do need to be distinguished from regular entries. This new build of LogUI uses emoji to do that, and brings improvements in exported entries.

Log list

Rather than display a single digit for the type of each log entry, LogUI now uses an emoji:

1. regular entries are marked with a right-pointing triangle,
2. activities with a softball,
3. boundaries with a clapper board,
4. signposts with a round pushpin.

Those make it much easier to scroll down through entries looking for activities, for example.

Rich Text export

Those are also shown in extracts exported to Rich Text Format files. Those exports have been improved to more closely reflect entries as they’re displayed in LogUI’s window, including the new type emoji, with the addition of extra fields for signposts.

Copy

The other form of exported entries are those copied from the list, by selecting them in the window and using the Copy command. Rather than trying to copy the full text contents of all the fields, this has previously brought a selection separated using tabs. In this version, the fields are expanded and use a vertical bar | as a separator, to provide
date | level | category | sender | process | subsystem | message or signpostName

Where an entry has no data for that field, it’s left empty. As signpost entries don’t have message fields, and the other three types don’t have signpostNames, the last of those depends on the entry type. This should make copied signposts more meaningful.

For example, a short regular entry might provide
2025-10-19 14:48:00.385306+0100 | info | SDNearbyAgentCore | CoreUtils | sharingd | com.apple.sharing | Checking active FT call count: 0
an activity
2025-10-19 14:48:00.902644+0100 | | | RunningBoard | runningboardd | | state update
and a signpost
2025-10-19 14:48:00.435671+0100 | | tracing | SkyLight | WindowServer | com.apple.SkyLight | FrameLifetime

LogUI 1.0 build 77 for macOS 14.6 and later is now available from here: logui177
from Downloads above, and from its Product Page.

Enjoy!

Apple has just released its weekly update to XProtect, bringing it to version 5319. As usual, it doesn’t release information about what security issues this update might add or change.

This version adds three new Yara rules. MACOS.SOMA.OCENA is yet another for the vast Soma/Amos family, and there are two for the far newer MACOS.ODYSSEY group, MACOS.ODYSSEY.SOCGO and MACOS.ODYSSEY.SEENA.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5319

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5319 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update

Some who use SilentKnight for the first time discover that their Mac has been running for months with one of its security systems disabled. As macOS doesn’t have a dashboard to warn you of such dangerous settings, you may not notice until it’s too late. This article explains how to check those essential security settings on Macs with T2 or Apple silicon chips, and how to put them right. Intel Macs without T2 chips are different, and are covered in a previous version.

Secure Boot

Running your Mac in Full Security ensures it gets full protection from its Secure Boot technology. In an Apple silicon Mac this prevents it from loading third-party kernel extensions, and requires recent approved versions of macOS. Check this in System Information by selecting the Controller item in its Hardware section, or in SilentKnight.

This is controlled in Startup Security Utility, accessed from Recovery. Note that it only works with the paired Recovery system, the one you normally use; Apple silicon fallback Recovery doesn’t have this ability.

If you need to run kernel extensions or other software that can’t be loaded in Full Security, use Startup Security Utility to set the Mac to Reduced Security, and enable kexts. Avoid doing this if at all possible.

Settings are different for Intel Macs with T2 chips, where there are three levels of boot security, and the most common reason for reduction from Full Security is to enable that Mac to boot from external drives, something that Apple silicon Macs can do in Full Security.

System Integrity Protection (SIP)

Since El Capitan, macOS has protected all its system files, even down to bundled apps, using System Integrity Protection. This should make it impossible for malware or other software to change those protected files. SIP is also required for a wide range of other security protection, and should be fully enabled unless you have a compelling reason for disabling it partially or completely. In Apple silicon Macs, its status is reported in System Information’s Controller item, but Intel Macs instead give it in the Software section. It’s also checked by SilentKnight and Skint.

You can turn SIP off, something very occasionally needed to perform certain essential tasks. Doing so requires you to start up in Recovery mode, enter a command in Terminal there, and restart; Apple silicon Macs also need to have their boot security reduced in Startup Security Utility before SIP can be disabled.

To enable SIP, start up in Recovery mode, open Terminal, and type the following command:
csrutil enable; reboot
Once that’s done your Mac will restart in normal mode, and you should confirm that SIP is reported as enabled.

If you ever do need to disable SIP, do yourself a favour and put a sticky note on your Mac’s display to remind you to turn it back on.

Gatekeeper/XProtect

Gatekeeper runs checks on apps when they’re opened, and those can include scans for known malicious software using XProtect. As part of your Mac’s frontline protection against malware, you should leave those enabled unless there’s a compelling reason to temporarily disable them. However, I don’t know of anywhere in the macOS GUI that informs you whether these checks are being performed, although they are reported by SilentKnight and Skint.

If it has been disabled, you may be able to enable it using the command
spctl --enable
but chances are that you will instead need to invoke
sudo spctl --global-enable
requiring you to authenticate using your admin password. Be careful with those commands: the hyphens before enable and global-enable aren’t long dashes, but two separate hyphens.

Signed System Volume (SSV)

When you install Big Sur or later, the vast majority of its system files are saved in its System volume. For your Mac to boot from this, it has to be turned into a snapshot, sealed using a tree of cryptographic hashes, and the master seal ‘signed’ by a hash, which is compared against that set by Apple. This signed system volume is extremely secure and thoroughly reliable. On Intel Macs, this is only reported in Disk Utility, but Apple silicon Macs list it in System Information as well. It’s also reported by SilentKnight and Skint.

The SSV should always be enabled. If it isn’t, you’ll need to re-install macOS.

FileVault

Intel Macs with T2 chips and Apple silicon Macs encrypt the whole of the Data volume on their internal SSD. By default, that uses an internally-generated key that’s used automatically when any user logs in. Although it provides good security in most situations, you’re far better off enabling FileVault, as that protects the encryption key with your password as well. This imposes no overhead on accessing encrypted data, and provides valuable protection for your data at no cost.

Check whether FileVault is enabled in Privacy & Security settings, where you can enable it if it’s not already turned on. SilentKnight checks it as well.

macOS and firmware

To ensure your Mac and its apps are best protected from malware, keep its firmware and macOS up to date. As those are updated together, Macs with T2 or Apple silicon chips that are running the most recent release of their major version of macOS will also be running the current firmware, which no longer needs to be checked separately. Check the version of macOS in the About This Mac command at the top of the Apple menu.

Apple lists current supported versions of macOS on its Security Releases page. Those, and versions of security data software, are also listed and detailed here on this page.

If your Mac is running an older release of macOS and its firmware, update them together using Software Update in General settings.

XProtect Remediator scans

This anti-malware scanner performs automatic background scans to detect and remove a wide range of malicious software. It’s normally scheduled to run at least once a day, when your Mac is awake but not busy, and supplied with mains power. You’re wise to check that its scans are being run correctly, and will probably want to know if it has detected and remediated any malware. SilentKnight and Skint run a quick check of its activity over the previous 36 hours, and XProCheck provides detailed reporting and analysis.

Over the last year or so, XProtect Remediator has been using a timer during its scans, and automatically cancelling them if a scan takes longer than allowed. On many Macs, most scans are terminated early, and that results in warnings from SilentKnight and Skint. If you’re concerned, check the reports in XProCheck, where you’ll see that plugin was cancelled with a status_code of 30, as is typical with the timer.

Check:

• the Mac boots in Full Security, if possible,
• SIP is enabled,
• Gatekeeper/XProtect is enabled,
• it has booted from an SSV,
• FileVault is enabled,
• it’s up to date with macOS,
• XProtect Remediator scans are taking place daily.

SilentKnight does all of those and more.

If there’s one topic that needs explanation currently, it’s how macOS updates XProtect’s data. Let me try.

Up to and including macOS Sonoma

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

The source of those updates is Apple’s Software Update Service, through the Software Update pane in System Preferences or System Settings, the softwareupdate command tool, or an app like SilentKnight. Left to its own devices, macOS normally checks for updates soon after starting up, and once every 24 hours running after that.

Early Sequoia

XProtect in macOS 15 prefers not to use the XProtect.bundle in its old location of /Library/Apple/System/Library/CoreServices, instead looking for XProtect.bundle in its new location, /var/protected/xprotect.

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

If you wanted that to happen immediately, then you could run the following command in Terminal:
sudo xprotect update
then enter your admin user’s password. The xprotect command tool would then complete the installation of that update from its old location into its new one.

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

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

Later, that changed and Apple started releasing updates via iCloud. By about macOS 15.3, xprotect update was no longer able to install XProtect in the new location, and that was only possible once that update had been released to iCloud, from where xprotect update could download and install it to the new location.

Late Sequoia and Tahoe

With the release of macOS 26.0 Tahoe, this changed again. Macs running the latest versions of Sequoia and any version of Tahoe (after 26.0 release) continue to update the old location in /Library/Apple/System/Library/CoreServices as before.

Updating the new location in /var/protected/xprotect can occur by two methods. A background service XProtectUpdateService can:

• ‘activate’ an update from the old location by installing a copy to the new location;
• use CloudKit to download an update available in iCloud and install it directly to the new location.

That service is scheduled to run once every 24 hours.

The end result can appear confusing, but is summarised in the diagram below.

There are two routes for XProtect data to be updated in the new location:

• XProtect in the old location is updated by softwareupdate, then XProtectUpdateService runs later and installs a copy of that update to the new location.
• XProtectUpdateService runs and detects an update available from iCloud, so downloads and installs that in the new location. That occurs even when the old location hasn’t been updated yet, but depends on the update being offered in iCloud.

Both of those updates run silently, and the only ways to check that the new location has been updated are to:

• check the version in /var/protected/xprotect,
• run xprotect version,
• use SilentKnight or Skint.

As far as the user is concerned:

• Updating XProtect in the old location is worthwhile, as it should enable XProtectUpdateService to update the new location from that.
• Running xprotect update in Terminal is only worthwhile if the new location hasn’t yet been updated, but that update has been released via iCloud, as confirmed using xprotect check.
• Either of the new update mechanisms should be run automatically within 24 hours of an update being released.

Summary

• In macOS Sonoma and earlier, XProtect updates come via Software Update, and are simple.
• In macOS Sequoia and later, XProtect updates are more complex, but should happen as if by magic within about 24 hours of their release.

Apple has released its weekly update to XProtect, bringing it to version 5318. As usual, it doesn’t release information about what security issues this update might add or change.

This version makes several changes to the Yara definition for MACOS.COMPLIANTPIRATE.DEFU, but doesn’t add any new detection rules.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5318

Sequoia and Tahoe systems only

This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5318 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update
However, if the regular update has been installed in the old location, XProtect is likely to update its new location from that. There’s nothing you can do to force that, but it may well explain why your Mac seems to have updated itself.

Updated 0450GMT 9 October 2025.

If you bought an M1 Mac with just a 256 GB internal SSD and have kept up with macOS upgrades and updates, should you be worried that it’s running out of space by the time it makes it to Tahoe? Dare you look at Storage settings to see how much of the SSD is now swallowed up by System Data? This article explains why macOS 26 shouldn’t devour the last of your SSD, and how you can ensure that it doesn’t.

What’s on your Mac’s internal SSD?

Internal boot disk layout is most complex in Apple silicon Macs, as theirs is divided into three partitions (or APFS containers). Two are hidden and contain pre-boot and other low-level support files, and amount to around 6 GB. The Macintosh HD partition then takes the lion’s share, the whole of the remainder. Even on a 256 GB SSD, that’s about 250 GB.

Volumes within Macintosh HD include:

• System, just over 12 GB,
• VM, varies in size according to how much virtual memory is swapped out to disk,
• Preboot, just under 8 GB,
• Recovery and others not normally mounted, a total of less than 2 GB,
• Data, whose size is determined by what you store there.

The system your Mac actually boots into isn’t the System volume itself, but a snapshot made of it, occupying the same space, plus a little extra for the snapshot’s metadata including its tree of hashes to form its seal and signature. Because this is a snapshot it uses the same data stored for the System volume, and doesn’t double that up.

This should allow your Data volume a maximum of 228 GB, less any space required by the VM volume. Although installation of a macOS upgrade or update will require substantial additional space, once that’s complete the space taken by the System volume and its snapshot should fall to little more than 12 GB.

What happens when macOS is upgraded?

In traditional macOS upgrades, the Installer app was downloaded first, and itself required around 13-15 GB. That was run, and expanded its contents to be installed onto the System volume, replacing much or all of it.

Updates work more economically, as they contain only the files that have changed, so far less than the Installer app. When they’re installed, they replace only those files changed in the System volume, ready for a new snapshot to be made from that, to be used to boot that Mac. So an update-style upgrade, as you should get when going from macOS 15.7 to 26.0, should require a much smaller download, a faster install, and less space to install the new version of macOS. However, the end result should be identical, with exactly the same files installed in the System volume, and exactly the same in the snapshot used when running.

Whichever is used, the installation process is similar. First, the files to be installed are expanded, then they’re written to the mounted System volume, with some going onto the Data volume as well. Once the System volume is complete, a snapshot is made of it, and that’s sealed using a tree hierarchy of hashes, culminating at the top of the tree in the seal.

What is System Data?

Storage settings scans the contents of the boot volume group, Macintosh HD, and divides the storage used into different categories like Applications and Podcasts. It appears to total those up and account for the remainder of storage used in the category System Data. That doesn’t include the size of the System volume, or its snapshot, but can include temporary files like caches, snapshots, and anything else it can’t account for in other categories.

Taking control

If there are substantial amounts of space that aren’t accounted for on your Mac’s internal SSD, and you want to reduce that, you need to account for it before deciding what to do about it.

First check for large snapshots. I hear repeatedly of Macs that turn out to have hundreds of GB being used by snapshots unnecessarily, and the current record is over 400 GB. The easiest place to check for those is in Disk Utility. In the sidebar on the left select the Data volume, then Show APFS Snapshots in the View menu for them to be displayed at the foot of the main view.

Backup utilities including Time Machine normally make a snapshot with each backup, and retain them for 24 hours, following which they’re automatically deleted. As snapshots can’t exclude folders in the way that Time Machine can in its backups, if you’ve been working with a couple of 100 GB VMs then they will be retained in snapshots even though you probably exclude them from being backed up.

Once you’re happy that free space isn’t being retained in snapshots, use a disk mapping utility like DaisyDisk or GrandPerspective to hunt down other large files and folders that you may not need. One reader here recently discovered that their iOS and iPadOS backups had taken over more than half the space on their Mac’s SSD.

Wait a day or two after upgrading

Installing a macOS upgrade also changes files on your Data volume, and may retain temporary support files. These are normally cleaned up in the next 24 hours, and you may be able to encourage that by starting your Mac up in Safe mode, leaving it a couple of minutes, then restarting it in normal user mode.

By a couple of days after the upgrade, your Mac should have returned to normal use of storage. If it hasn’t, check snapshots and go hunt that missing space.

Apple has released its weekly update to XProtect, bringing it to version 5317. As usual, it doesn’t release information about what security issues this update might add or change.

This version adds five new detection signatures to its Yara file. These include another newcomer with four signatures, MACOS.DAILYDUMPLING, and MACOS.SOMA.SEEND to add to the large Amos/Soma family.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5317

I apologise for the late announcement of this update, which seems to have been released after 22:00 GMT on 30 September, but was still incomplete here through the whole of today, 1 October.

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5317 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update

As promised earlier this week, I’m delighted to offer a new version of my log browser LogUI that provides a Diagnostics Tool to help you understand log folders and discover any problems with them.

Open its window using the Diagnostics Tool command in the Window menu, and you’re offered four tools at the top.

The first, Get Info, performs a simple analysis on the files in the selected diagnostics folder. By default, that’s your current live log, in the path /private/var/db/diagnostics, in your Data volume. After telling you how many log files there are in each of its three main folders, and the number of timesync files, it reports the date and time of the oldest Persist log file, marking the start of the continuous log record, in this case nearly 4 days ago.

You can use these tools on any diagnostics folder you can access through its dialog. This includes Time Machine backups, external boot disks, and other bootable systems. Don’t click on the Open button, though, until you’ve selected the diagnostics folder in the view above.

Locating the diagnostics folder in a Time Machine backup can be interesting, but once you’ve found it, LogUI will happily check it for you.

The Catalogue tool lists all the tracev3 log files in the folders inside diagnostics, starting with those in Persist. It gives each file’s creation and modification timestamps, indicating the range for log entries within them, their size in bytes, and an estimate of the period that file covers.

The Analyse tool extracts information from each of logd‘s statistics files, with the number of log entries broken down in frequency order. If you tick the CSV checkbox, they will be delivered in CSV format, ready to import into other software such as a spreadsheet.

The last of the tools, Save Text, saves the contents of the window to a text file for your records.

Further information about locations used for log files is in this article.

LogUI 1.0 build 74 is now available from here: logui174
from Downloads above, and from its Product Page.

Enjoy!

Apple has just released macOS 26.0.1 Tahoe, which fixes the problem upgrading to 26.0 on Mac Studio M3 Ultra models, and apparently fixes other urgent bugs.

For Apple silicon, the update is a 1.76 GB download.

Tahoe 26.0.1 fixes a single vulnerability, although Apple doesn’t report that it’s already being exploited. The same is also fixed in Sequoia 15.7.1, and in Sonoma 14.8.1.

macOS 26.0.1 has build number of 25A362, Safari version 26.0.1 (21622.1.22.11.15), and a Darwin Kernel version of 25.0.0. There has been no change in iBoot firmware, which remains at 13822.1.2.

As Apple hasn’t been forthcoming about what else has changed, here’s my list:

• Passwords app has gone from version 2.0 to 2.0.1, suggesting it has at least one significant bug fixed.
• AppKit framework has had an increment in build number, also suggesting bug fixes.
• CoreText framework likewise, with bug fixes for a higher build number, possibly related to the fixed vulnerability in font handling.
• Security framework has a substantial increase in build number, implying bug fixes there as well.

Otherwise, remarkably little has changed.

Updated 1910 29 September 2025.

One of the many fine details in macOS is its built-in support for a content caching service, both as server and client. This can be used for local distribution of macOS and other system updates, App Store updates, Apple media content such as Music and movie purchases, and iCloud content.

This appears to have originated as one of the new services added to Mac OS X Server 10.4 Tiger in April 2005, initially confined to a Software Update server. Apple’s online services were growing rapidly at the time, with the iTunes Store opening in 2003, and the first of its App Stores for iOS launching in 2008. Those were followed by the iCloud service in 2011. To cater for those, Apple added a separate Content Caching server by OS X Server 2 in 2012.

This shows the Software Update service in OS X Server 2 in 2012, with a list of some of the updates it had in its cache at the time.

At that time, a client Mac’s Software Update pane in System Preferences had to be pointed at the local server for that to be used instead of Apple’s. However, that didn’t work with App Store caching, for which the /Library/Preferences/com.apple.SoftwareUpdate.plist file had to be edited manually on each client to add a new property specifying the IP address of the local server.

macOS Server 5 in 2015 extended this further.

Features of the Software Update server then included the ability to limit the server’s bandwidth in its link back to Apple’s servers, and to control local network bandwidth used to transfer updates from the server to clients.

Amazingly, its original documentation is still available online here, and instructions for setting up clients remain here.

The Caching service worked with all content and apps provided by the Mac App and iTunes Stores, which of course included OS X updates, and is explained here. By this time, Macs and iOS devices connected to the local network would automatically find a server when it was running; there was minimal configuration for the server, and none for the clients.

When macOS 10.13 High Sierra was released in 2017, that brought update and content caching services to client Macs, and no longer required macOS Server, which was already in its terminal decline. These were configured in a new Content Caching feature added to the Sharing pane in System Preferences.

In essence, you designated one or more Macs as ‘parents’, to serve their cached content to ‘children’, which can themselves host caching services, to allow tiered setups. Initially, parents also needed to share their internet connection, required a minimum of iOS 10.3 for iOS devices, required a wired Ethernet connection to your router, and couldn’t sleep, so had to be run on mains power.

Although the content caching service has become quite widely used since, it’s never been as popular as it deserves. It remains remarkably simple to set up, as seen in these screenshots from 2020.

Clicking on the Options button let you set the cache location and its size.

Tabs were made available if you held the Option key before clicking the Options button, which then became Advanced Options. That let you set up clients, as well as other servers functioning as peers or parents, on more extensive networks.

These remain essentially the same today in Tahoe.

When Apple changed macOS updates in Big Sur, life became more complicated. When updating Apple silicon Macs, the first GB of macOS updates had to be downloaded direct from Apple’s servers, and it was only after that the remainder of the update could be obtained from a local caching server.

Apple has further extended the types of content that can be cached locally, to include

• macOS updates normally obtained through Software Update or the command tool softwareupdate;
• internet Recovery images from macOS 10.13.5 onwards when obtained in Recovery mode;
• apps and their updates supplied through the Mac and iOS App Stores;
• GarageBand downloadable content;
• iCloud documents and data, including Photos libraries;
• Apple Books;
• downloadable components for Xcode.

Most recently Rosetta 2, screen savers, wallpaper and AI models have been added to the list. Apple’s reference document is here.

Advanced server configurations are catered for by the command tool AssetCacheManagerUtil which can also provide performance information, and there are two additional tools available, AssetCacheLocatorUtil and AssetCacheTetheratorUtil. On the server, performance information is most readily accessed in Activity Monitor’s Cache view, which provides summary statistics for the local cache.

This includes the total size of data served for the last hour, 24 hours, 7 days, and 30 days. To view those graphically, the time period for the charts at the foot can be changed by using it as a popup menu.

These show what happened on my content caching server during the macOS 11.4 update in 2021, for which almost 30 GB still had to be downloaded from Apple’s servers, while just over 20 GB was served from its cache.

Over the last 20 years or so, Software Update and Content Caching services have been remarkably reliable, but in June 2022 there was a period during which updates to XProtect and XProtect Remediator failed to install correctly when attempted through a content caching server. Apple never explained what the cause of that was, but it was eventually fixed and hasn’t recurred since.

Then, out of the blue, iOS and iPadOS 26 introduced a new feature to identify and test a connected caching server.

To access this, in Settings > Wi-Fi tap the ⓘ button on your current active network, scroll to the bottom and tap Content Caches. Tap the active cache to see full details, together with a download test. Don’t bother looking for an equivalent feature in macOS 26 Tahoe, though, as it isn’t available yet. How odd.

No sooner have we recovered from upgrading and updating macOS to 26.0/15.7/14.8 than Apple has released the next round of betas. This article looks at what’s in store for us over the coming year, as far as macOS is concerned.

With pandemics hopefully behind us, Apple’s planned OS updates have settled into a more regular pattern. Release dates when Sonoma was the current version of macOS (2023-24) were:

• 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.

Over the last year (2024-25), Sequoia has been almost identical, allowing for the small vagaries resulting from our calendar:

• 15.0 – 16 September
• 15.1 – 28 October
• 15.2 – 11 December
• 15.3 – 27 January
• 15.4 – 31 March
• 15.5 – 12 May
• 15.6 – 29 July
• 15.7 – 15 September.

If Tahoe follows the same pattern, you can expect releases to occur on the following dates:

• 26.0 – 15 September 2025
• 26.1 – 27 October 2025
• 26.2 – 15 December 2025
• 26.3 – 26 January 2026
• 26.4 – 30 March 2026
• 26.5 – 11 May 2026
• 26.6 – 27 July 2026
• 26.7 – 14 September 2026.

If you’d like a week’s notice of scheduled updates, watch Apple’s Developer Releases newsfeed at feed://developer.apple.com/news/releases/rss/releases.rss for Release Candidates. For minor versions, those are normally released about a week before the intended final release, so RCs seen on 20 or 21 October are likely to be followed by the public release on about 27 October.

Those can of course slip a few days or even a week if there are serious problems remaining with a release candidate, and some may be rescheduled to coincide with hardware announcements. These are also the ‘minor’ version updates, and Apple is likely to intercalate ‘patch’ releases to fix any serious bugs or urgent security vulnerabilities. Those almost never go through beta-testing or release candidacy.

For those staying with Sequoia or Sonoma for the time being, those security updates are most likely on the same dates as those for Tahoe.

Finally, a reminder for those whose Macs are still running macOS 13 Ventura: the final security update to 13.7.8 was released on 20 August this year, and Ventura is no longer officially supported by Apple. If your Mac can run Sonoma or later, and you want continuing security updates, then you’ll need to upgrade it to Sonoma 14.8 or later.

Apple has just released its weekly update to XProtect, bringing it to version 5316. As usual, it doesn’t release information about what security issues this update might add or change.

This version adds nine new detection signatures to its Yara file. These include five with novel names:

• MACOS.SULFURSLAB.JS
• MACOS.FOXTAIL.DEST
• MACOS.FLAMINGOFEET.AR
• MACOS.COMPLIANTPIRATE.DEFU
• MACOS.TETRAGONE.FU

together with MACOS.ODYSSEY.SOBGO for the recently added Odyssey, and MACOS.SOMA.SEENB, MACOS.SOMA.SEENC and MACOS.SOMA.INGOBA for the prolific Amos/Soma family.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5316

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5316 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

It has been barely a year since XProtect changed from stalwart to bogeyman. Over the course of dozens of updates through to macOS Sonoma, if there was one security data update you could rely on, it was XProtectPlistConfigData containing the many rules for XProtect. They guarded us through the dangerous days of Flash Player, the perils of ransomware, and a succession of stealers.

Then in Sequoia that changed, and XProtect’s data became stored in two locations, each with its own update method. The traditional location in CoreServices continued to be updated through softwareupdated, while the copy in the new location in /var/protected/xprotect has been updated by XProtectUpdateService over a connection to iCloud.

With both locations in play, XProtect updates have become more complicated. Some updates only came for one location, such as versions 5273 and 5275 that were released only to Sequoia’s new location. To help us manage XProtect in its new location, Apple provided a command tool, xprotect. That can check which version is available via iCloud, and update that when the local copy was no longer the latest.

One valuable feature was that it could also use a copy in the traditional location to update the new location, in the event that version was more recent than that available from iCloud, but most recently that has been disabled. Now, if a Mac running Sequoia or Tahoe has successfully updated its traditional location but not the copy in the new location, the user is unable to do anything to rectify that, and has to wait until that update is made available from iCloud. Sometimes both are provided at the same time, but it’s also common for iCloud to lag the traditional version by an hour or more, sometimes even longer.

Last week, with the update to XProtect 5315, the day after many of us were preoccupied with macOS updates, something even stranger happened. At around 18:00 GMT on 16 September, softwareupdated became able to download and install that new version into its traditional location, enabling macOS versions up to Sonoma to update successfully. But no such update was made available via iCloud for Sequoia or newly upgraded Tahoe systems, not for another 24 hours. Over that period attempts to obtain or convert the update using xprotect update were unsuccessful.

However, some hours after the traditional update was installed by those who had upgraded to Tahoe, XProtect’s new location was silently updated to 5315. Its version number had gone bump in the night. But if the xprotect command tool couldn’t accomplish that for the user, how could macOS? Were these silent updates coming by telepathy or radio waves?

Although there was no record in any of the usual places, such as Installations in System Information, or even found by my app SystHist, the xprotect version command disclosed that my Mac mini had updated XProtect’s new location at 06:46 GMT on the morning of 17 September, enabling me to hunt that event down in the log.

That update had been accomplished by a background check scheduled and dispatched by DAS-CTS (I have corrected times here to GMT):
2025-09-17 06:46:42.615072 com.apple.duetactivityscheduler REQUESTING START: 0:com.apple.security.syspolicy.xprotect-update:7874AD

This in turn fired up XProtectUpdateService
2025-09-17 06:46:42.695517 com.apple.xprotect Connecting to XProtectUpdateService
2025-09-17 06:46:42.744182 com.apple.security.XProtectFramework.XProtectUpdateService XProtectUpdateService booting
2025-09-17 06:46:43.157255 com.apple.security.XProtectFramework.XProtectUpdateService Attempting to apply update: [private]
2025-09-17 06:46:43.191178 com.apple.security.XProtectFramework.XProtectUpdateService Update completed. Activated update [private]

So the XProtect update had been completed and activated at 06:46 that morning. But how, given that iCloud was still only offering the old version?
2025-09-17 06:46:43.193159 com.apple.syspolicy.activities Finished Xprotect update in 496.4100122451782 ms: Error Domain=XProtectUpdateError Code=2 "Activated update LocalUpdate[5315]" UserInfo={NSLocalizedDescription=Activated update LocalUpdate[5315]}
2025-09-17 06:46:43.193285 com.apple.syspolicy Sent CloudTelemetry event: Xprotectupdateresult

“Activated update LocalUpdate” can only mean one thing, that XProtectUpdateService did what xprotect update used to do, and used the copy of XProtect 5315 in the traditional location to update the new location, taking just under half a second. In addition, com.apple.syspolicy had sent news of that event to Apple via iCloud.

That didn’t work for my old iMac Pro, still running Sequoia, though, which had to wait for the iCloud version of XProtect data to be updated, and wasn’t using version 5315 until 20:17 GMT on 17 September, over 26 hours after its initial release.

Prior to Sequoia, all supported and many unsupported versions of macOS got the same XProtect updates, available immediately they were released through Apple’s software update servers. Just over a year later,

• Macs running Sonoma and unsupported versions of macOS could be updated as soon as the softwareupdated update became available, in the traditional way;
• Macs running Sequoia could only be updated 24 hours later, when the iCloud update was made available;
• Macs running Tahoe could have been updated at any time after the traditional update had been installed, until the update was finally made available through iCloud.

I’m so looking forward to the time when I don’t need to use SilentKnight, the xprotect command and my log browser LogUI to track XProtect updates, and when those become timely again.

If you have a Mac Studio M3 Ultra and want to upgrade it to run macOS 26.0 Tahoe, then I’m afraid you’re going to have wait for Apple to build a new release that will install on your Mac.

I’m very grateful to Ken who has tried unsuccessfully to upgrade from 15.7 to 26.0. There are plenty of others reporting exactly the same: the upgrade goes well until towards the end, then aborts and the Mac is restarted back into 15.7. The problem seems to originate from an error in its neural engine driver.

Having just taken a look through a comparison between kernel extensions shipped with macOS 15.6 and 26.0, there are several Apple silicon hardware kexts that seem to have gone missing in 26.0, although whether that’s the cause only Apple’s engineers should know.

Apple is advising all those affected to put their Tahoe upgrade on pause until it releases a new build that does fully support the M3 Ultra. Until then, 15.7 is the limit for Apple’s most powerful and expensive Macs yet.

Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5315. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds three new detection signatures to its Yara file, two for a new entry named Zuru as MACOS.ZURU.LOAD and MACOS.ZURU.BEACON, and the third as another Soma/Amos component named MACOS.SOMA.SEENA.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5315

Sequoia and Tahoe systems only

This update has finally been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5315 but your Mac still reports an older version is installed, you should be able to force the update using
sudo xprotect update

Update: as of 1100 GMT 17 September 2025, Apple still hasn’t released this via iCloud for Sequoia and Tahoe systems.

Further update: Sequoia and Tahoe systems are now receiving the 5315 update silently, without any change in the version reported by the xprotect tool. So don’t be surprised if your Mac gets updated without the xprotect tool knowing anything about it.

Further further update: over 24 hours after release of this update for older macOS, it has now been made available via iCloud, and the xprotect commands now work, for those Macs that still haven’t updated themselves.

Apple has just released macOS 26.0 Tahoe (build 25A354), together with security updates to Sequoia taking it to 15.7, and for Sonoma to 14.8. As expected, there are no further security updates provided for Ventura, which is now unsupported.

The upgrade to Tahoe is once again provided as an ‘update’ rather than a full Installer app. If you want to run the Installer app to upgrade, download it from the App Store rather than using Software Update. If you’re updating Sequoia or Sonoma and your Mac is capable of running Tahoe, be very careful to select the right update in Software Update.

The Tahoe upgrade weighs in at 7.7 GB for Apple silicon Macs upgrading from a recent version of Sequoia. For Intel Macs it should be 6.1 GB.

On Apple silicon Macs, iBoot is updated to version 13822.1.2. Intel Macs have their firmware updated to version 2092.0.0.0.0 (iBridge 23.16.10350.0.0,0). Safari is version 26.0 (21622.1.22.11.14). The Darwin kernel version is 25.0.0.

Security release notes are also available:

• Tahoe 26.0 lists 75 vulnerabilities fixed, none of which is reported as already being exploited.
• Sequoia 15.7 lists 34 vulnerabilities fixed.
• Sonoma 14.8 lists 38 vulnerabilities fixed.

Useful links

Prepare to upgrade macOS – what you should have done already
What should you do when an update goes wrong?
When you should use Safe Mode, and what it does
What to do when there’s something fundamentally wrong with an Apple silicon Mac
Eclectic Light software updates for Tahoe

Last updated at 1928 GMT 15 September 2025. My apologies for some previous incorrect versions, which were the result of an unintended update.

For the last three months, since Apple released the first developer beta of macOS 26 Tahoe, I’ve been fairly busy updating my apps so they’re ready for its release. This quarter of the year is usually quite busy, but the changes brought by Tahoe have required more work than any version of macOS so far. This article provides checklists of every one of my apps and command tools that I believe should be compatible with macOS 26, and in most cases I have tweaked and rebuilt to ensure that.

The first problem posed by Tahoe was its rough handling of app icons that it didn’t like, because they deviated from its standard square with rounded corners. This isn’t something to be ignored, as if you can’t recognise apps in the Dock, how can you use them?

Here are two icons for the same app viewed in Tahoe. The left one uses a traditional AppIcon.icns icon image, while that on the right is the same circular PNG that has been applied using Icon Composer and added as a .icon file for Tahoe. So every supported app has required a new icon to be designed for it, and incorporated into a new build. Here’s part of my beauty parade.

Unfortunately, the moment you rebuild an app with its new icon, its whole interface is also rebuilt to Tahoe’s new standards. Those not only include all those infernal rectangles with rounded corners, but many controls and elements are larger than in Sequoia. While this is implemented intelligently so as not to upset layouts when running in older versions of macOS, Tahoe’s new look can wreak havoc with windows and dialogs.

This demo, Mallyshag, looks the same in Sequoia above, but has become a mess in Tahoe (below) because of those changed control dimensions.

Those three buttons are significantly wider, so now overlap one another and are wider than the text box below. They need a careful overhaul before they’re ready for Tahoe. Conversion can also have unexpected side-effects: for example, I’ve had some selectable text fields changed to be editable as well.

Here are the 31 updated apps that I have equipped with a new icon and adjusted their interface for Tahoe:

• Alifix version 1.4
• Apfelstrudel version 1.6
• Cirrus version 1.16
• Cormorant version 1.6
• DelightEd version 2.4
• Dintch version 1.8
• DropSum version 1.2
• Dystextia version 1.9
• Fintch version 1.4
• LogUI version 1 build 70
• Metamer version 1.6
• Mints version 1.21
• Nalaprop version 1.4
• Podofyllin version 1.4
• Precize version 1.16
• Revisionist version 1.10
• SilentKnight version 2.12
• Skint and SkintM version 1.09
• Sparsity version 1.4
• Spotcord version 1.0
• SpotTest version 1.1
• Spundle version 1.9
• Stibium version 1.2
• SystHist version 1.21
• The Time Machine Mechanic (T2M2) version 2.03
• Ulbow version 1.11
• UTIutility version 1.4
• Versatility version 1.1
• xattred version 1.6
• XProCheck version 1.7

There are also my three macOS virtualisers for Apple silicon Macs, which require more than an overhaul. However, I regularly use these in Tahoe and believe they’re fully compatible, even if their icons will disappoint:

• Viable version 1.0.12 (b12)
• ViableS version 1.0.12 (b12)
• Vimy version 0.7 (fourth beta)

I intend working on those in the coming months, to update them and cast them into fresh interfaces.

I have also tested five of my command tools, and believe they too are fully compatible with Tahoe:

• alisma version 4
• blowhole version 11
• cintch version 3
• cmpxat version 4
• unorml version 5

At least they don’t have custom icons.

So that was the summer of 2025, in more nutshells that I had expected. I hope you still find these useful, and will report any problems you encounter.

With macOS 26 Tahoe due to be released on Monday 15 September, I’m delighted to provide version 1.09 of my simple security checker Skint and its menu bar sibling SkintM.

These new versions should recognise Tahoe correctly, and check its version against an updated database.

Skint and SkintM versions 1.09 are now available from here: skint109
from Downloads above, from their Product Page, and via their auto-update mechanism.

Note that, because of the way it (mis)handles Dock icons, Skint might prove to be one of the few apps you run in Tahoe that doesn’t conform to its standard icon format. I also resisted the temptation to make these version 26.

Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.

One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.

Emergencies

The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.

Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.

In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).

Reverting macOS

The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.

I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.

On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.

Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.

Checklist

• Check you’re prepared to use your disaster plan if needed.
• Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
• Make a full backup immediately before starting the upgrade.
• Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
• Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
• Revert an Intel Mac using a bootable external installer.
• Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.

Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.

Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5314. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version brings no changes in its text data files, specifically its Yara rules. Wondering if I might be missing something, I have also compared the general release XProtect files with those for Sequoia and Tahoe (delivered by iCloud), and they are identical too.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5314

Sequoia and Tahoe systems only

This update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5314 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

It’s now almost a year since macOS Sequoia changed security updates, and I’m still being asked how these work. I also suspect a few are wondering whether there will be any changes coming in Tahoe. This article summarises how these work at the moment, and are expected to continue.

Three XProtects

All reasonably recent versions of macOS have three different security features known as XProtect:

• The oldest XProtect scans code just before it’s run. This uses one or two XProtect.bundle items containing Yara rules that determine the known malware it can detect. Currently, those are updated once a week.
• The newer XProtect.app in /Library/Apple/System/Library/CoreServices is only used in Catalina and later. This runs daily scans to look for malware using its scanning modules, and is also known as XProtect Remediator as it removes malware. Currently, this is updated once a month.
• The newest and hidden Behavioural XProtect watches constantly for suspicious behaviour such as apps accessing folders used by Safari and other browsers, according to its Bastion rules. Those rules are contained inside XProtect.app and are updated with it.

So for the time being, you should expect your Mac to update XProtect’s bundle every week or so, and the XProtect app (XProtect Remediator, and Bastion rules) every month.

XProtect Remediator

Roughly once a month, your Mac should download and install a file named something like XProtectPayloads_10_15-155, where the last three digits are its new version number. This is delivered and installed automatically through Software Update, if you have it set to Install Security Responses and system files. You can also download and install it manually using the softwareupdate command, or, easiest of all, using my free SilentKnight.

Legacy XProtect

All fairly recent versions of macOS have a copy of XProtect.bundle in /Library/Apple/System/Library/CoreServices. This is also downloaded and installed using Software Update, softwareupdate or SilentKnight, and the file name is something like XProtectPlistConfigData_10_15-5314. In versions of macOS before Sequoia, this is the only copy of that bundle, and once that has been installed, XProtect is up to date.

iCloud XProtect

Almost a year ago, Apple changed XProtect in Sequoia, and since then Tahoe has followed suit. They not only have legacy XProtect with its XProtect.bundle in /Library/Apple/System/Library/CoreServices, but they have a separate copy of the same bundle in /private/var/protected/xprotect. If you compare those carefully, you’ll see differences, as the legacy copy is signed, but the other isn’t.

When XProtect is updated, Sequoia and Tahoe therefore download and install those two copies separately. The legacy copy is updated exactly the same as in older macOS, through Software Update, softwareupdate or SilentKnight.

The new copy of XProtect.bundle in /private/var/protected/xprotect can’t be updated by softwareupdate or SilentKnight, though. Updating the legacy copy doesn’t alter or update that, which is instead performed over a connection to iCloud. To check and update that copy, you can use the xprotect command in Terminal. The command
xprotect version
returns the version of XProtect installed in the new (iCloud-based) location, which can be different from the legacy copy. You can check whether an iCloud update is available using the Terminal command
sudo xprotect check
and entering your admin password when prompted to do so. If that version number is higher than that currently installed in the new location, then the command
sudo xprotect update
will download and install XProtect from iCloud into its new location.

Can the two XProtects interact?

In Sequoia and Tahoe, both versions of XProtect.bundle will eventually be downloaded and installed automatically. Sometimes, when you’re installing one, the other is also updated. That doesn’t occur because one updater can also update the other copy, but simply because the automatic update process has run. In the early days of Sequoia, the xprotect update command could update the iCloud version from the legacy version, but that stopped working many months ago.

Another behaviour that can appear confusing is when legacy XProtect updates but the iCloud version doesn’t. That often occurs soon after a new version is released, as it almost invariably is made available via Software Update first, so resulting in the legacy version being updated quickly. Sometimes the iCloud update isn’t made available for several hours later, and that may give the impression that updating the legacy version is somehow blocking the iCloud update. That’s easy to check using the xprotect check command: until that reports the new version is available, the xprotect update command won’t work.

How do I know when these updates are available?

I am sometimes asked where I look to check when XProtect and other updates are available, as if Apple publishes this information somewhere. It doesn’t. I use the same tools that you can use, SilentKnight to check for updates via softwareupdate, and the xprotect command tool for those delivered from iCloud. As soon as I find a new update, I install it here, update the databases on Github used by SilentKnight and Skint, analyse the contents of the update, post the announcement here, post that on X/Twitter, then update this blog’s System Updates page.

Do different Macs update differently?

All the code for these updates is contained in the copy of macOS installed in the SSV, the signed snapshot of the System volume that runs your Mac. For any given version of macOS, all Macs, both Intel and Apple silicon, have identical SSVs, although there are differences in their cryptexes and Data volumes. Thus, XProtect updates work exactly the same on all Macs running Sequoia 15.6.1 from my ancient iMac Pro to my latest Mac mini M4 Pro, and I check those with every update as well.

I hope you find these helpful.

Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5313. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds 4 new rules for components of MACOS.MISOMESA and 7 for MACOS.MISOMAGIC, both new codenames in the Yara file, it also adds a new rule for MACOS.SOMA.AUENC, another Soma/Amos component, and amends the existing detection rule for MACOS.DUBROBBER.CHBI.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5313

Sequoia and Tahoe systems only

This update has now been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5313 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

DropSum is my simple drag-and-drop utility for checking MD5 and SHA256 hashes, and using them to compare pairs of files to see if they’re identical.

This new version brings two changes:

• Text entered in its two text boxes, where you paste hashes, is now cleaned of any spaces and hyphens, and set in lower case, before being used as a hash, although it’s not altered in the text box. This should save you having to edit what you paste there. Thanks to Panda for requesting that.
• I have tried to improve readability when in dark mode in Sequoia and earlier. Thanks to EcleX for requesting this.

That said, the window’s appearance is a compromise between what looks best in Sequoia, and that in Tahoe. To see what I mean, here’s the same app, in its new version 1.2, in two versions of macOS, both in dark mode with Reduce Transparency enabled.

In macOS Tahoe there’s strong contrast throughout, and all text is readable, as it is in light mode.

Yet in macOS Sequoia, white text in unselected text boxes is shown against its orange background, rather than grey or black.

I have a feeling we’re in for an autumn of similar visual discrepancies appearing in other apps, whether or not they’ve been built for compatibility with Tahoe.

DropSum 1.2 for Big Sur and later, including Tahoe, is now available from here: dropsum12
from Downloads above, and from its Product Page.

Its MD5 hash is 9370f006d65eb3f6f65ab97dc78ce345
and SHA256 is f898b580138dc05d273c8b7f16321ad6d6754d76ecabf1c49fcac1d32bc156e6

Enjoy!

Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5312. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds three new detection rules: MACOS.SOMA.AUENB augmenting rules for the Soma/Amos family, MACOS.DUBROBBER.CHBI for another Dubrobber variant, and MACOS.ODYSSEY.LELI for an additional Odyssey variant.

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 and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5312

Sequoia and Tahoe systems only

This update has now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5312 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

As promised, this new version of my Spotlight indexing and search utility SpotTest extends its reach beyond the user’s Home folder, and can now test and search any regular volume that’s connected to your Mac and mounted in /Volumes.

By default, its searches remain restricted to the user’s Home folder, where SpotTest’s folder of crafted test files is installed. That applies whether you opt to use the search using its NSMetadataQuery tool, or the much faster option of the mdfind tool instead. If you want to search another mounted volume, click on the button for the app to check which volumes are available, then select one from its new Scope menu items. Volumes listed there exclude Time Machine backups and any hidden volumes whose names start with a dot, which will in any case be excluded from Spotlight indexing as they’re hidden.

This new version also fixes a weird bug that you’re unlikely to encounter in the previous version, but in rare circumstances could be infuriating. When searching using the NSMetadataQuery tool, if you had two windows open both with results from that tool, both would be updated with the same search results, and the time taken in them could rise to the absurd. This occurred because both windows were being updated with the data returned from the most recent search, as the NSMetadataQuery is shared in the app’s MainActor. After some fraught debugging, windows in this version ignore any search result updates initiated by other windows. I hope!

Volumes set in the Scope menu only affect search scope. Test folders are created in and removed from the user’s Home folder, and mdimporters are checked there as well. If you want to investigate indexing and search performance on other volumes, then you should manually create your own test folders as necessary. One quick and simple approach is to create a standard test folder in the Home folder, and copy that onto the volume(s) you want to test. A little later this week I’ll illustrate this in an article explaining how to get the best out of SpotTest and how it can help diagnose Spotlight problems.

I have taken the opportunity to improve SpotTest’s reporting of errors, such as trying to remove a test folder that doesn’t exist. I have also thoroughly revised the Help book, and added a page about search scopes.

SpotTest version 1.1 for macOS 14.6 and later, including Tahoe, is now available from here: spottest11
from Downloads above, and from its Product Page.

Enjoy!

Apple has just released urgent security updates to bring macOS Sequoia to 15.6.1, Sonoma to 14.7.8, and Ventura to 13.7.8.

Security release notes for these are already available, for 15.6.1, 14.7.8 and 13.7.8 Each refers to the same single vulnerability in ImageIO, which is apparently being exploited “in an extremely sophisticated attack against specific targeted individuals” using a crafted image file.

The download for 15.6.1 is about 1.56 GB for an Apple silicon Mac, and should be well under 1 GB for Intel. Time to update!