Apple has released the update to bring macOS Tahoe to version 26.5, and security updates for Sequoia and Sonoma to bring them to 15.7.7 and 14.8.7.
If you were expecting 15.7.6 or 14.8.6, then you’ll be as surprised as I was that Apple appears to have skipped those and gone straight on to x.x.7. I haven’t seen any explanation for this curious change in version numbering.
Download size for the 26.5 update on an Apple silicon Mac is around 3.8 GB, and the last 5 minutes of preparation takes maybe a tad longer than that. Intel Macs should download around 2.9 GB instead.
In Apple silicon Macs, firmware is updated to mBoot 18000.120.36, while Intel firmware is updated to 2103.100.6.0.0 (iBridge 23.16.15067.0.0,0).
Release notes are the bland and unhelpful statement that “This update includes enhancements, bug fixes, and security updates for your Mac.”
Security release notes are here for Tahoe with around 69 vulnerabilities fixed including more kernel bugs than I’ve ever seen in a single update, here for Sequoia with around 45, and here for Sonoma with a mere 43 or so.
Apple still hasn’t posted any enterprise release notes here but might think of something to report later.
With the continuing reluctance of many to upgrade to macOS Tahoe, some are seeking compromise by retaining access to both macOS 15 Sequoia and 26 Tahoe in a dual-boot system. This article explains how you can do that on an Apple silicon Mac, and choose between
both systems installed in a single container on the internal SSD,
each installed in a separate container on the internal SSD,
one on the internal SSD, the other on an external SSD,
one on the internal SSD, the other in a virtual machine (VM).
These have become more complicated with Apple silicon Macs because, unlike Intel Macs, they’re designed to boot from external disks in full security. To achieve that, they have to start their boot process from their internal SSD, and that stores LocalPolicy files to enable handover to a boot volume group such as that on an external disk. The structure of their internal SSD is also more complex, with two hidden containers, as well as the bootable system in a boot volume group, as shown below.
One common requirement for all except a VM is that the Mac needs to be compatible with both versions of macOS that you intend to run. For example, those models with M5 chips released after Tahoe on 15 September 2025 will never be able to install Sequoia. If you want to run Sequoia on one of those, then your only option is to install it in a VM.
Another general principle is that the closer the two versions of macOS are, the better dual-booting will work. Running Sequoia and Tahoe side by side shouldn’t be a problem, but the combination of Monterey and Tahoe could prove more troublesome.
When setting up any dual-boot Mac, it’s easier to do so when booted from the older version of macOS. This is because the installer for an older version of macOS may be blocked when running a more recent version. If that isn’t possible you’ll almost certainly need to create a bootable installer disk and run the installation from that. Apple describes how to do that in this support article.
Apple’s terse summary is perhaps too generic to be useful.
Single container, internal SSD
This is by far the most straightforward and most popular option for dual-booting, where both versions are installed into the same APFS container on the internal SSD. This has the advantage that each of the volumes in the two boot volume groups shares free space within that single container.
To install the second macOS you’ll need to create a new APFS volume on the internal SSD with the name you want to give that new system, then select that as the destination for the macOS Installer. What you should end up with is complex, as it consists of the standard five (or six) volumes, plus a second pair of System and Data volumes with their own Sealed System Volume (SSV) snapshot, making a total of seven or eight volumes and two SSV snapshots, all in the single container. The two bootable systems should then share a common paired Recovery volume, and Fallback Recovery in its separate container.
Because these volumes all share a single container, any problems that arise could compromise both systems, so maintaining good backups of each is particularly important.
Two containers, internal SSD
Instead of installing both systems into the same container, it’s also possible to repartition the internal SSD to add another container into which you install the second system. If you want to try this, you’ll need to perform that repartitioning before the first macOS has taken up too much space on the internal SSD, or the repartitioning may end up being destructive and require both systems to be installed afresh, which would be even more complex and risky.
For this reason, installing the two systems into separate containers on the internal SSD is seldom attempted, despite its advantage of robustness for the systems. Because they’re in separate containers, each system is independent, and likely to have its own paired Recovery volume. In theory at least, if one container were to run into problems, it may be possible to boot into the other system and attempt to repair the damaged system from there, although I’ve not heard of anyone doing that.
One internal, the other external
This is a popular and more robust alternative, as the two (or more) systems are physically separate. However, the two systems aren’t equals, as all boots must still start from the internal SSD before handing over to the external system. This can’t enable the Mac to boot entirely from the external disk in the way that an Intel Mac can.
There are drawbacks in booting from an external disk. Its speed can’t compare with that of an internal SSD, and it can’t use hardware encryption for FileVault. But external disks are also mobile between Macs, so if you want to be able to boot more than one Mac from the same boot volume group, it has to be installed on an external disk.
I provide detailed instructions for installing the external system in these articles:
If you need more than two versions of macOS, you could install multiple boot volume groups into a single container on the external disk, or separate them into their own containers. This has become popular for those like developers who need access to multiple versions of macOS for testing.
Below is a typical partition/container containing two bootable systems named ExternalA and ExternalB. This has two Boot Volume Groups, each consisting of a System volume with its SSV, and a Data volume, to which are added their three common volumes, Preboot, Recovery and VM.
One internal, the other in a VM
Virtual Machines are the cleanest of all the options, as their boot volume group is installed inside a disk image, and tucked away within a bundle. You can store them where you like, move them between Macs, and do the most horrible things to them with little fear: if anything goes wrong, you can just delete the VM and build yourself a new one.
Ideal for software developers and security researchers, macOS VMs running on Apple silicon Macs perform almost as well as the host they’re running on, and support Rosetta 2 so they can run Intel-only code when needed. However, they can’t run Big Sur or earlier, have limited features for Monterey guests, and only support iCloud access when Sequoia (or later) is running in the guest and host. Most surprisingly, though, they’re unable to run many App Store apps, so before committing to using a VM check that the apps you need can be run inside one.
Tips
General:
The host Mac must be capable of running that version of macOS, unless it’s in a VM.
macOS installers are the most reliable means of creating and installing Boot Volume Groups.
When using a laptop Mac, run it from mains power throughout macOS installation.
Each container with one or more Boot Volume Groups should contain one set of Preboot, Recovery and VM volumes shared between them.
Older macOS:
When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
Boot from the installer volume through Recovery mode.
Bootable external disks:
During macOS installation, an external disk must be connected to a port other than the DFU port, as listed here and in Mactracker.
Apple silicon Macs will boot from external disks in Full Security, and reducing that doesn’t solve any problems.
APFS:
The first and fundamental step in trying to diagnose problems with multiple Boot Volume Groups or bootable external disks is to examine their container and volume structure using two diskutil commands: diskutil apfs list
to list all APFS volumes by container and give key information about each, including their role and UUID, and diskutil apfs listVolumeGroups
to list all recognised Boot Volume Groups, which you can tally against the first. Pipe these to text files so you can study and refer back to them. Example output from the second is: +-- Container disk5 5BA1AAC8-3AD4-4594-AF01-7C0AA75CABAD
| |
| +-> Volume Group 68627CBB-D774-444E-97C6-F9511B5030F3
| =================================================
| APFS Volume Disk (Role): disk5s1 (Data)
| Name: Macintosh HD - Data
| Volume UUID: 68627CBB-D774-444E-97C6-F9511B5030F3
| Capacity Consumed: 580769214464 B (580.8 GB)
| -------------------------------------------------
| APFS Volume Disk (Role): disk5s5 (System)
| Name: Macintosh HD
| Volume UUID: 8B9FF440-75C8-4F7F-B09E-9222D44A2276
| Capacity Consumed: 11239186432 B (11.2 GB)
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.
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.
Login
