Apple has just released its regular weekly update to XProtect, bringing it to version 5323. As usual, it doesn’t release information about what security issues this update might add or change.
This version adds five new Yara rules in its TIMELYTURTLE series, for MACOS.TIMELYTURTLE.DYCASWOC, MACOS.TIMELYTURTLE.DYCASWOCB, MACOS.TIMELYTURTLE.LELINO, MACOS.TIMELYTURTLE.TRNO, MACOS.TIMELYTURTLE.DYHEOC, and a single new rule for MACOS.REALSTAR.VO, which appears to be a new genus of malware.
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-5323
Sequoia and Tahoe systems only
This update has at last 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 5323 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 22:00 GMT on 11 November, the update to 5323 has reappeared for download to the traditional location via Software Update or SilentKnight, and is available through the iCloud connection for Sequoia and Tahoe.
If you have updated your Mac to Tahoe 26.1, you may be blissfully unaware that it will now automatically download and install some security updates, regardless of its Software Update settings. Open Privacy & Security settings, scroll down to the end and you’ll see a new item, Background Security Improvements, that Apple has kindly turned on for you. There are matching new settings in iOS and iPadOS 26.1 that are also enabled by default.
Apple seemingly forgot to mention these when listing the changes in 26.1, and its documentation of these Background Security Improvements (BSI) is sketchy to say the least. However, the description there as “lightweight security releases for components such as the Safari browser, WebKit framework stack and other system libraries” is so similar to that for RSRs as “improvements to the Safari web browser, the WebKit framework stack, and other critical system libraries” that we can only conclude the BSI is a rebranded RSR.
What is an RSR/BSI?
Although almost all of macOS is contained in the System volume, turned into a snapshot that’s protected by a tree of hashes with a signature, then mounted as the Signed System Volume, there are additional components that are delivered in separate cryptex files. These are also heavily protected with signatures to verify their contents, and are mounted well after the kernel has booted. APFS then grafts them into the root file system so their contents appear in the correct places. There are currently two main cryptexes common to all Macs, one containing Safari and its WebKit components, the other with dyld caches supporting frameworks. Apple silicon Macs additionally have many smaller cryptexes to support AI and related features.
Because those cryptexes are separate from the SSV, they can be unloaded, replaced with updated versions, and reloaded without necessarily having to reboot the kernel, or go through any of the complex procedures to update macOS itself. Apple first tested this new type of update, a Rapid Security Response (RSR), in beta-releases of macOS 13 Ventura, and the first was publicly released for Ventura 13.3.1 on 1 May 2023.
How do RSRs work?
RSRs have been released using the regular Software Update mechanism, controlled in its settings, and can be uninstalled manually even if you have opted for them to be installed automatically.
To remove an RSR, you open System Settings > General > About, and look down for the macOS version. At the right of that line is an ⓘ button: click on it to see the dialog above, allowing you to uninstall it.
Why don’t we get RSRs now?
Apple proudly announced RSRs at WWDC in June 2022, and they were listed among the new features in Ventura: “Get important security improvements to your devices even faster. This isn’t a standard software update. These improvements can be applied automatically between normal updates — without a restart.”
Although the first in May 2023 seemed to go well, the next on 10 July was an embarrassing disaster. RSR 13.4.1 (a) fixed one WebKit vulnerability, but unfortunately it also changed the version number of Safari to 16.5.2 (a), which was reflected in its User Agent, so broke access to many popular websites including Facebook. That had to be rectified in RSR 13.4.1 (c) released three days later. And all three of these RSRs required the kernel to be rebooted after their installation.
Since then, as far as I’m aware, Apple hasn’t released any further RSRs, although they’ve still been referred to throughout its documentation.
Their greatest limitation is that they can only fix vulnerabilities that are confined to Safari, WebKit and other components that are delivered in cryptexes. More commonly, urgent security patches also require changes to software in the SSV, for which the only solution is a full update. For example, during the year that macOS Sequoia was current, it received six patch updates in between those scheduled. Of those, only two might have been suitable as RSR/BSI updates, as all the others required changes to the SSV.
How do BSIs work?
If Apple’s current account of BSIs is complete, the only control we have over them is whether they’re downloaded and installed automatically. If you opt for that, as Apple has set as the default, then you won’t be given any warning, or even informed when the BSI has been installed on your Mac. The only way you’ll be able to learn that is by trawling through the list of software installations in System Information, although Apple will post information about the BSI in its security release notes, following its release.
If there’s a problem with a BSI, such as that in the second RSR in July 2023, then there’s no option to uninstall the BSI and revert to a previous version of that cryptex, as there was with RSRs. However, Apple might decide to remove the BSI from your Mac.
Given the short and unfortunate history of RSRs, that might appear surprising.
Apple has just released an update to XProtect for all versions of macOS, bringing it to version 5322. At the same time there’s an update to XProtect Remediator for Catalina and later, bringing that to version 156. As usual, it doesn’t release information about what security issues these updates might add or change.
This version of XProtect adds one new rule to its main Yara file, for MACOS.TIMELYTURTLE.DYCAOC, and amends the existing rule for MACOS.SOMA.OCENA. It also adds a new XPScripts.yr file containing two rules using an osascript (AppleScript) interpreter, MACOS.OSASCRIPT.COTABR and MACOS.OSASCRIPT.COTAWA.
XProtect Remediator 156, which follows version 153, adds one new scanning module, XProtectRemediatorConductor. It will be interesting to see whether this refers to a new codename, or its role among other scanning modules.
The XProtect Behavioural or Bastion rules embedded in XProtect Remediator 156 amend Rule 22, but don’t add any further rules.
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 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 these as a named updates in SilentKnight, their labels are XProtectPlistConfigData_10_15-5322 and XProtectPayloads_10_15-156
Sequoia and Tahoe systems only
This XProtect 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 5322 but your Mac still reports an older version is installed, you should be able to force the update using sudo xprotect update
Update: the iCloud update was finally made available after 22:00 GMT on 5 November, over 24 hours after the release of this new version of XProtect.
The update bringing macOS 26 Tahoe to version 26.1 is substantial, and has a great many increases in build numbers, so this overview of its changes concentrates on those substantial enough to merit an increment in version number. The update itself varies widely in size, ranging between about 3-14 GB, which is unusual and hard to explain.
Apple’s security release notes report that it addresses a total of 90 vulnerabilities, none of which have been reported as being exploited in the wild.
There are firmware updates to bring Intel T2 Macs to 2094.40.1.0.0 (iBridge 23.16.11072.0.0,0), and Apple silicon Macs to iBoot version 13822.41.1. The build number for macOS 26.1 is 25B78.
Version changes seen in bundled apps include:
Audio MIDI Setup to 3.7
Books to 8.1
ColorSync Utility to 12.2.0
Freeform to 4.1
iPhone Mirroring to 1.5
Music to 1.6.1
News to 11.1
Passwords to 2.1
Safari to 26.1 (21622.2.11.11.9)
Screen Sharing to 6.1
Stocks to 8.1
Tips to 26.1 (routine for this update)
TV to 1.6.1.
Notable changes seen in /System/Library include:
several PDF Automator actions have build increments
Archive Utility has changed, with removal of a pref pane
SystemIntents is a new app added to CoreServices at version 1.0
two new driver extensions (dext) have been added, for AppleSunriseBluetooth and AppleSunriseWLAN
kernel extensions updated include many for AGX, as well as AppleDiskImages2 and AppleEmbeddedAudio
new kernel extensions include AppleSPINORFlasherDriver at version 1.0, and a family of AppleT8142 kexts to support the M5
APFS is updated to version 2632.40.15
added to DiagnosticExtensions are new items ScreenTimeDiagnosticExtension and ToolKitDiagnosticExtension
added to PrivateFrameworks are new SpotlightDiagnostics and ThumbnailsBlastDoorSupport frameworks
the RichText mdimporter is unchanged, remaining at version 6.9 (350).
As expected, the Spotlight bug described here recently remains unchanged in macOS 26.1.
One of the longstanding joys of the Mac has been how you can customise apps, giving them new icons and, in the past at least, even a few gentle tweaks. What’s unfortunate is that changing apps isn’t just for users. If we can alter them, so can an attacker, and the last thing any of us would want is for Safari or Preview to turn malicious. Over the years the scope for making changes to apps has therefore been reduced. This article explains how, and what we can still do.
To understand how customisation has been limited, we need to know what can and can’t change.
Signature
The most basic requirement of any app is that it’s signed. This provides a set of hashes that can be used to verify that none of its contents have been changed since that app was signed, and those hashes are hashed again to product code directory hashes, CDHashes, that are used to identify and recognise the app. Whatever we might customise in an app, its CDHashes must match its contents.
Certificate
Next comes the chain of trust established by the certificate used to sign the app. Developer certificates are issued by Apple as their Certificate Authority, so they each can be traced back through an Apple Intermediate certificate to Apple’s Root certificate, the chain of trust.
An Apple-issued certificate isn’t required for macOS to run an app, though. Because many Mac users build their own apps locally from open source, local or ad hoc certificates are also acceptable. However, anyone can sign an app with an ad hoc certificate, including an attacker, and, apart from the few malicious apps that have been signed using developer certificates, all other malware for the Mac is now ad hoc signed. As ad hoc signatures have no chain of trust, you can’t put any trust in them.
Notarization
Over the last few years, Apple has required developers to get their apps notarized. That involves ensuring the app meets certain security requirements, and is submitted to Apple to be checked to see if it contains any malicious code. Apps that satisfy those requirements are then issued with a ticket, that’s usually stapled inside the app’s bundle. That consists of the app’s set of CDHashes, again used to identify and recognise that app.
Although there’s no reason that you can’t notarize your own apps, and any you have resigned, that requires a paid-for subscription as a developer, putting it out of the reach of most. However, in an enterprise it can prove useful.
Launch constraints
Since macOS 13.3 Ventura, a new set of restrictions have been imposed on all apps and command tools provided as part of macOS, in launch constraints. These are rules that must be met for macOS to launch that app or binary, and include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch.
Launch constraints for bundled apps prevent them from being run from anywhere else. If you manage to make a copy of any of those apps, and that’s a challenge in itself, then macOS will prevent you from running that copy. This is made harder to avoid by the fact that these launch constraints are stored in an inaccessible Trust Cache, so the only way you could work round those rules is by turning System Integrity Protection (SIP) off, which in turn reduces Boot Security. That’s explained in more detail here.
Although third-party apps don’t get to use launch constraints or the Trust Cache, some may now have started using environment constraints, which can have similarly restrictive effects. The best way to discover this is using Apparency, which also includes a full guide to the constraints available.
Bundled apps
If you can’t remember which apps are bundled and which are not, look in /System/Applications, as that shows all those in the Signed System Volume, to which you need to add Safari, as that’s sealed in a cryptex.
Sadly, because of all their levels of protection, you can’t customise any of the bundled apps. Even copying them from their read-only SIP-protected location to a folder in your Home folder, which is difficult enough, that copy can’t be run, no matter what you do to it. You can make a Finder alias to the original app and give that a custom icon that will appear in Finder windows. But the app’s original icon will still be displayed everywhere else, including in the Dock, so it’s simply not worth the effort.
If you had ideas that you could replace all Tahoe’s new-style app icons with those from Sequoia, I’m afraid you will be disappointed.
Third-party apps
One customisation you can apply in complete safety is to replace a regular app’s icon. To do that, paste the new icon into the top left of its Get Info dialog, and further information is given here. This doesn’t affect any of the security protection of that app, as the new icon is added as a hidden Icon file at the top level inside the app’s bundle, which isn’t included in its CDHashes.
Any more substantial changes, even to the app’s resources, should break its signature and CDHashes, and macOS won’t like that.
If there’s a really good reason for making a change, and you can justify resigning the app using an insecure ad hoc signature, you could try stripping its current signature, changing the app bundle, then resigning it with an ad hoc signature. There are two cautions, though:
Any ad hoc signature is inherently insecure, and makes it simple for malicious code to tamper with that app.
This may break the app’s updating process, and if it doesn’t, any update will undo your customisation.
Before going any further, you’ll need to add Terminal to the list in System Settings > Privacy & Security > App Management, otherwise your commands will be unable to make any changes to the app. Then make a copy of the app you intend to change, so you can readily revert to the original. Once you’ve done that, open Terminal and use the command codesign --remove-signature MyApp.app
to strip the existing signature from the app MyApp.app. Note that two hyphens precede the remove-signature verb.
When you’ve made your changes, use the command codesign --sign - MyApp.app
to sign that app with an ad hoc signature.
Summary
Apps bundled in macOS from 13.3 onwards can’t be copied and run from elsewhere, preventing all customisation, and can’t be given custom icons.
Third-party apps can have custom icons applied in the normal way.
Any internal surgery inside the app bundle will break its notarization and signature, and shouldn’t be attempted.
If it’s an essential change, you may be able to strip the signature, make the change, and resign with an ad hoc signature.
Ad hoc signatures are inherently insecure, and should be avoided if at all possible.
Apple has just released macOS 26.1 Tahoe, together with security updates for Sequoia to bring it to 15.7.2, and for Sonoma to 14.8.2. There are also separate updates for Safari in 15.7.2 and 14.8.2.
The Tahoe update has at last appeared here in Europe, and is a hefty 4.7 GB for Apple silicon Macs.
Security release notes for 26.1 report around 90 vulnerabilities have been fixed, none of which have been reported as being exploited in the wild. Listings for Sequoia give about 54, and for Sonoma about 46.
Details provided by Apple beyond the general ‘bug fixes and updates’ include a new tinted option for Liquid Glass, that has already been widely discussed among beta-testers, Apple Music AutoMix support over AirPlay, better FaceTime audio in low bandwidth connections, and Communication Safety and Web content filters enabled by default for existing child accounts. That seems surprisingly little to squeeze into a mere 4.7 GB, and I suspect there will have been more extensive changes.
The build number for macOS 26.1 is 25B78. Firmware in Apple silicon Macs is updated to iBoot version 13822.41.1, and Safari is version 26.1 (21622.2.11.11.9).
I will post a detailed analysis of changes tomorrow, 4 November.
Important note for those intending to update to 15.7.2 or 14.8.2 rather than Tahoe:
To be certain the correct updates will be installed, in the Also Available section of Software Update, click on the ⓘ button to the right of the Update Now button for Other Updates and select the appropriate macOS update and Safari, deselecting the Tahoe update there. That should ensure you don’t inadvertently upgrade to Tahoe.
For good practical reasons, provided an app was signed using a certificate that was valid when the developer signed it, that certificate remains valid in perpetuity unless Apple (as the Certificate Authority) revokes it. But signatures in installers, including those for macOS and its components, must be valid when you run that installer. When any of the certificates used in Apple’s installers expire, Apple has to release a new installer with a certificate that remains valid into the future.
Six years ago, on 24 October 2019, Apple’s intermediate security certificate it had been using to sign all macOS installers and updaters expired. That also applied to most if not all Apple’s user signing certificates, but not the Apple Root CA. The consequence is that none of the installers provided with certificates expiring in 2019 will work on Macs running with a more recent date.
To check whether an installer is affected, double-click it to open it in the Installer app. At the top righthand corner of its window is a small padlock: click on that to review its certificate information. Most Apple installers refer to three levels of certificate:
Apple Root CA, the root certificate authority, should expire in 2035.
Apple Software Update Certification Authority provides the intermediate certificate, which may have expired on 24 October 2019.
Software Update, the user certificate, may also have expired on 24 October 2019.
Normally it’s number 2 above that is the most critical: once an intermediate certificate has expired, all chained user certificates become invalid. Currently, the intermediate certificate for all third-party developer certificates doesn’t expire until 2027. It’s unclear why Apple gives its own certificates an intermediate that expires after less than five years, and you might recall the previous time this happened was in February 2015.
If you have an old Mac and want to install or update macOS on it, using an old installer package with expired certificates will fail. To work around that, you’ll need to locate an installer with updated certificates that remain valid on the date that you perform that installation. There are several ways to accomplish that, with an excellent compilation given by Mr. Macintosh.
One popular way of working around this is to deliberately set your Mac’s clock back to a date before those certificates expired, such as 20 October 2019. Although that’s easy to do, it has far-reaching consequences that you should consider before trying it.
A great deal of macOS depends on the accuracy of date and time stamps. For example, it’s a general rule that the creation timestamp of a file or directory should be the same as or earlier than its modification and other timestamps. Some software used to make backups may become confused with file creation times that are not only more recent than their modification timestamp, but are also more recent than the current clock time. This can also feed through into the FSEvents database used by Time Machine to determine what it should back up, and more.
Macs suddenly running at some time in the past create difficulties in the log as well. You may well discover that log entries written at times set to be days or years ago can’t be found, particularly if you do later return that Mac to correct time. That’s another decision you need to think through carefully: once you have run the outdated installer, will you return the clock to normal timekeeping, so it leaps forward by more than 6 years?
As a general principle, don’t try fiddling with your Mac’s clock to pretend it’s a time in the past. That may leave you a mess that is too deep-seated to be put right.
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
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
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.
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
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.
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.
Login
