What can you do with virtualised macOS on Apple silicon?

If you want to run an older version of macOS that your Mac doesn’t support, so can’t boot into, then the only option is to run it within your current macOS. You may be able to do that using one of two methods: virtualisation or emulation. Emulation is normally used when the older macOS runs on a different processor, while virtualisation may be available when the processors share the same architecture.

Running Intel macOS

If you want to run a version of macOS for Intel processors, including Catalina and earlier, then your Apple silicon Mac has to run a software emulation of an Intel processor for that to work. Although this is possible using UTM, emulation is slow and not reliable enough to make this feasible for everyday use. It’s impressive but not practical at present. For an Apple silicon Mac, that automatically rules out running any macOS before Big Sur, the first version with support for Arm processors.

Rosetta 2 for Apple silicon Macs isn’t an emulator, although it allows you to run code built for Intel Macs on Apple silicon. It achieves that by translating the instructions in that code to those for the Arm cores in Apple silicon chips. This is highly effective and in most cases runs at near-native speed, but Rosetta 2 can’t be used to translate operating systems like macOS, so can’t help with running older macOS.

Virtualisation

Virtualisation is far more practical than emulation, as it doesn’t involve any translation, and most code in the virtualised operating system should run direct on your Mac’s CPU cores and GPU. What is required for virtualisation to work is driver support to handle access to devices such as storage, networks, keyboards and other input devices. Those enable apps running in macOS inside the virtual machine (VM), the guest, to use features of the host Mac.

Virtualisation of macOS, Windows and Linux have been relatively straightforward in the past on Intel Macs, as they’re essentially PCs, and providing driver support for guest operating systems has been feasible. That has changed fundamentally with Apple silicon chips, where every hardware device has its own driver unique to Apple, and undocumented. Without devoting huge resources to the project, it simply isn’t feasible for third-parties to develop their own virtualisation of macOS on Apple silicon.

Recognising this problem, Apple has adopted a solution that makes it simple to virtualise supported macOS (and Linux) using a system of Virtio drivers. Those have been progressively written into macOS so that it works both as a guest and host, for services that are supported by a Virtio driver, and all versions of macOS since Monterey have been able to virtualise Monterey and later when running on Apple silicon.

The drawback is that, although features supported by Virtio drivers are readily implemented in virtualisers, those that aren’t can’t be supported unless Apple builds a new Virtio driver into macOS. Even then, that new feature will only be available in that and later versions of macOS on both host and guest, as support is needed in both before it can work.

Another important consequence of virtualisation being built into macOS is that different virtualising apps all rely on the same features, and act as wrappers for macOS. While different apps may offer different sets of features and present them in their own interface, virtualisation is identical inside them. I’m not aware of any macOS virtualiser on Apple silicon that doesn’t use the API in macOS, and they all share its common limitations and strengths. This also means that, when there’s a bug in virtualisation within macOS, it affects all virtualisers equally.

macOS support

Early Virtio support appeared first in macOS Mojave and gathered pace through Catalina and Big Sur, but the first version of macOS to support virtualisation of macOS on Apple silicon Macs was Monterey 12.0. That means that no Mac released after the release of Monterey in the autumn/fall of 2021 will ever be able to run Big Sur, as their hardware isn’t supported by it, and macOS 11 can’t be virtualised. The only way to retain access to Big Sur is to keep an M1 Mac that shipped with it, the last of which was the iMac 24-inch M1 of 2021. However, it also means that the latest M4 Macs can run Monterey in a virtual machine, even though the oldest macOS they can boot into is Sequoia.

When the host or guest macOS is Monterey, sharing folders between them isn’t supported, and the only way to share is through network-based file sharing, which is less convenient. Display support was enhanced in Ventura, which again is required on both guest and host for it to be available.

Support for iCloud and iCloud Drive access didn’t become available in VMs until Sequoia, and now requires that both the guest and host must be running macOS 15.0 or later. As VMs that support these features are structurally different from earlier VMs, this also means those VMs that have been upgraded from an earlier macOS still can’t support iCloud or iCloud Drive. Only those built from the start to support Sequoia on a Sequoia host can support them.

Virtualisation can also have limited forward support, and is widely used to run beta-releases of the next version of macOS. This should be straightforward within the same major version, but testing betas for the next major version commonly requires the installation of additional support software. However, support for running betas is less reliable, and may require creation of a new VM rather than updating.

Many aren’t aware that Apple’s macOS licences do cover its use in VMs, in Section 2B(iii), where there’s a limit of two macOS VMs that can be running on a Mac at any time. This is enforced by macOS, and trying to launch a third will be blocked. For the record, the licence also limits the purposes of virtualisation to “(a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.” It’s worth noting that Apple discontinued macOS Server on 21 April 2022, and it’s unsupported for any macOS more recent than Monterey.

Major limitations

The greatest remaining limitation in virtualising macOS on Apple silicon is its complete inability to run apps from the App Store, apart from Apple’s Pages, Numbers and Keynote, when copied across from the host. Even free apps obtained from the App Store can’t be run, although independently distributed apps are likely to be fully supported. This appears to be the result of Apple’s authorisation restrictions, and unless Apple rethinks and reengineers its store policies, it looks unlikely to change.

Some lesser features remain problems. For example, network connections from a VM are always treated as being Ethernet, and there’s no support for them as Wi-Fi. Audio also remains odd, and appears to be only partially supported. Although Sequoia has enabled support for storage devices, earlier macOS was confined to the VM’s disk image and shared folders. Trackpads don’t always work as smoothly as on the host, particularly in older versions of macOS.

Strengths

One of the most important features is full support for running Intel apps using Rosetta 2.

That and other performance is impressive. CPU core-intensive code runs at almost identical speed to that on the host. Geekbench 6 single-core performance is 99% that of the host, although multi-core performance is of course constrained by the number of cores allocated to the VM. Unlike most Intel virtualisers, macOS VMs attain GPU Metal performance only slightly less than the host, with Geekbench 6 Metal down slightly to 94% that of the host.

VMs are mobile between Macs, even when built to support iCloud and iCloud Drive access. Because each VM is effectively self-contained, this is an excellent way to provide access to a customised suite of software with its own settings. As disk images, storage in VMs is normally in sparse file format, so takes a lot less disk space than might be expected. It’s also quick and simple to duplicate a VM for testing, then to delete that duplicate, leaving the original untouched.

Future

Virtualising macOS on Apple silicon has relatively limited value at present, but in the future will become an essential feature for more users. Currently it’s most popular with developers who need to test against multiple versions of macOS, and with researchers, particularly in security, who can lock a VM down with its security protection disabled.

Few apps that ran in Big Sur or Monterey are no longer compatible with Sequoia. As macOS is upgraded and newer Macs are released, that will change, and virtualisation will be the only way of running those apps in the future, much as virtualisation on Intel Macs is for older macOS.

There will also come a time when Apple discontinues support for Rosetta 2 in the current macOS. When that happens, virtualisation will become the only way to run Intel apps on Apple silicon.

However, until App Store apps can run in VMs, for many the future of virtualisation will remain constrained.

Summary

macOS VMs on Apple silicon can:

run Monterey and later on any model, but not Big Sur or Intel macOS;
run most betas of the next release of macOS;
run Intel apps using Rosetta 2;
deliver near-normal CPU and GPU performance;
access iCloud and iCloud Drive only when both host and guest are running Sonoma;
but they can’t run any App Store apps except for Pages, Numbers and Keynote.