With macOS Tahoe already more than half way through its cycle, and Apple’s WWDC announced, now is a good time to plan your Mac’s calendar. This article peeks at what lies ahead for macOS over the next six months.
Since the pandemic disruption settled, minor version updates to macOS have become more regular. Looking across Sonoma, Sequoia and Tahoe, greatest variation in their timing has been in their x.3 and x.4 releases, that have varied between 22 Jan – 11 Feb, and 7 – 31 March, respectively. x.5 to x.7 have been more consistent, as they’re more tightly constrained by events including WWDC, the subsequent new beta season, and for some maybe even a vacation.
Those are summarised in the chart above, together with my predictions for the dates we should expect the remaining minor versions of Tahoe. Those should bring its cycle to look like:
26.0 – 15 September 2025
26.1 – 3 November 2025
26.2 – 12 December 2025
26.3 – 11 February 2026
26.4 – 24 March 2026
26.5 – 11 May 2026
26.6 – 27 July 2026
26.7 – 14 September 2026.
Where my forecasts are given in italics. Patch releases, such as 26.3.1, and BSIs occur outside that schedule. While we’re on the topic of BSIs, all indications are that Apple only intends to provide them for the current release of macOS, as it did with RSRs, which means that those Macs staying with Tahoe from 26.7 will no longer get them. It’s unclear how significant a loss that might prove.
WWDC this year is being held between 8-12 June, and will almost certainly bring the first developer beta release of macOS 27.0 (and all Apple’s other OSes). That’s likely to be made available to public beta-testers in early July. This is particularly significant this year, as it will be the first version of macOS to run exclusively on Apple silicon Macs.
For those with Intel Macs, or intending to remain with older versions of macOS, likely dates of release for scheduled security updates to Sonoma and Sequoia are:
15.7.6, 14.8.6 – 11 May 2026
15.7.7, 14.8.7 – 27 July 2026
15.7.8, 14.8.8 – 25 August 2026
15.8 – 14 September 2026.
The date at the end of August is possible, but less likely than the previous two. So far this year, security updates for Sonoma and Sequoia have been keeping reasonably close to those for Tahoe, in terms of vulnerabilities addressed, so the security gap between them has been rather less than in previous cycles.
However, the important message here is that it’s unlikely that Sonoma will receive any further security updates after the end of August this year. If your Mac is capable of being upgraded to Sequoia, now is the time to plan that, or it’ll all too quickly be September and your macOS will have lost its last support.
Similarly, if you’ve been holding back from upgrading to Tahoe in the hope that it will undergo interface improvements, I’m afraid that’s now looking increasingly unlikely. If it’s an Intel Mac capable of running Tahoe, there’s little point in avoiding making that decision any longer. There’s only limited time and scope left for improvement in macOS 26, with most engineers now more focussed on getting macOS 27 ready for WWDC.
Many discovered how long 5 minutes could last when they updated from macOS 26.3.1 to 26.4. Right at the end of its Preparation phase, Software Update showed there were only 5 minutes remaining for far longer. This article reveals what went wrong with that update.
My observations come from a Mac mini M4 Pro running a vanilla installation of macOS Tahoe, being updated from 26.3.1 (a) with the BSI installed, to 26.4. Times and details are taken from log extracts covering the final 14 minutes of the update, immediately prior to the reboot for its installation.
Preparation
At almost exactly 18:43:00, softwareupdated reported that the PREPARING_UPDATE phase was in progress, with 70% complete on the progress bar, and 20 minutes remaining. Periodic preparation activities were then reported in the log, mainly verifying components to be installed as part of the update. One of the longest of those, /usr/standalone/i386/Firmware.scap, took nearly 6.5 minutes alone, although you might wonder why that’s required on an Apple silicon Mac!
Eleven seconds later, softwareupdated changed the progress bar to display 10 minutes remaining, with 71% completed. Just 1.5 seconds later that changed again to display 5 minutes remaining with 94% complete. Six seconds after that, with 5 minutes still displayed, the log records 98.6% was complete.
The log and progress bar then remained stuck at 5 minutes remaining and 98.6% complete for the next 11 minutes and 47 seconds, before changing to 99.9% complete and no time remaining.
These are plotted in the chart below.
The final 5 minute period started at 18:43:12, and lasted until 18:55:04, as reflected in the long period of 98.6% completion (upper line) and 5 minutes remaining (lower line).
The “5 minutes” remaining actually took 12 minutes and 7 seconds, although log entries make it clear that preparation continued throughout that time, with further verifications and “Preparing system volume…”. Those details were reported as ActionText for progress monitoring, but curiously aren’t accessible to the user at the time.
Log entries record softwareupdated keeping detailed records of progress over this period, though. For example: 18:51:32.924688 softwareupdated PrepareUpdate PROGRESS (Continue) | state:{
ActionText = "Preparing system volume...";
ElapsedTime = 490;
ExpectedTime = 1335505;
PercentBytesComplete = "48.05373989419242";
PercentComplete = "4.701870471432042";
}
But those aren’t reflected in the progress bar.
Once the update had completed that preparation phase, extensive checks were performed to ensure it was correctly configured, and components were moved into place in the ‘stash’ to be used during installation. One second after successful completion, softwareupdated locked the controller state and waited for the reboot to start installation. Rebooting followed less than two minutes later.
What went wrong?
The macOS 26.4 update for Apple silicon Macs was large, and the work required to verify its contents and complete its preparation was incorrectly reported in both percent completion and time remaining. Even in smaller updates, some form of progress needs to be shown in the progress bar during these later stages of preparation, or users may be mislead into thinking the update has frozen or failed, and could for example restart their Mac to try updating again.
What should the user do?
When an update claims there’s only 5 minutes left, that could readily extend to longer, possibly on slower Macs as long as 30 minutes or more. Unless there’s evidence that the update has gone wrong at this stage, you should leave your Mac to complete it, as it almost certainly will. If you’re still in doubt and want to confirm that the update hasn’t frozen, open Activity Monitor and look for around 100% CPU from softwareupdated or related processes, and disk activity.
Unfortunately, there’s nothing the user can do to accelerate macOS updates.
One of the longstanding jokes in computing is how misleading progress indicators can be, and last week most of us had a timely reminder when we updated macOS. However much we might like a perfectly accurate linear indicator for macOS updates, this is one of those situations where the best we can expect is a compromise, as I tried to explain here.
Showing progress
There are two types of progress indicator, determinate and indeterminate, depending on whether the task is quantifiable and progress is measurable. Determinate indicators are always preferred, as they inform the user whether they need only wait only a few moments, or they have time to enjoy a leisurely meal, but that requires quantifiability and measurability.
The simple example is copying a file from one disk to another: although macOS doesn’t know in advance how long that might take, it can quantify the task as the size of the file to be copied, then keep track of how much of that has already been completed. When half the size of the file has been copied, the progress bar can be set to half-way along its total length, so providing an accurate indication of progress.
However, with some copy operations that breaks down: when copying a sparse file between APFS volumes, for example, only the sparse data is copied, not the whole file size. As a result, copying sparse files often results in progress bars that jump from a low point to completion in the twinkling of an eye. This also relies on the quantities involved being linearly proportional to the time required, an assumption that often breaks down when downloading from a remote server.
macOS updates
Updating macOS consists of a series of many tasks (see references at the end), of which only one, downloading, is both quantifiable and has measurable progress, and even that may be far from linear. Apple therefore has a choice of:
Display multiple progress indicators, appropriate to each phase. While that might work well for the download phase, it can’t work for others, including preparation, which is likely to take a period of several minutes at least.
Combine those into a single progress bar, as at present.
Use an indeterminate progress indicator, such as a spinning wheel, which would be reliable but unhelpful.
As downloading is the one task that is quantifiable and its progress is measurable, I’ll start there.
For this, the progress bar starts an an arbitrary 15%, and softwareupdated assumes the total size of that download is the magnitude of that task.
When the download has been completed, the progress bar reaches an arbitrary 55%, and its caption then changes to reporting progress with preparation.
There is a weakness in the assumption that becomes obvious when downloading from a local Content Caching server, as the final 1 GB or so normally isn’t provided from the cache, but has to be freshly downloaded from Apple’s servers. However, that isn’t normally apparent when caching isn’t available and the whole of the download comes from the same remote source.
For the remainder of the progress bar, between 0%-15% and 55%-100%, the task is neither quantifiable nor measurable. Instead, softwareupdated divides it into a series of subtasks, each of which has a fixed progress level. One list of subtasks and levels obtained from the log is given in the Appendix at the end.
The disadvantage of that strategy is that time required by each subtask varies with the update and the Mac being updated. Inevitably, computationally intensive subtasks will proceed more rapidly on newer and faster Macs, while those mainly constrained by disk speed should be more uniform. Large updates should take significantly longer, and that will vary by subtask as well.
The last 5 minutes
A particular problem with some more recent macOS updates, including that from 26.3.1 to 26.4 last week, has been unmarked progress over the final “5 minutes” of preparation. While indeterminate progress indicators continue to move over that period, and reassure the user that the task hasn’t ground to a halt or frozen, the progress bar shown had no intermediate points, making it easy to misinterpret as failure to progress. If this is going to be a feature of future macOS updates, Apple needs to insert some intermediate points to let the user know that the update is still proceeding.
Conclusion
A progress bar that combines different measures of progress, such as download size and substages, can work well, but only if the user is aware of how to read it. As we only update macOS a few times each year, that isn’t sufficient exposure, and how it works needs to be made explicit.
In most respects, lightweight virtualisation of macOS on Apple silicon delivers almost the same performance as running code on the host. That’s the result of having direct access to CPU cores and the GPU. However, earlier implementations in Monterey and Ventura performed poorly when accessing the Data volume in the Virtual Machine, with read/write speeds measured at 4.4/0.7 and 5.4/0.7 GB/s respectively, without FileVault or other encryption. In macOS 26.3.1 both RAW and ASIF encrypted disk images show disappointing performance particularly when writing to them. This article therefore re-evaluates VM disk performance to see if that extends to VMs.
Methods
Tests were performed on two freshly made 100 GB VMs in RAW format using the macOS 26.4 IPSW, running on a Mac mini M4 Pro in macOS 26.4. VMs were given 5 CPU cores and 16 GB memory, didn’t connect to an Apple Account, and were built and run in Viable and Vimy, both of which use the standard macOS API for virtualisation.
Performance was measured using Stibium’s ‘Gold Standard’ with 5 rather than 10 test sets, reading and writing a total of 26 GB in 80 files ranging in size between 2 MB and 2 GB. Following an initial write test, the VM was restarted before performing the read test. The first VM was configured with FileVault enabled, and the second with it disabled. In addition to those, standard read/write performance was measured as before on a 100 GB RAW disk image on the host, and on a 100 GB ASIF image, both being encrypted using 256-bit AES.
Results
Measured read/write speeds were:
Native SSD, FileVault on – 6.57/7.66 GB/s
VM, FileVault off – 6.62/5.91 GB/s
VM, FileVault on – 4.66/3.11 GB/s
RAW disk image, 256-bit AES – 2.82/1.59 GB/s
ASIF disk image, 256-bit AES – 2.85/1.76 GB/s.
With FileVault disabled, performance in the VM was surprisingly close to that of the host’s internal SSD, with a small reduction in write speed from 7.66 to 5.91 GB/s. That’s a huge improvement on previous results, with writes being almost ten times faster.
Enabling FileVault did reduce performance significantly, particularly write speed which fell to about half. However, those are still good enough to be acceptable for most purposes.
No significant change was seen in host disk image performance from those measured in 26.3.1, though, which remains substantially slower than the VM with FileVault enabled.
Conclusions
VMs are vulnerable if they don’t have FileVault enabled. Without encryption, sensitive contents would be relatively easy to access if the VM were to fall into the hands of an attacker. Enabling FileVault is thus potentially more important for a VM.
Thankfully, with such great improvements in VM disk performance, those hosted on an Apple silicon Mac’s internal SSD are unlikely to be slowed much by their disk performance.
This makes it the more puzzling that encrypted RAW and ASIF disk images should perform so poorly, and it’s disappointing to see that continues in macOS 26.4. Over the same period that VM disk performance has increased so impressively, that of disk images has headed in the opposite direction.
VMs and BSIs
If you tried installing the recent Background Security Improvement (BSI) in a macOS 26.3.1 VM, you were probably disappointed. In this respect, the VM didn’t work as expected. I was unable to find the BSI in its section in Privacy & Security settings. What did help was downloading it using SilentKnight, although that can’t install BSIs successfully. Instead, I restarted the VM and Privacy & Security offered to install the BSI at last.
Once installed, Privacy & Security offered to remove the BSI, but failed to do so, with SecurityImprovementsExtension reporting: Rollback failed: Error Domain=SUOSUErrorDomain Code=103 "Unable to remove Background Security Improvement" UserInfo={NSLocalizedDescription=Unable to remove Background Security Improvement, NSLocalizedRecoverySuggestion=Use Software Update to install the latest version of macOS.}
For the time being BSIs appear dysfunctional in VMs.
The update to bring macOS Tahoe up to version 26.4 is hefty at around 7.15 GB (more than double that if you’re unlucky), and reflects a great deal of bug fixes and improvements in almost every subsystem. Apple provides three good sets of release notes:
General release notes include the addition of an option to use compact tabs in Safari, Freeform’s new Creator Studio enhancements, and a facility for Purchase Sharing in Family Sharing. Oh, and the requisite eight new emoji.
Security release notes list over 70 fixes, many of which are significant, but none are reported as being known to be exploited in the wild at present.
The new build number of 26.4 is 25E246. The Darwin Kernel version is 25.4.0, and XNU 12377.101.15~1.
Apple silicon firmware is updated to a completely different version numbering system, and is now reported as mBoot version 18000.101.7. If you’re running SilentKnight older than version 2.14 (71), then it’s likely that it will crash as a result of this change in firmware version. Please use version 2.14 from here.
Firmware in Intel Macs with T2 chips remains with the previous system, and is updated from 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0) to 2103.100.6.0.0 (iBridge 23.16.14242.0.0,0).
Looking through the bundled apps and /System/Library, there are a great many increments in build numbers reflecting the extensive changes made. Here are a few of the more substantial changes found.
In bundled apps:
Books goes from version 8.1 to 8.4
Freeform, version 4.3 to 4.4
iPhone Mirroring, version 1.5 to 1.6
Music, version 1.6.3 to 1.6.4
Safari, version 26.3.1 (21623.2.7.111.2) in BSI (a) to 26.4 (21624.1.16.11.4)
TV, version 1.6.3 to 1.6.4
Audio MIDI Setup, version 3.7 to 3.8
Digital Color Meter, version 6.10 to 6.11
Screen Sharing, version 6.2 (758.1) to 6.1 (760.4), note the reduction in version number.
In /System/Library:
AGX kernel extensions all have build increments
AppleDiskImages2 kext has a build increment
AppleEmbeddedAudio kext and its plugin kexts have build increments
AppleIntel Graphics kexts have version increments
AppleStorageDrivers kext and its plugin kexts have build increments
APFS is updated from 2632.80.1 to 2811.101.1, suggesting a substantial change has been made
new private frameworks include ASMExclaveSupport, AccelerateOpt, AlwaysOnExclavesDaemon, AnteroAgent, AppRemoteAssets, AudioPasscodeDSP, BNNSOdieDelegate, CookingData, CoreTransparency, DynamicPrefetching, InAppFeedback, NanoPassKit, PartnerVisualSearch, a whole family of Unilog frameworks, and a group of iCloudWeb frameworks
mdimporters updated include those for Application, CoreMedia, Mail, Office, iWork but not RichText.
After seeing the new CookingData private framework, I looked out for RecipeKit, but was disappointed not to see it.
This is probably going to be the last such substantial update to macOS Tahoe, as much of Apple’s engineering effort is transferring to make macOS 27 ready for release as a beta at WWDC in early June.
Freeform joins Creator Studio, with advanced tools and a premium content library
Purchase Sharing in Family Sharing
and eight new emoji.
Security release notes for 26.4 list over 70 fixes, those for Sequoia 15.7.5 list about 56, and those for Sonoma 14.8.5 list about 50. None are reported as being known to be exploited in the wild at present.
Firmware in Apple silicon Macs is updated to a new mBoot firmware version numbering system, with the current version given as 18000.101.7. The macOS build number is 25E246, and Safari is version 26.4 (21624.1.16.11.4). Firmware in Intel Macs with T2 chips is updated from 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0) to 2103.100.6.0.0 (iBridge 23.16.14242.0.0,0).
If you’re running SilentKnight older than version 2.14 (71), then it’s likely that it will crash as a result of the change in firmware version. Please use version 2.14 from here.
I’ll be posting an analysis of what has changed later today.
Updated 09:15 25 March 2026 with firmware details for Intel Macs.
One of the biggest penalties in using disk images has been their performance, particularly when they’re encrypted. Although no longer offered in Disk Utility, UDSP sparse images encrypted using 256-bit AES typically read and write as slow as 500/100 MB/s when mounted from an SSD delivering 4.7/4.9 GB/s. In contrast, UDSB sparse bundles can achieve close to that native speed.
macOS Sequoia brought a new type of disk image, Apple Sparse Image Format or ASIF, intended to deliver the high performance of sparse bundles, with their efficient use of storage space, in a single file that can be hosted on file systems beyond APFS. As this is now well over 18 months old, this article considers whether it has achieved those goals, and should become the preferred type of disk image.
Methods
Each test image was created using Disk Utility 22.7 (2510) in macOS 26.3.1 (a) running on a Mac mini M4 Pro, on its internal SSD of 2 TB. Performance measurements were made using the ‘gold standard’ method in my free Stibium on disk images of 100 GB nominal size. This writes and reads a total of 53 GB in 160 files ranging in size between 2 MB and 2 GB. As performance is likely to change with use of the disk image, the following sequence of events was used:
Create disk image, which is mounted automatically, so unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, then delete the last 8 of 10 sets of test files, and unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, then delete all test files, and unmount.
Mount disk image, measure write speed, then unmount.
Mount disk image, measure read speed, and unmount.
These provide three pairs of read/write measurements:
for an empty, unused 100 GB disk image;
for a 100 GB disk image containing over 10 GB of existing files in addition to 53 GB of test files;
for an empty 100 GB disk image that had previously contained about 66 GB of test files that had been deleted.
Disk image sizes were also measured when unmounted, using Precize or the Finder’s Get Info (for sparse bundles).
The three types of disk image tested were RAW (UDRW), UDSB (sparse bundle) and ASIF (sparse image). Each was tested fully when unencrypted, and test 1 was performed on an image encrypted using 256-bit AES.
Results
The best and most consistent performance was achieved by UDSB sparse bundles, as expected. Their read speeds were 6.13, 6.12 and 6.19 GB/s, and write 7.62, 8.03 and 7.79 GB/s for the three separate measurements, and 5.09/5.23 GB/s read/write when encrypted. When first created, the sparse bundle only occupied 32 MB on disk, but by the end had grown to 3.99 GB even though empty.
The RAW disk image, formerly known as UDRW, also largely performed as expected. Read speeds were 6.09, 6.10 and 6.08 GB/s, and write 10.11, 9.86 and 10.11 GB/s. Initially it only required 5.78 MB on disk, rising to 621 MB at the end. However, its performance when encrypted was disappointing, at 2.84/1.58 GB/s read/write.
ASIF disk images were good, but also ran into problems when encrypted. Unencrypted read speeds were 5.99, 5.88 and 5.85 GB/s, and write 9.55, 8.93 and 9.64 GB/s. When encrypted, those fell to 2.82/1.72 GB/s read/write, no better than the RAW disk image. The image file size started at 26.8 MB on disk when empty and unused, and returned to 954 MB when empty at the end.
To confirm that ASIF performance when encrypted wasn’t an anomaly, I repeated that pair of tests on a MacBook Pro M3 Pro running 26.3.1 (a), and obtained similar results at 2.63/1.52 GB/s read/write, using a 10 GB ASIF image with one-tenth of the tests, giving 3.32/1.65 GB/s, and using Blackmagic, which gave 2.92/1.15 GB/s read/write. Although there is variation, they appear remarkably similar.
Test 2 results are summarised in the table above, for ease of comparison, and with the earlier results from macOS 26.0 below.
What has gone wrong with encrypted writes?
Although most of the test results in macOS 26.3.1 are very similar to those from 26.0, performance when using 256-bit AES encryption has fallen for all three disk image types, and most significantly in write performance for RAW and ASIF images, which have reduced from 4.3 to 1.58 GB/s (RAW) and from 3.9 to 1.72 GB/s (ASIF). The magnitude of those reductions is sufficient to have obvious impact on their use. Compared to native write performance using FileVault of 7.66 GB/s, those two types of disk image are pedestrian in the extreme, turning that blisteringly fast SSD into the equivalent of 20 Gbps over USB 3.2 Gen 2×2.
It’s possible that this dramatic reduction in encryption performance may have resulted from a change to address a vulnerability, but I’ve been unable to identify an entry in Apple’s security release notes that might correspond to such an event. I will repeat these tests once the update to macOS 26.4 has been released, in the hope it might be reversed.
Which disk image type?
When their folder-based structure is acceptable, UDSB sparse images remain the disk image type of choice, for their consistent high performance even when encrypted.
There is little to choose between RAW and ASIF disk images when a single file solution is required. ASIF images are portable to other file systems that can’t support APFS native sparse files, although curiously they too are flagged in APFS as being sparse files. As their sparseness isn’t dependent on APFS trimming habits, they are now an alternative that can be used on network storage and NAS. However, those able to use sparse bundles should continue to do so, particularly if using encryption.
If there’s one thing I’ll remember macOS Tahoe for it’s brilliant engineering inside a shockingly flawed interface. Last week’s first Background Security Improvement was yet another example of that trend.
I had enthused about its predecessor the RSR three years ago, although it was sent to the naughty corner after an updated version of Safari told Facebook and other popular sites it wasn’t who they expected. After that trauma, most users shunned RSRs, and it seems engineers who dared mention them were strapped to the front of an F1 car and driven round until they recanted.
Thankfully, RSRs were only put on pause before being rebadged as Background Security Improvements or BSIs, an Orwellian turn of phrase that skilfully avoids the word update despite the fact that they’re still discovered, downloaded and installed by softwareupdated. Now I’ve had a chance to give a fair account of the first public BSI, I can consider what’s wrong with their current implementation.
Location
BSIs are controlled not in Software Update settings, but in their own section at the end of Privacy & Security. As such, they are the only macOS update there, and all others remain in Software Update where they belong. This misleads users, and Software Update reports that Your Mac is up to date when it isn’t, because there’s an outstanding BSI available.
Not only that, but users naturally assume that when Software Update settings have Install macOS updates disabled, no macOS updates will be installed automatically. Little do they realise they can still get a BSI without being asked.
BSIs are currently misplaced in System Settings, and their controls should be moved back to Software Update where RSRs were.
I fear the reasoning behind hiding BSIs among strangers in Privacy & Security was to ensure most Mac users would leave BSIs to be installed automatically. It’s no coincidence that, in addition to this hiding, the automatic installation of BSIs was enabled by default when upgrading to macOS Tahoe. This reeks of deliberate deception.
Control
There is a single on-off toggle provided, to Automatically Install BSIs. Apple explains that “if you choose to turn off this setting, your device will not receive these improvements until they’re included in a subsequent software update.” Thus the user is given a forced choice between macOS deciding when to install an available BSI, or not being notified about that BSI at all.
As with other macOS updates, the user must be given the option to be notified when a BSI is available, and to make their own choice whether and when to install it.
The alternative for users is to disable Automatically Install, watch for news of BSI releases, and, if they wish to receive one, to enable that setting, download and install the BSI, then disable the control again. For many Mac users, that appears to be the best option in the absence of better support.
Although the control is titled Automatically Install, its behaviour is different. When a BSI is found to be available, macOS doesn’t automatically download and install it, but waits for the user to click on the Install button, then to authenticate.
However, if the user isn’t aware that BSI is available, or chooses to ignore it, automatic installation does appear to occur without the user being informed until the Mac is just about to restart, and no authentication seems necessary after all.
This behaviour is the greatest deterrent to users, as it effectively means that their Macs could restart unpredictably with almost no warning, resulting in data loss and disruption to their work. That’s completely unacceptable, and will ensure many will disable BSIs as a precaution to avoid the possibility of data loss. This aversion could be addressed simply by allowing the user full manual control over whether and when a BSI will be installed.
Progress
Despite softwareupdated monitoring progress through the download and preparation phases, the user is shown an indeterminate progress spinner, rather than a progress bar, which would at least give better warning of the restart that is coming. Although much briefer than a full macOS update, a progress bar should be displayed for the download and preparation phases of a BSI.
Restart warning
All previous RSRs, and this first BSI, have required restarts to complete the update. Yet at no time during this BSI was the user told that would be necessary. A notification was displayed a few seconds before the restart, but gave insufficient notice for the user to make any preparations.
It’s essential that information given about the BSI states clearly if a restart will be necessary, and the user is given the same one-minute countdown provided in macOS updates. Bizarrely, the one place that a restart was mentioned is in the dialog to remove a BSI.
Information
Apple’s current support note on BSIs is woefully inadequate, as is obvious by the content of this article. What would appear to be additional information in the BSI settings, marked with the ⓘ Info button, isn’t informative at all, but provides the means to remove a BSI, which is at least an improvement on RSRs, which unaccountably hid removal in the About settings. A more appropriate button should be provided.
BSIs are also only currently covered in the US English version of Apple’s Platform Security Guide. All other localised versions, including British and Canadian English, still contain the outdated section on RSRs. Fortunately, as their content is almost identical, this is revealing rather than misleading.
Version numbering
Ignoring RSR and BSI version numbering, macOS has in recent years achieved clean and systematic version (and build) numbering, without the excesses of the past. By adopting a parenthesised letter as the identifier of a BSI, comparison is clumsy and prone to error. ProcessInfo.processInfo.operatingSystemVersion doesn’t contain a field for the BSI identifier, which is only offered as part of the full string in ProcessInfo.processInfo.operatingSystemVersionString. Version numbers like 26.3.1 (a) and build numbers of 25D771280a are irregular and unnecessary.
Recommendations
BSI controls should be removed from their hiding place in Privacy & Security and put alongside all other macOS updates in Software Update settings.
An option should be provided so that users are informed of the availability of BSIs without any obligation for them to be installed automatically.
Behaviour of the Automatically Install button should be described explicitly to the user. Does it automatically install, and if so, in what circumstances will the user not be so informed?
BSI download and preparation should be accompanied by a progress bar similar to that for a macOS update.
When a BSI requires a restart to complete its installation, the user must be informed of that before they consent to the BSI being downloaded.
When a BSI install is ready to restart the Mac, one minute’s warning notification should be given, just as in macOS updates.
The BSI support note should provide full details, not a sketchy outline.
The button to remove a BSI shouldn’t use the ⓘ Info symbol, but something more appropriate to its purpose.
Apple’s Platform Security Guide should be updated in all its online versions. Is it really that hard to translate from US English to British English?
Version and build numbering should be redesigned to be more consistent and better accessible in the API.
Despite having over three years to get them right, BSIs are a worse mess than RSRs were in Ventura. This is a great shame as their technology is still brilliant, but their current interface is shockingly flawed in so many respects.
Since the introduction of the Signed System Volume in Big Sur, the great majority of macOS has been strongly protected. So strongly that applying the smallest security patch has required the full might of a macOS update. There are times when something more lightweight enables Apple to promulgate urgent patches swiftly and efficiently, and that’s what a Background Security Improvement or BSI does.
This was set up when macOS Monterey introduced cryptexes to contain Safari, its WebKit supporting library, and the large dyld caches for general support in Frameworks. Cryptexes are cryptographically sealed disk images that aren’t mounted like other volumes, but are grafted into arbitrary locations in the file system. In Ventura they were used for Rapid Security Responses (RSR), in many ways indistinguishable from BSIs.
This week’s first BSI for macOS 26.3.1 is a good example: it fixes one serious vulnerability in WebKit. Rather than building that into a full update to 26.3.2, because it only requires changes in the cryptex containing Safari and WebKit, this BSI swaps out the existing App cryptex and replaces it with a patched one. For those who don’t want to install BSIs, those same vulnerabilities should be fixed in the next set of security updates to macOS.
Controls
Look in Software Update settings, and you’ll see no mention of any BSI, and that will claim your Mac is up to date, even though it’s not.
BSIs are controlled in their section listed close to the foot of Privacy & Security settings. If you want your Mac to be offered BSIs when they’re available, you must enable Automatically Install first. Despite those words, BSIs don’t appear to install in the least bit automatically, and you should be offered those available for the installed version of macOS. When you’ve chosen to download and install one and authenticated, you’ll see a progress spinner rather than a bar.
As soon as downloading and preparation are complete, you should be given a few seconds before your Mac restarts to complete the installation. This is all very brief, but once you’ve authenticated to start the process, it will run through to completion automatically.
Once your Mac has restarted, you always retain the option to remove any BSI and return to an unpatched cryptex. To see that, click on the ⓘ Info button on the right.
If you decide you want to remove the BSI, your Mac will need to be restarted.
Problems
If you know a BSI is available but Privacy & Security settings appear unable to find it, something I’ve encountered in Virtual Machines, try running SilentKnight. Although BSIs aren’t controlled in Software Update, they do still use the same softwareupdate system used by SilentKnight. Normally you shouldn’t try to install BSIs using SilentKnight, as installation will fail. However, you can turn this to your advantage when a BSI is being elusive.
Once SilentKnight has downloaded and failed to install the BSI, you should be notified of that failure. Restart your Mac, give it a couple of minutes to settle once you’ve logged back in, and open the BSI section in Privacy & Security settings again. The downloaded BSI should now be available, and shouldn’t even need to be downloaded.
If you think a BSI has caused another problem, such as instability in Safari, use the ⓘ Info button to remove that BSI.
Installing a BSI does weird things to the macOS version and build numbers, and those can break scripts and possibly some apps. While ProcessInfo.processInfo.operatingSystemVersion doesn’t contain a field for the BSI letter, ProcessInfo.processInfo.operatingSystemVersionString does return a full version description including the BSI letter and extended build number. In Terminal, sw_vers -productVersion returns the regular version number without BSI, while sw_vers -productVersionExtra returns the BSI designation alone.
Currently, SilentKnight and Skint ignore BSIs, and won’t inform you if you could have one installed except by listing it as an available installation, nor will they check whether your Mac is up to date with the latest BSI. Experience from RSRs in Ventura shows that trying to track lightweight updates like RSRs or BSIs is only going to annoy those who don’t want to install them, and as they can change in a short period, they are hard to track reliably. SilentKnight does report the full version and build number, and SystHist lists details of all BSIs that Mac has installed.
Limitations
Like the RSRs of Ventura, BSIs can only work for a limited range of patches. If a vulnerability needs a fix outside Safari, WebKit, and the dyld caches, then it will require a full macOS update to fix it. BSIs are only ever likely to be provided for the current version of the latest major version of macOS.
From its first account of RSRs, Apple has claimed that some RSRs and BSIs shouldn’t require a restart to apply their patches. However, every RSR and BSI to date has had to be completed by restarting that Mac, which is mildly disruptive and not as lightweight as we’d like.
If you disable Automatically Install in the BSI section of Privacy & Security settings, then your Mac won’t be informed about or have access to any BSIs.
Under the hood
Despite their control being part of Privacy & Security settings, BSIs are managed like all other macOS and related updates by softwareupdated. What is most remarkable about them is their speed of download, preparation and installation compared with macOS updates. From detection of a new BSI to logging back into the restarted Mac can take little more than five minutes.
Apple’s in-house term for BSIs is the same as it used for RSRs, Splat. You’ll also come across Semi-splat, which should be a transient state in which the Splat Restore Version is different from the Cryptex1 Restore Version. That’s normally rectified after the reboot.
softwareupdated checks specifically for BSIs by scanning the update server catalogue for Splat updates. In this case, for an App cryptex, the download size is given as 214 MB. There’s a brief preflight phase, followed by its download. Although no progress indicator is shown in Privacy & Security settings, softwareupdated does record progress, but using similar figures for a full macOS update. Under those, preparing the update is set at 60% progress.
Applying the update takes around 2.5 seconds, at which stage softwareupdated reports that Semi-splat is active because of unequal restore versions, and rollback objects are checked.
Once the Mac has restarted, property list paths are checked for six different Splat versions, enabling the restore versions to be rectified and Semi-splat is no longer active. A brief purge of update assets is performed, and softwareupdated checks once again for any available updates.
Is a BSI just an RSR in disguise?
Apart from the move of its control from Software Update to Privacy & Security settings, there appear to be few if any differences between them. This is even reflected in version numbering. Installing the first RSR for macOS 13.3.1 brought it to version 13.3.1 (a), with a build number of 22E772610a. This first BSI for macOS 26.3.1 brings it to version 26.3.1 (a), with a build number of 25D771280a.
Most telling, though, are the accounts of RSRs and BSIs given in Apple’s Platform Security Guide, which are almost word-for-word identical apart from their names. It seems most likely that a BSI is a rebranded RSR in a bid to move on from the loss of confidence in RSRs following unfortunate errors nearly three years ago.
Key points
If you’re running the current version of the latest major version of macOS, BSIs provide lightweight fixes for some vulnerabilities, including those in Safari and WebKit.
Enable them in Privacy & Security settings, in their section at the foot. If they aren’t enabled there, you won’t be offered them at all.
Control their installation in that section. Once you’ve agreed to install one and have authenticated, your Mac is likely to restart automatically soon after the BSI has been downloaded.
Remove and revert a troublesome BSI using the ⓘ Info button there.
Although the US English version of Apple’s Platform Security Guide has replaced its section on RSRs with an almost identical account of BSIs, most other localised versions of that guide still contain the old RSR version.
Apple silicon Macs are about to undergo change to the numbering of their firmware versions. Accounts from beta-testing of the next minor update to macOS 26 Tahoe, version 26.4, indicate that future firmware will no longer be numbered as iBoot 13822.101.6, but as mBoot 18000.101.6 instead. This has major consequences for my free utility SilentKnight, which checks and reports the version of firmware installed. Version 2.14 should address that change in readiness for the release of the 26.4 update, and is particularly recommended for use on Apple silicon Macs.
This change was first reported in macOS 26.4 beta 2, and has apparently been sustained in the two subsequent beta releases, confirming that it’s an intended change, and not a bug.
There are currently two places in System Information that report a Mac’s firmware version, either the main Hardware section (also accessible in system_profiler SPHardwareDataType), or the Controller item within that section (or system_profiler SPiBridgeDataType).
Intel Macs without a T2 chip don’t report anything for their Controller, but those with T2 or Apple silicon chips reveal that they have a T2 or give an iBoot firmware version there. All three types of Mac also give a System Firmware Version in the Hardware overview.
This can get more confusing if you update or install macOS to an external disk. That will normally update the Mac’s firmware if the version of macOS installed on the external disk comes with more recent firmware. For example, if your Apple silicon Mac is currently running macOS Tahoe 26.3.1, it should have an iBoot firmware version of 13822.81.10. If you were to install Tahoe 26.4 to an external disk, as that has a more recent version of iBoot firmware, that should update the version installed in your Mac, and that remains so even when you start it up from its internal SSD.
As far as I can tell at present, this can result in internally inconsistent reporting. When running 26.3.1 from its internal SSD, that Mac will report its old iBoot version in the Controller section, but its new mBoot version in the Hardware section. Although that could change by 26.4 release, it might remain in all older versions, so providing lasting confusion.
As Apple hasn’t documented this change, I don’t know whether this will apply to all Apple silicon Macs updated to macOS 26.4, or to those updated to the matching versions of Sequoia or Sonoma. Therefore this new version of SilentKnight doesn’t attempt to check these new mBoot versions, and merely reports those found as well as it can. Once I know more, I will endeavour to interpret the results.
SilentKnight version 2.14 for macOS 11.5 and later is now available from here: silentknight214
from Downloads above, from its Product Page, and via its auto-update mechanism.
Please let me know how you get on with these new firmware version numbers.
Note: version 2.14 now fixes a bug that failed to recognise T2 Macs correctly in certain localisations including German. Thanks to Jan for reporting this so promptly.
Apple has released an update to macOS Tahoe bringing it to version 26.3.1. This adds support for its new Studio Display announced earlier this week. It’s also claimed to contain “bug fixes”, although none are detailed.
Download size for Apple silicon Macs is around 3 GB.
There are no published CVE entries for this update, so no publicly known security vulnerabilities are claimed to have been addressed.
This version has a build number of 25D2128, and there’s no change in iBoot firmware, which remains at 13822.81.10.
Looking at changes in bundled apps, there’s only one small increment in build and version numbers, in Passwords, which rises from version 2.3 to 2.3.1. Safari goes up a single build increment from 26.3 (21623.2.7.11.6) to 26.3.1 (21623.2.7.11.7).
In /System/Library, almost all the changes are in kernel extensions added to support the new Studio Displays. These include:
AGXFirmwareKextG17PRTBuddy and AGXFirmwareKextG17XRTBuddy, AGXG17P and AGXG17X, AGXMetalG17P and AGXMetalG17X
nine new AppleT6050 kexts, and an AppleT8080SOCTuner
three additional AppleT8140 kexts
an additional T6050TypeCPhy plugin to AppleTypeCPhy kext
AppleVL822FirmwareUpdater
AppleXHCFFirmwareDriver
WLANDriver kext
there’s an additional plugin to AppleEmbeddedAudio.
There’s also a new app in CoreServices, Medical Imaging Calibrator, and new DriverExtensions AppleCentauriAlpha, AppleCentauriBeta and AppleCentauriControl. Several private frameworks have been added, and others updated, presumably to provide access to the features of the new displays.
Clearly, Apple’s internal name for these new displays is Centauri.
If you are testing beta-releases of macOS Tahoe 26.4 and use SilentKnight, you will be aware that betas 2 and 3 cause it to crash on launch, on Apple silicon Macs. This is because the firmware version returned by these betas is completely different from all others for Apple silicon Macs for the last five years. As a result of that, SilentKnight doesn’t recognise them as Apple silicon Macs, and tries to obtain their firmware versions in a way that’s only compatible with older Intel Macs.
I’m very grateful to all those beta-testers who informed me of this problem, and those who sent me crash logs.
I have now incorporated a workaround into a new build of this version. Although this doesn’t attempt to interpret the new firmware version number, which will be reported as requiring updating, this has been tested against beta 3 and does now recognise Apple silicon Macs, and shouldn’t crash. Although this should also be compatible with all other Macs and macOS that support SilentKnight version 2.12 build 59, it’s only required on 26.4 beta 2 and later. It also won’t be offered through SilentKnight’s auto-update mechanism, so if you want it, please download build 61 from here: silentknight212v61
As Apple has never documented firmware version numbers, despite revealing them in System Information, I have absolutely no idea whether this change is intentional, whether it will be used in 26.4 release, or whether it’s simply a bug. I’m hoping the last of those, because changing firmware version numbering is a sure way to create havoc, as Apple should have learned from the past.
Look in Apple’s support note explaining Safe mode, and you’ll see a list of three things that mode is claimed to do:
“Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren’t required by macOS, and fonts that weren’t installed by macOS.”
“Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.”
“Clears some system caches, including font caches and the kernel cache, which are automatically created again as needed. This can temporarily make more storage space available on your startup disk.”
That note is well-maintained, and its US version was last updated on 5 December last year. This article examines what “basic check of your startup disk” is performed, how “similar” it is to the First Aid feature in Disk Utility, and whether it differs from checks performed during startup in normal mode. All testing has been performed in macOS 26.3 Tahoe on Apple silicon Macs.
Reporting
Disk checks made in Safe mode aren’t reported to the user in the GUI. There’s no notification that they have been completed, neither is there any record made in System Information. They are, though, reported in three more obscure places most folk won’t try accessing:
/var/log/fsck_apfs.log, accessible in Console or a text editor,
/var/log/fsck_apfs_error.log, accessible in Console or a text editor,
the Unified log, accessible using a log browser such as LogUI.
A typical entry in the first of those, for the Data volume, reads /dev/rdisk3s5: fsck_apfs started at Mon Mar 2 06:46:45 2026
/dev/rdisk3s5: error: container /dev/rdisk3 is mounted with write access; please re-run with -l.
/dev/rdisk3s5: fsck_apfs completed at Mon Mar 2 06:46:45 2026
Seven of the volumes checked during startup report that same error, and the only two in the boot volume group that report completion of the check are the System volume, unmounted during normal running, and the Signed System Volume, which has its own error-checking and is a snapshot in any case. Those that do complete and provide further information uniformly report /dev/rdisk7s3: ** QUICKCHECK ONLY; FILESYSTEM CLEAN
fsck_apfs_error.log contributes no useful information, as many of its entries are uninformative, for example dev= uuid=00000000-0000-0000-0000-000000000000 vers=2632.80.1.0.1 default_ans=n result=0 fp=0 fl=-1 repairs=0 time=0 iter=1
fsck_apfs completed at Mon Mar 2 06:46:45 2026
which completely fails to identify the volume being reported.
Corresponding entries in the Unified log for the Data volume are similar to those in fsck_apfs.log: 06:46:45.153989 com.apple.DiskArbitration.diskarbitrationd probed disk, id = /dev/disk3s5, with apfs, ongoing.
06:46:45.175308 com.apple.DiskArbitration.diskarbitrationd fsck status 65 /dev/rdisk3s5
06:46:45.182032 com.apple.DiskArbitration.diskarbitrationd probed disk, id = /dev/disk3s5, with apfs, success.
Checks performed
It’s clear from those reports that fsck_apfs is performing a ‘quick check’ of each volume after it has been mounted ready for use. According to man fsck_apfs, that “causes fsck_apfs to quickly check whether the device is `clean’. If device is an APFS volume, fsck_apfs will quickly check the APFS container and the specified APFS volume.” A status code of 65 is well-known from First Aid in Disk Utility as indicating that the volume being checked was mounted for writing at the time, so no check has been performed, as that would require the volume to be unmounted first.
First Aid checks
Normally, running First Aid in Disk Utility on a volume causes that volume to be unmounted, and a full fsck_apfs to be performed, in which any errors found will be repaired if possible. In addition to checking that volume, any snapshots of it will also be checked, although they cannot normally be repaired. Checking snapshots is time consuming, and when using the command tool fsck_apfs can be skipped using the -S option, although that’s not available in Disk Utility, which automatically includes snapshot checks.
Normal startup
Exactly the same checks as those made in Safe mode are also performed at the same point when starting up in normal user mode, but not when starting up in Recovery mode. Reporting in fsck_apfs.log and the Unified log is identical, with the same volumes returning status 65 each time.
In this respect, Safe mode is no different to normal user mode.
History
Prior to the introduction of macOS Catalina in 2019, starting up in Safe mode resulted in a full scan of all volumes and snapshots using fsck_apfs in normal mode. As that could take an hour or more, and delayed startup for the whole of that period, checks changed in Catalina, since when they have only used quick checks. Despite that, Apple has continued to claim that one of Safe mode’s features is checking disks similarly to First Aid in Disk Utility.
Q&A
Does Safe mode perform “a basic check of your startup disk”?
Although quick checks are attempted during startup in Safe mode, because of the circumstances, they can’t be run on the Data volume, but they should complete on external volumes.
Is that check “similar to the more comprehensive check performed by the First Aid feature of Disk Utility”?
No. When it is able to complete, all it does is verify the file system is ‘clean’ and not already in need of repair. Checks in First Aid are more extensive, include any snapshots, and include any repairs found to be necessary.
Do the disk checks performed in Safe mode differ from those that occur during normal startup?
No. Safe mode doesn’t add any disk checks beyond those that already occur during normal startup.
Recommendations
If you want to check any of your Mac’s volumes or disks, don’t try using Safe mode. Instead, use First Aid in Disk Utility (or fsck_apfs). If you want to check one of the volumes in the current boot volume group, prefer doing so in Recovery mode.
Although the way that macOS updates itself has changed beyond all recognition over the last few years, we tend to assume that it still works much as it did in the past, downloading a single update file, decompressing and installing that. This series of articles takes a deeper dive into what actually happens, and tries to explain how it differs from previous package updates.
This account is primarily based on a detailed analysis of log entries obtained from updating 26.2 to 26.3 on a Mac mini M4 Pro, supported by additional information obtained from updating virtual machines to 26.3. macOS updates have changed considerably even since Big Sur, but I believe that their mechanisms have remained more similar than they differ from those before.
Download size
One of the most basic and striking observations about macOS updates is their variation in size. Although those reported on many Apple silicon Macs making the same single-step update are similar, some are considerably greater. As updates aren’t offered in standalone form, and are only provided via Software Update or its command line equivalent softwareupdate, the only practical way to assess this is to update a range of virtual machines.
Software Update also reports two update sizes to the user: the first is given as a promise prior to the user initiating the update, the other displayed above the progress bar during downloading, in the progress window. A third figure can also be derived by obtaining the update through a local Content Caching Server. Results obtained for the update to 26.3 are shown in the table below.
When originally performed on the host Mac, the initial claimed and reported download sizes were both smaller at 3.68 GB.
Although sizes for the update from 26.1 to 26.3 are surprisingly slightly less than those from 26.2, these demonstrate that the greater the difference between the original and destination versions, the larger will be the size of the download, as expected. However, there is no evidence that any of these shared the same download size: each is different, as if tailored to the requirements for the original macOS. This is very different from a system offering three types of installer for Delta and Combo updates, and a whole-system Installer for upgrades from an earlier major version.
Installation sizing
Prior to the update being applied, its download and preparation is largely controlled by softwareupdated and its associates. Before any downloading is initiated, that calculates the disk space required to download and prepare each of the components required for the update, a task it refers to as CalculatePrepareSize. This is critical if the update is to ensure that it won’t run out of free space during the update, and is checked repeatedly during the downloading sequence, as individual components are prepared for installation.
CalculatePrepareSize calculates the following values:
Cryptex size requirement, consisting of 60 MB being 1.2 times the size of the app cryptex, and 7,748 MB being 1.2 times the size of the system cryptex, for a total of 7,809 MB.
Snapshot preparation size, consisting of snapshot installation size of 3,785 MB plus the cryptex size, for a total of 11,595 MB.
Snapshot apply size, consisting of twice the update partition size plus the update APFS reserve for 700 MB, plus 231 MiB for sealing, for a total of 931 MB.
Snapshot preparation size, consisting of snapshot installation size of 5,154 MB (a significant increase from previously) plus the cryptex size, for a total of 12,963 MB.
For any given version of macOS (ignoring RSRs and BSIs that may later replace them), each hardware architecture is thought to have its own pair of cryptexes, and they aren’t thought to differ between Macs of the same architecture. Thus, no matter which their original version of macOS, all Apple silicon Macs updating to macOS 26.3 should be provided with the same app and system cryptexes, of the same sizes.
Sizes for snapshot update and installation clearly differ according to the original version of macOS. Although almost self-evident, it’s important to remember that updating macOS from a previous major version will normally require greater free disk space than updating by a single minor or patch version.
Given the sizes above, it’s also obvious that components downloaded for macOS updates are compressed to substantially smaller sizes, so have to be decompressed on the Mac being updated. Thus, the download sizes reported to the user are far smaller than the free disk space required to prepare and install the update.
Main stages
The overall sequence of stages is:
Identify update. Shortly after starting up, and at intervals of approximately 6 hours afterwards, softwareupdated tries to connect to Apple’s software update service to check whether there’s an update available for that Mac. Checks can also be initiated manually, or by apps like SilentKnight. If an update is found, the Mac and its current system are checked to determine whether it meets the requirements for that update.
Check update size. CalculatePrepareSize estimates space required. If free space is insufficient for the calculated requirements, the update is aborted.
Display progress. The progress window is displayed with its bar, and set points are allocated to stages of the finite state machine in softwareupdated to indicate to the user how far update download and preparation have progressed.
Initial preparations. These include detailed identification of components to be downloaded and installed, and preparation of persistent data.
Preflight. Download the ‘update brain’ used to perform the update phase, and perform preflight phases.
Update Rosetta. Download any update for Rosetta 2.
Update Recovery. Download any Recovery update.
Download snapshot update. This takes 38% of the progress bar, and includes streaming decompression of contents, and download and decompression of the two cryptexes.
Preflight Recovery.
Prepare update. This includes many checks, including hashes of firmware updates, cryptexes, and contents of the updates. This takes 39% of the progress bar, but doesn’t appear to involve any decompression.
Apply update. Reboot macOS into the control of the ‘update brain’ to install update including new firmware, create snapshot, build hash tree, seal and sign SSV, then continue the boot process from that.
Kernel boot into updated macOS.
Clean up and check for updates.
Because stage 11, applying the update, is run by the update brain, normal logging doesn’t take place, and no clear account can be made of what happens then.
From Big Sur onwards, the great majority of this is performed in what is effectively a single thread run on CPU Performance cores. This is readily seen when updating a virtual machine, for example. It’s thought that updates are constrained to use the equivalent of just a single P core to enable the user to continue working through a process that could take up to an hour. Thankfully, with the advent of faster models and continued engineering optimisations, this Mac mini took just 18 minutes from requesting the update to 26.3 until it was logged into and fully functional again.
In subsequent articles I will look in more detail at the stages listed above.
Conclusions
The greater the difference between the original and new macOS versions, the larger the update will be to download.
Updates are tailored to the individual requirements of the Mac being updated, and may differ considerably in size.
Detailed installation sizing is performed after the offer of the update, and is considerably larger than download size, as it includes all components after decompression.
Download and preparation account for just under 40% of the progress bar each. More than 20% is accounted for by other stages.
Applying the update is followed by kernel boot from the updated SSV.
Last week Apple released the second beta of macOS 26.4 to developers, and almost immediately I was receiving reports that SilentKnight crashed on launch in that new beta. Given how unusual that has been in previous versions, I was grateful to hear so quickly, and for so many of you to provide crash reports. As usual they don’t point to anything specific, but led me to wonder whether something might have broken in AppKit in that beta.
But there’s a strange observation reported by SilentKnight’s old predecessor LockRattler, which continues to work normally in 26.4 beta 2: that reports a bizarre iBoot firmware version number from Apple silicon Macs. Instead of a number like 13822.101.2 that I might have expected, LockRattler gives “mBoot-18000.100.10.0.1”, which is random nonsense. Yet it’s listed in a mammoth compilation of iBoot version numbers in the Apple Wiki as an occasional fault.
“mBoot-18000.100.10.0.1” is a problem for SilentKnight, as it tries to make comparisons between firmware version numbers to see whether that installed in your Mac is older or more recent that the version number it expects. If it didn’t do that, every beta-tester would be driven crazy by its persistent reports that their Mac’s firmware is out of date, when in fact it’s that for the next version.
Comparing numbers is of course simple, but I’ve been unable to find anywhere in the API that returns numbers for firmware versions. Wherever they’re available, they’re reported as strings of arbitrary characters, leaving SilentKnight the task of recovering three integers (in the case of iBoot) from what in this case turns out to be rubbish. This is further complicated by the fact that different architectures return strings with different structures: for plain Intel Macs, they should look like “2094.80.5.0.0”, those with T2 chips extend to “2094.80.5.0.0 (23.16.13120.0.0,0)”, and Apple silicon is simpler again with “13822.81.10”. What could have been a simple task is turned into lots of additional code.
It also raises the question of how any beta-release could be put in the hands of external testers when it can’t even report its firmware version correctly. Most of us draw clear distinctions between alpha and beta releases, and this strongly suggests that Apple doesn’t undertake any purposeful alpha testing before release as a beta. Either that or it’s well aware of significant bugs that it doesn’t inform beta-testers about. I fear the answer could be both, and I’m wondering whether trying to make sense of reported firmware versions is too fraught to be reliable.
My main use of SilentKnight here is to check for updates released for the security tools in macOS, primarily XProtect and XProtect Remediator. You may recall that Apple’s last update to XProtect Remediator on 17 February, bringing it to version 157, contained a strange change, which I reported as “the Bastion rules appear to correct a group of typos in the definition for bastion-common-system-binary”.
There were six typos in all, in a definition for bastion-common-system-binary introduced back in version 153 six months ago, on 5 August last year. I shouldn’t need to point out the errors in the original definition: (define bastion-common-system-binary
(require-all
(process-attribute is-platform-binary)
(require-not
(require-any
(signing-identifier "com.apple.osascript")
(signing-identifier "com.apple.zsh")
(signing-identifier "com.apple.bash")
(signing-identifier "com.apple.sh")
(signing-identifier "com.apple.ksh")
(signing-identifier "com.apple.osacompile")
(signing-identifier "com.apple.python2")
(signing-identifier "python3")
(signing-identifier "ccom.apple.pbcopy")
(signing-identifier "ccom.apple.pbpaste")
(signing-identifier "ccom.apple.cat")
(signing-identifier "ccom.apple.curl")
(signing-identifier "ccom.apple.dd")
(signing-identifier "ccom.apple.cp")
(signing-identifier "com.apple.perl")))))
Instead of “ccom.apple.pbcopy”, it should of course have read “com.apple.pbcopy”, and the same for the other five signing-identifiers below that.
I’m delighted that Arnaud Abbati has explained eloquently the consequences of those typos in a wonderful article in his blog. I won’t steal his thunder here, but agree with his conclusion: “Six months of security updates, and nobody noticed. It missed engineering. It missed testing. It missed code review. It missed QA. It missed whatever metrics pipeline is supposed to validate that the rules actually match real binaries.”
There are times when I wonder what really does go on in Apple. When it releases a beta that can’t even tell what its firmware version is, and its security intelligence tool is broken for six months because of obvious typos, it does make you wonder.
Life without documentation can get quite exciting, particularly when you discover a feature that changed beyond all recognition last September, with the release of macOS 26 Tahoe. I’m referring of course to what used to be Apple Diagnostics, but only in Apple silicon Macs. If you’re running Tahoe on an Intel Mac, then I’m afraid you’ll just have to be struggle along with what you’ve been using for the last few years.
Apple Diagnostics used to be the only part of Recovery that still relied on a keystroke command in Apple silicon Macs, and that hasn’t changed. Before starting your Mac up, if it’s a laptop connect its mains power adaptor if possible, and that will be included in the tests. Then press and hold the Power button until Recovery starts loading. Once it appears, press and hold the Command ⌘ and D keys until you hear the startup chime indicating the Mac has rebooted into Repair Assistant.
This is the welcome window, explaining how Repair Assistant can run diagnostics, as well as being used to complete hardware repairs.
Then comes the inevitable privacy policy.
Unfortunately that’s as far as a virtual machine can get. On a real Apple silicon Mac you’ll then be invited to choose from the available diagnostic suites according to your Mac’s hardware, from:
Mac Resource Inspector, to test the main Mac hardware over a period of 1-7 minutes;
Display Anomalies, for any built-in LCD panel;
Keyboard, only when built-in;
Trackpad, only when built-in;
Touch ID, for any built-in Touch ID sensor;
Audio, to verify audio output using a set of test tones.
Currently these are run individually and there’s no means to run them all in sequence.
Once a test has completed, it’s marked with a green to indicate success, or a warning triangle or error symbol if the test couldn’t be attempted (power supply when not connected to a laptop) or problems were discovered. Individual tests and their results are listed from each test’s ⓘ button. After all these years, Apple is finally trusting us to know what tests have been performed, and not just giving us a cryptic code at the end.
Repair Assistant’s substitute for an About window provides details of your Mac, including its serial number, and the version of macOS. Its QR code (lightly defaced here) simply provides the serial number in an accessible way.
This is a huge improvement on Apple Diagnostics, but there’s one slight glitch. Previous results from diagnostic testing were recorded in the Diagnostics section of System Information, but not those from Repair Assistant.
I was very surprised to come across this in macOS 26.3 when only intending to take a quick screenshot of Diagnostics. Although I was aware that a Repair Assistant had been rumoured prior to the release of Tahoe, I had thought that was only intended to help service engineers authorise some replacement parts that needed to be recognised by the Mac. I can still find no mention of how Repair Assistant replaced Apple Diagnostics five months ago.
Apple’s own documentation is as unhelpful as ever and unusually vague. It does refer to the version of Apple Diagnostics used depending “on your Mac, the version of macOS that it’s using, and whether certain parts of your Mac have been repaired or replaced”, but complete replacement was unexpected. The closest that note comes to its description is that “in macOS Tahoe 26 and later, you’re asked to choose a specific diagnostic to run, such as a diagnostic for your built-in display, keyboard, or trackpad. In earlier versions of macOS, this is automatic.”
It’s almost as if the author of that note had never used or seen Repair Assistant, and was basing that account on something overhead in passing. And that article is dated 19 December 2025.
Although Apple forgot to tell you about it five months ago, let me break the news that macOS 26 Tahoe brings a completely new and redesigned replacement for Apple Diagnostics in Apple silicon Macs. I’m impressed with it, and sorry I’ve only just caught up.
For once, Apple’s bland statement that “this update provides important bug fixes and security updates” may be the best overview of what has changed in macOS Tahoe 26.3. There are few version changes that stand out, but a lot of smallish build increments that suggest some bugs, at least, have been fixed.
Security is another matter, with around 52 vulnerabilities addressed and listed here. Those include one that Apple reports has been exploited in a sophisticated attack against an older version of iOS. For that alone, this update is compelling if you’ve already upgraded to Tahoe.
There are three entries in Apple’s release notes for enterprise, although none should affect those outside enterprise environments.
What Apple doesn’t reveal is that it has improved, if not fixed, the shortcomings in Accessibility’s Reduced Transparency setting. When that’s enabled, at least some of the visual mess resulting from Liquid Glass, for example in the Search box in System Settings, is now cleaned up, as the sidebar header is now opaque. It’s a small step, but does address one of the most glaring faults in 26.2.
The build number of the release version of 26.3 is 25D125. There are firmware updates all round, bringing iBoot to 13822.81.10, and Intel T2 firmware to 2094.80.5.0.0 with iBridge 23.16.13120.0.0,0.
Significant version increments in bundled applications include:
Freeform from 4.2 (630.61.2) to 4.3 (630.81.1)
Music from 1.6.2 to 1.6.3
Passwords from 2.2 (21623.1.14.11.9) to 2.3 (21623.2.7.11.6)
Safari from 26.2 (21623.1.14.11.9) to 26.3 (21623.2.7.11.6)
TV from 1.6.2 to 1.6.3.
Significant changes seen in /System/Library include:
PosterBoard app has been removed from CoreServices
Kernel extensions in the AGX family have substantial changes in build numbers
AppleT6022CLPCServer has been added as a new kext
There are two new kexts to support Thunderbolt, AppleThunderboltUSBType2DownAdapter and AppleThunderboltUSBType2UpAdapter, perhaps to support new hardware features in future M5 models?
APFS from version 2632.40.17 to 2632.80.1
MPSHost, a new framework for Metal performance shaders, has been added
New private frameworks include BinaryAssetTag
Spotlight mdimporters updated to new build numbers include Application, Automator, CoreMedia and Mail, but not RichText.
I look forward to hearing of any fixes or improvements you find.
Postscript:
I’m grateful to @Remo_Pr0 for drawing my attention to the fact that the updated version of OpenSSH included writes a scary warning about post-quantum key exchange algorithms when a connection is made to a system that doesn’t support post-quantum methods.
Apple has released updates to macOS, to bring Tahoe to version 26.3, and security updates for Sequoia to version 15.7.4, and Sonoma to 14.8.4.
The Tahoe update downloads in around 3.7 GB for an Apple silicon Mac, and 2.5 GB for an Intel Mac.
Apple seems to have forgotten what 26.3 fixes or improves, writing just “this update provides important bug fixes and security updates”.
Security release notes for Tahoe 26.3 are here, and list around 52 vulnerabilities addressed, including one that has been previously used in an attack on iOS. Sequoia 15.7.4 has about 30 fixes listed here, and Sonoma 14.8.4 has about 36 listed here.
The build number of 26.3 is 25D125, and iBoot firmware is updated to version 13822.81.10. Safari is version 26.3 (21623.2.7.11.6).
I’ll update this post with further information as I get it. and will later provide details of significant changes in version numbers.
Despite rumours that Time Capsules had lost support in macOS Tahoe, those still backing up to them have discovered they continue to work, at least to existing backup stores. I’m very grateful to Michael for telling me that Tahoe no longer lets you start a new backup on a Time Capsule, nor it appears to any other store requiring HFS+ (Mac Extended) format.
Time Capsule support is expected to end with macOS 26 Tahoe, as macOS 27 is unlikely to support AFP any more, so those Intel Macs compatible with Tahoe can continue backing up to Time Capsules until they’re replaced. Apple remains intentionally vague about this, stating only that AFP “won’t be supported in a future version of macOS”, and has been even less clear about support for backup stores on HFS+.
Apple’s documentation implies that has been dropped already. Since Big Sur, it has stated: “APFS or APFS Encrypted disks are the preferred format for a Time Machine backup disk. If you select a new backup disk that’s not already formatted as an APFS disk, you get the option to erase and reformat it. If the disk is a Mac OS Extended format disk that contains an existing Time Machine backup, you aren’t asked to erase and reformat the disk.” However, “Time Machine still supports backups on Mac OS Extended format (Journalled), Mac OS Extended (Case-sensitive, Journalled), and Xsan formatted disks.”
Other support documents are even less helpful. This one doesn’t even mention HFS+, while another, dated 5 December 2025 and detailing backup disks you can use with Time Machine, concentrates on AFP and implies that HFS+ remains fully supported on Time Capsules.
Unfortunately, in macOS Tahoe, the moment you erase your Time Capsule to start a fresh backup series, Time Machine considers that’s a new backup disk, and wants it to be in APFS format. As that’s not possible, it refuses, stating “Time Machine can only be used if it contains existing Time Machine backups for this Mac.”
Michael found an ingenious workaround on his MacBook Air M2, by installing Sequoia in its own container, starting up from that, and then creating the new backup store on his Time Capsule. When he restarted his Mac in Tahoe, Time Machine was perfectly happy to start a new backup set, as it already existed.
From this we can only conclude that macOS Tahoe:
fully supports Time Machine backups using AFP,
fully supports Time Machine backups to Time Capsules with backup stores already formatted in HFS+,
but refuses to create a new backup store on a Time Capsule,
also refuses to create a new backup store on local storage formatted in HFS+, but insists on reformatting that to APFS.
I don’t believe for a moment this behaviour is a bug, but is an intentional limitation that Apple hasn’t documented. While I have been warning since July 2021 that you should replace any Time Capsules, as they won’t be supported for much longer, this abrupt change is unwarranted.
If you’ve upgraded to macOS Tahoe and erase your Time Capsule’s backups, you’ll be unable to store any new backups on it, unless you revert to Sequoia. This is yet another compelling reason not to upgrade to macOS 26.
Anyone familiar with Doctor Who will be aware of the power brought by control over time. Although there have been sporadic reports of problems with Apple silicon Macs keeping good time, and they may not synchronise sufficiently accurately for some purposes, they appear to have generally good control over time.
Last year I explained how macOS now uses the timed service with network time (NTP) to perform adjustments while running. This article looks at what happens before that, during startup, when the Mac has only its own devices to tell the time. Although the user sees little of this period, anyone accessing the log recorded during startup could find the timestamps of entries affected by adjustments. It may also provide insights into how Apple silicon Macs tell the time.
Methods
To investigate clock initialisation and adjustment during startup, I analysed approximately 100,000 consecutive log entries freshly recorded in the log of a Mac mini M4 Pro booting cold into macOS 26.2, following a period of about 14 hours shut down. These entries covered the period from the initial boot message for approximately 27 seconds, after I had logged in and the Desktop and Finder were displayed. This Mac is configured to Set time and date automatically from the default source of time.apple.com in Date & Time settings, and has both WiFi and Ethernet connections.
Multiple adjustments to wallclock time were recorded during that period, resulting in significant discontinuities in log timestamps. For example, 11:40:15.888717 void CoreAnalyticsHub::handleNagTimerExpiry(IOTimerEventSource *)::838:messageClients of 37 available events
11:40:10.045582 === system wallclock time adjusted
11:40:10.053309 000009.664065 Sandboxing init issue resolved: "Success"
11:40:10.053447 com.apple.sandbox.reporting Sandbox: wifiFirmwareLoader(49) deny(1) file-read-metadata /Library
11:40:10.112333 === system wallclock time adjusted
11:40:10.127559 com.apple.Installer-Progress Progress UI App Starting
In the first of those adjustments, the wallclock time was retarded by up to 5.84 seconds, and in the second it was advanced by at most 0.0589 seconds.
Because of those wallclock adjustments, times recorded in the log are discontinuous. Although it’s not possible to correct for the adjustments made completely accurately, assuming that each of those adjustments corresponds to standard time (such as UTC), those can be applied backwards through times recorded in the log to bring them closer to that standard. This could result in some brief periods of entries with times earlier than preceding entries, but is as accurate an estimate possible given the data.
Adjustments found
The narrative constructed from the log is summarised in the following table.
This starts with the initial record of the boot process, giving its UUID, within a second of the Power button being pressed (at approximately 0.0 seconds) to initiate the startup. That’s followed by a gap of just over 5 seconds before the second log entry.
The first two wallclock adjustments were made at 10 seconds, before there was any evidence of network connectivity. Those took place one second before the loginwindow was launched.
Two subsequent adjustments were made shortly after 24 seconds, immediately following the removal of the loginwindow after successful authentication. A further three adjustments followed in the 2.5 seconds after the user was logged in, while the Desktop and Finder were being prepared and displayed.
Log entries reporting the timed service was running didn’t occur until shortly before the last of those wallclock adjustments, and that was recorded in the log 0.0003 seconds before timed obtained its first external time.
Multiple internal clocks
A total of seven wallclock time adjustments were made before timed was able to obtain a time from any external reference. Over the first 10 seconds, before the initial wallclock adjustment, those were substantial, amounting to 5.8 seconds. For those changes to be made to wallclock time, there must be another source of time deemed more accurate, against which wallclock time can be compared and adjusted.
I’ve been unable to find any trustworthy information about internal clocks and timekeeping in Apple silicon Macs. It has been suggested (and Google AI is confident) that local reference time is obtained from the Secure Enclave. However, Apple’s only detailed account of features of the Secure Enclave fails to mention this. Initialisation of the Secure Enclave Processor also occurs relatively late during kernel boot, in this case at around the same time as the first two adjustments were made to wallclock time.
Conclusions
Apple silicon Macs may make multiple adjustments to wallclock time during startup, resulting in several discontinuities in log timestamps, which can cause discrepancies in event times.
Several of those can occur before the Mac has access to external time references, and timed is able to obtain an external time against which to adjust wallclock time.
Wallclock time can’t be the only local source of time, and appears to be adjusted against another local source.
Since macOS Ventura, if not in late releases of Monterey, macOS has been loading Safari and other parts of the operating system, including dyld caches, in cryptexes, instead of installing them in the Data volume. In addition to those, Apple silicon Macs with AI enabled load additional cryptexes to support its features. I detailed those for macOS 15.5 last summer; this article updates that information for macOS Tahoe 26.2.
Cryptexes
These first appeared on Apple’s customised iPhone, its Security Research Device, which uses them to load a personalised trust cache and a disk image containing corresponding content. Without the cryptex, engineering those iPhones would have been extremely difficult. According to its entry in the File Formats Manual from five years ago (man cryptex), ‘A cryptex is a cryptographically-sealed archive which encapsulates a well-defined filesystem hierarchy. The host operating system recognizes the hierarchy of the cryptex and extends itself with the content of that hierarchy. The name cryptex is a portmanteau for “CRYPTographically-sealed EXtension”.’
In practice, a cryptex is a sealed disk image containing its own file system, mounted at a chosen location within the root file system during the boot process. Prior to mounting the cryptex, macOS verifies it matches its seal, thus confirming it hasn’t been tampered with. Managing these cryptexes is the task of the cryptexd service with cryptexctl. Because cryptexes aren’t mounted in the usual way, they’re not visible in mount lists such as that produced by mount(8).
System cryptexes
Once kernel boot is well under way, APFS mounts containers and volumes in the current boot volume group, followed by others to be mounted at startup. When those are complete, it turns to mounting and grafting the three standard system cryptexes, os.dmg containing system components such as dyld caches, app.dmg containing Safari and its supporting components including WebKit, and os.clone.dmg a clone of os.dmg that shares its data blocks with os.dmg. Grafting all three takes around 0.034 seconds, and typically occurs over 15 seconds after APFS is started, and around 25 seconds after the start of boot.
AI cryptex collection
About 5 seconds after the system cryptexes have been grafted, APFS checks and grafts a series of cryptexes primarily involved with Apple Intelligence features. These are handled one at a time in succession, and are listed in the Appendix. Typical time required to complete this collection is less than 0.5 seconds.
Ten new AI cryptexes have been added in Tahoe, and five of Sequoia’s have been removed, bringing the total including the PKI trust store from 23 to 28. Notable among the additions are:
language instruction support for image tokenisation
support for drafting replies in Messages
suggesting action items in Reminders
support for Shortcuts
suggesting recipe items.
Conclusions
Apple silicon Macs running macOS 26.2 with AI enabled load 28 additional cryptexes to support AI.
One cryptex is a secure PKI trust store, whose volume name starts with Creedence.
These cryptexes are installed and updated as part of macOS updates, although they could also be installed or updated separately, for example when AI is enabled.
If a Mac shows an unusual mounted volume with a name starting with Creedence or Revival, that’s almost certainly the respective disk image, which should normally be hidden and not visible in the Finder.
Appendix
Disk image names for the main AI cryptex collection in macOS 26.2 (Apple silicon):
New cryptexes are shown in bold. When these are mounted, their volume names add the prefix RevivalB13M202xxx where xxx are ID digits for that cryptex. That prefix replaces RevivalB13M201xxx used in macOS 15.5.
Additionally, a volume is mounted as a PKI trust store, as Creedence11M6270.SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.
The following cryptexes found in macOS 15.5 appear to have been removed from 26.2:
Sometimes apparently simple things are truly simple, but more often than not they need us to turn detective to delve deeper. This has proved the case with local network privacy protection, introduced well over a year ago in macOS Sequoia, and largely glossed over since. As I was compiling my brief summary of what I had been able to discover about it, I had a feeling there was more to come, and there is.
Cast your mind back just over a year to the first couple of release versions of macOS Sequoia. Do you recall all the problems reported with its software firewall and networking? At the time I wrote of 15.0 “There have been widespread reports of problems with networking, many attributable to the software firewall. Products across a wide range of vendors are affected, and many simply can’t function properly in Sequoia.”
Most of those were addressed in 15.1, but their cause was never made clear unless you read Apple’s TN3179 carefully, where it’s mentioned in passing that “macOS 15.1 fixed a number of local network privacy bugs”. It’s no coincidence that macOS 15.0 was the first public release to feature that local network privacy protection.
Another clue came in the statement in that note that “on macOS there’s no way to reset your program’s Local Network privilege to the undetermined state”. This contrasts with pretty well every other category of privacy protection, which are handled by the dreaded TCC, Transparency Consent and Control. The major exception to those comes in Location Services, which are handled and implemented separately.
At this point I could hear the log calling me to take a look at what happens when a new app first requests access to the local network. Thanks to those of you who suggested candidates for this, I chose VideoLAN’s VLC running in a macOS 26.2 VM with bridged networking and a LAN available. I first drew a blank for TCC, as I had expected, which clearly knows nothing about local network privacy. Instead, it was the Network Extension framework that did all the work.
Once VLC had cleared Gatekeeper’s checks, it tried to query the local network, resulting in the standard request for consent.
This in itself is revealing, as it doesn’t appear to be constructed using a prompt string supplied in VLC, neither does it include VLC’s icon. It turns out that was all handled by the Network Extension framework: 06.249975 com.apple.networkextension Showing local network alert for org.videolan.vlc even though not in the foreground
06.249982 com.apple.networkextension Local network preference not yet set, prompting for VLC (org.videolan.vlc)
06.252939 com.apple.networkextension LocalNetwork icon configuration: notification dictionary option {
AlertHeader = "Allow \U201cVLC\U201d to find devices on local networks?";
AlertMessage = "This will allow the app to discover, connect to and collect data from devices on your networks.";
AlternateButtonTitle = "Don\U2019t Allow";
DefaultButtonTitle = Allow;
IconURL = "file:///System/Library/Frameworks/NetworkExtension.framework/Resources/LocalNetworkPrivacy.png";
SBUserNotificationDefaultButtonTag = 32; }
Less than four seconds later, I had clicked on the Allow button, and VLC got the green light: 10.015043 com.apple.mdns Local network alert policy status 'granted' for (org.videolan.vlc).
This added a new entry to the network privacy configuration: 10.023955 com.apple.networkextension NESMPathControllerSession[com.apple.preferences.networkprivacy-04DDB2F9-2C12-49BC-A4DE-B4CE6341E2B0:0C6F88E8-8AB2-4307-88AE-17E072232031]: handling configuration changed: {
name = <73-char-str>
identifier = 0C6F88E8-8AB2-4307-88AE-17E072232031
grade = 2
pathController = {
enabled = YES
pathRules = ( {
matchSigningIdentifier = PathRuleDefaultNonSystemIdentifier
matchDesignatedRequirement =
allowEmptyDesignatedRequirement = YES
noDivertDNS = NO
cellularBehavior = 0
denyCellularFallback = NO
denyMulticast = YES
multicastPreferenceSet = NO
isIdentifierExternal = NO
wifiBehavior = 0
denyAll = NO },
[other apps omitted]
{
matchSigningIdentifier = org.videolan.vlc
allowEmptyDesignatedRequirement = YES
noDivertDNS = NO
cellularBehavior = 0
denyCellularFallback = NO
denyMulticast = NO
multicastPreferenceSet = YES
isIdentifierExternal = NO
wifiBehavior = 0
denyAll = NO }, )
cellularFallbackFlags = 0
ignoreRouteRules = YES
ignoreFallback = YES } }
10.027741 com.apple.networkextension UUID: Found for org.videolan.vlc: ("07F0D29A-6013-3F29-81DC-15EAAB1C50D4")
The apps listed there extend well beyond those in the Local Network section of Privacy & Security settings, and it appears to include apps that don’t even attempt to make any network connection. It’s a useful list, though, that could be valuable if you’re trying to investigate a problem with local network connections. To elicit it, change its configuration and look for log entries from the com.apple.networkextension subsystem containing the word NESMPathControllerSession in the message field.
Knowing what the Network Extension framework can do, this makes it clear that local network privacy is implemented as a packet filter following those pathRules, which matches the statement in TN3179, that “the system implements these TCP and UDP checks deep in the networking stack, and thus they apply to all networking APIs.”
Summary
Local network privacy isn’t implemented through TCC, but as a packet filter in the Network Extension framework.
Prompts to allow access to local network features can be made without the app providing an information string.
A user’s Network Extension configuration contains path rules for apps that aren’t listed in the Local Network section of Privacy & Security settings.
The subsystem com.apple.networkextension may write its configuration to the log when it’s changed.
An app’s path rules are applied across all networking APIs.
This year marks the twentieth anniversary of Apple’s announcement of the introduction of code signing, although it wasn’t unleashed until Mac OS X 10.5 Leopard the following year (2007). I doubt whether there’ll be crowds gathering to celebrate the occasion, but 2026 also marks the parting of the ways for Intel and Apple silicon Macs, as Tahoe is the last version of macOS to run on Intel processors. There have already been rumours that will bring changes to code signing and what code will run on Arm cores.
Apple had long maintained that users would remain able to run unsigned code in macOS, but that changed in November 2020 with the first Apple silicon models. Since then, all executable code run on those new Macs has to be signed. What hasn’t been mandatory is the use of a developer certificate for the signature. Instead, all build systems now sign code using an ad hoc signature by default, when no developer certificate is available. This enables ordinary users to build their own apps and command tools locally, and run them on their own Macs, as many continue to do. The same applies to codeless apps such as Web Apps introduced in Sonoma, which are automatically signed ad hoc by macOS.
Those who develop apps and command tools for distribution to others have been told to sign their code using their developer certificate, then to get it notarised by Apple. Although that’s by no means universal, and there are still a few apps that don’t fit the process well, the great majority of those distributed outside the App Store should now come signed with a developer certificate and notarised.
Unlike some other operating systems, the only developer certificates recognised by macOS are those issued by Apple, but they’re provided free as one of the benefits of its $99 annual subscription to be a registered developer, as are unlimited notarisations.
The next concern for many is what happens when a developer certificate expires. On other systems, certificate expiry can result in apps suddenly becoming unusable, but that isn’t the case with macOS. So long as the certificate was valid at the time it was signed, macOS will recognise it as being valid at any time in the future. This isn’t the case, though, with developer installer certificates, used to sign installer packages: those must be valid at the time of installation, and the same applies to Apple’s own macOS and other installers. That continues to catch out both developers and users.
So as far as Intel Macs are concerned, the arrival of macOS 27 this coming autumn/fall won’t affect their access to apps, provided they’re supplied in Universal format, with x86 code. Many major software vendors have aligned their support period with Apple’s, so those apps should remain fully supported on Intel Macs until Apple’s support for macOS 26 ends in the autumn/fall of 2028. The sting here is that depends on upgrading to Tahoe: stick with Sequoia and that support is likely to end a year earlier, in 2027.
If you’ve switched to Apple silicon, you may be concerned as to when macOS will cease providing Rosetta 2 support for the few remaining apps that aren’t already Universal. Apple has stated its intention that full Rosetta translation support will end with macOS 27, although it intends to retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles” beyond that. In practice, that means most x86 apps and command tools will stop working in macOS 28, in the autumn/fall of 2027.
From then on, if you want to be able to run x86 code using Rosetta 2 translation, that will have to be in a virtual machine running macOS 27 or earlier. For once, the continuing inability of macOS VMs to run most App Store apps should have little or no effect. For installers whose installer certificate has expired, this may be a blessing, as it’s easier and less disruptive to set the clock back in a VM.
Apple has given no warnings, yet, of any changes to requirements for developer certificates, notarisation, or ad hoc code signing to come in macOS 27 or beyond. Given the time required for the adoption of code signing and notarisation, those would appear unlikely in the foreseeable future.
Key dates
All events occur with the autumn/fall release of the new version of macOS.
2026 (this year)
Intel Macs: Tahoe enters security-only support; new versions of some 3rd party products may be Arm-only Apple silicon Macs: first single architecture macOS.
2027
Intel Macs: Sequoia becomes unsupported Apple silicon Macs: full Rosetta 2 support ends.
2028
Intel Macs: Tahoe becomes unsupported; major 3rd party products likely to lose support.
For some, Spotlight and even Siri are indispensable, for others they’re just a waste of CPU and storage space. If you want to disable them, how is that best achieved?
Siri
The only documented way to turn Siri off is in its section in System Settings, where you should disable Siri Requests.
Although Siri will then be essentially inactive, it still doesn’t disappear. During startup, siriactionsd runs, and siriknowledged and some other of its services remain listed in Activity Monitor.
Spotlight
If you disable every item in Spotlight’s section in System Settings, that doesn’t disable Spotlight, nor stop it from indexing mounted volumes. Indeed, you may find it slows some Finder operations. Traditionally there have been two commands used in Terminal to try to disable Spotlight, depending on which of its features you want to stop.
The most common recommendation is to use sudo mdutil -a -i off
to disable Spotlight indexing, but that doesn’t stop its searches, and it may not even do that on the current Data volume. When you run that command, mdutil should inform you that indexing is disabled on each mounted volume, and Spotlight has been switched to kMDConfigSearchLevelFSSearchOnly. Although that’s reported for the root volume / and the Data volume at /System/Volumes/Data, I was still able to search and find files in the latter after running that command.
This might be related to previously reported problems disabling just the Data volume, which could require use of the explicit path /System/Volumes/Data.
The alternative is to use sudo mdutil -a -d
as that disables both Spotlight searches and Spotlight indexing, and appears to be effective on the current Data volume. mdutil will then inform you that indexing and searching are disabled on each mounted volume, and Spotlight has been switched to kMDConfigSearchLevelOff. That ensures all attempts to search will fail to return any hits.
Look carefully, though, and Spotlight hasn’t gone anywhere, and is still present in Activity Monitor’s list of processes. During startup you’ll still see its related daemons mediaanalysisd and photoanalysisd run briefly, and mds, Spotlight and spotlightknowledged are still present in the list of processes. Volumes will also have their hidden .Spotlight-V100 folder, although after mdutil -a -d its Store-V2 folder should remain completely empty.
Should you wish to enable Spotlighting indexing again, regardless of which command was used to disable it, use sudo mdutil -a -i on
which should report that indexing has been enabled on each mounted volume.
Conclusions
It’s not possible in macOS Tahoe to completely disable either Siri or Spotlight, not without resorting to system surgery and running with SIP disabled. However, you can reduce them to an absolute minimum by:
turning Siri Requests off in Siri settings;
running the command sudo mdutil -a -d in Terminal.
But using sudo mdutil -a -i off isn’t as thorough or reliable.
Of all the privacy protections in macOS, those for local networking are among the most recent and the least understood. Introduced in macOS Sequoia, they’re related to protection introduced earlier in iOS and iPadOS version 14, but different, and could trip you up when you’re least expecting yet another privacy prompt.
Fundamental rule
Any process running on your Mac that tries to make a connection to a local network address, to send or receive network packets without being forwarded by a router, requires privilege to do so. Without that privilege being allowed, the system will block it.
That sounds draconian, but most common uses are subject to exemptions, as a result of which the Local Network section in Privacy & Security settings remains empty.
All non-exempted apps and other processes start without any privilege. Those that try to make a local network connection result in the user being prompted to allow or deny their access. Your decision is then recorded in that app’s new entry in the Local Network section, and you can then set that to allow or deny its future access. For that to happen, the responsible app needs an additional item in its property list to explain to you why it requires that access, something that should appear in any prompt for access.
As with other privacy controls in macOS, this is applied for each individual user.
Major exceptions
In macOS, the following are automatically given local network access and don’t appear in Local Network settings:
any daemon (except agents) started by launchd
any process running as root
command tools run from Terminal or using SSH, including their child processes; however, there are reports that closing Terminal while child processes are still running can lose their exemption, and cause their local connection to be broken
traffic from Safari and WebKit (WKWebView)
access to a local DNS server or network proxy
high-level services using Bonjour internally, including AirPlay, printing, device discovery and accessory setup.
Those exempt the majority of processes regular users are likely to run.
Listening for and accepting incoming TCP connections doesn’t require any privilege, nor does receiving an incoming UDP unicast. Resolving a local DNS name, ending in .local, does require privilege, though, as do all Bonjour operations other than those exempted above.
Known problems
A process with a short life that immediately fails if it can’t complete a local network operation may not trigger a user prompt, and can continue to fail repeatedly as it can’t be granted the privilege. Apple recommends changing the code so that it doesn’t exit immediately after failure, to allow the prompt to be displayed and access granted.
There’s currently no way to reset an app’s Local Network setting.
Prompts to grant the privilege of local network access can appear out of the blue when an app accesses certain third-party libraries. It can be hard to trace the origins of those, but if you can work out which app is most probably responsible, you can report this to its developer.
Local network privacy, like other similar protection, relies on tracking apps by their code signature, so works best with code signed with certificates issued by Apple, rather than ad hoc signatures. It also relies on the UUID of the main executable code; in some cases that may be absent, or shared with other code, and can then behave unpredictably. These should be raised with the app developer.
Key points
macOS Sequoia and Tahoe apply restrictions to local network connections. Although few are likely to encounter them, don’t be surprised to be prompted to allow or deny a local network connection. Control those in the Local Network section in Privacy & Security settings as necessary.
Login
to indicate success, or a warning triangle or error symbol if the test couldn’t be attempted (power supply when not connected to a laptop) or problems were discovered. Individual tests and their results are listed from each test’s ⓘ button. After all these years, Apple is finally trusting us to know what tests have been performed, and not just giving us a cryptic code at the end.
