Dual-boot an Apple silicon Mac in Sequoia or Tahoe

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)