Before Apple silicon Macs, you’ve been able to run different versions of macOS, Linux or Windows in third-party virtualisers, such as those from VMware and Parallels. Those products enable a virtual machine running a different operating system to be hosted in macOS, both running code for Intel processors. As part of its engineering preparations for the switch to using Arm processors, Apple decided that the only practical way to support virtualisation on its new Mac hardware was to build it into macOS. This was to enable older versions of macOS, and other operating systems including Linux and Windows for Arm, to run in virtual machines.

This is quite different from the more challenging problem of running operating systems for different processors, such as Intel, on Apple silicon Macs. Although Intel apps can have their code translated by Rosetta 2, that doesn’t work for operating systems, which need a software emulator, a feature left for the likes of UTM.

Hypervisor

The fundamental requirement for modern virtualisers hosted on a primary operating system like macOS is a hypervisor, which Apple added to macOS back in OS X 10.10, in 2014. Like Intel processors, Arm CPUs provide hardware support for hypervisors, so much of the remaining work to implement virtualisation in Apple silicon Macs centred on device support. That had been relatively straightforward for Intel Macs, as they mainly use PC hardware components, but that isn’t the case for Apple’s new Macs.

Virtio drivers

Every single hardware device in an Apple silicon chip is different from its equivalent (if there is one) in Intel Macs. Even if Apple had wanted to document them fully for external use, the engineering effort to match device support in Intel Macs would have been too costly for any third party. Thus starting with a hypervisor and expecting others to build a complete virtualiser wasn’t feasible, nor was it likely to result in the high performance that Apple and users expected. What Apple did instead was to build device support into macOS, in the form of Virtio drivers.

Virtio is a standard originally developed by Rusty Russell to provide an abstraction layer over I/O devices. When the guest operating system calls to open a file, for example, that’s passed to a front-end Virtio storage device para-driver, and from there into a Virtio back-end driver that interacts with the storage device. Although this might seem less efficient than traditional virtualisation, in practice it can prove far more efficient.

Its most obvious advantage is that creating a virtualiser app becomes a matter of configuring and opening the required Virtio devices, and letting the guest, Virtio and the host get on with it. And that’s essentially what an app does with Apple’s Virtualisation framework.

Apple’s choice of Virtio was undoubtedly swayed by the fact that Linux already has good Virtio support, but at the time macOS had none. In the couple of years preceding the release of Monterey, Apple’s engineers thus set about building Virtio support into macOS, which explains why macOS lightweight virtualisation is only available in Monterey and later hosts, and when running Monterey and later guests. As implemented in macOS (both as guest and host), there are also extensions to support keyboard and pointing devices, a shared clipboard, and high-performance graphics with Metal and GPU support.

In the Virtio model, providing such support is the task of the operating system, not the virtualiser. For vendors like VMware and Parallels this reduces not only the cost of development, but also the commercial value of their products; there’s no scope for either of them to engineer better or faster graphics support, as that’s determined by features provided in both guest and host operating systems, via Virtio or an equivalent. That puts Apple in charge of what hardware and features are supported by virtualisation on Apple silicon.

Performance

On the other hand, it guarantees optimum performance in VMs. Not only is their CPU and GPU code run direct on the hardware, just as in the host, but Virtio devices deliver almost as good performance as on the host. Comparable Geekbench 6.3.0 benchmarks when running macOS Monterey as both guest and host are:

• CPU single core VM 3,643, host 3,892
• CPU multi-core VM 12,454, host 22,706 (limited by the number of cores available)
• GPU Metal VM 102,282, host 110,960, with the VM as an Apple Paravirtual device.

Subsequent versions of macOS have improved on those. It’s worth noting that virtual cores allocated to a VM are primarily Performance cores, so threads running in the VM that would normally be run on Efficiency cores normally run significantly faster than they would do in the host.

Initially, performance of VM primary storage in its disk image wasn’t good, but more recently this has improved substantially, even with FileVault enabled in the VM.

Rosetta 2

Although it can’t be used to translate a guest operating system, Rosetta 2 can still be used inside a macOS VM to translate and run 64-bit Intel code in apps that are compatible with macOS 10.15 Catalina, but is subject to the same limitations as any version of macOS on Apple silicon, in that it can’t handle older or 32-bit apps. This will become most useful when Apple drops full support for Rosetta in macOS 28. VMs with older versions of macOS will still be able to translate and run compatible 64-bit Intel code, even though the host won’t be able to.

Major limitations

Support for iCloud and iCloud Drive access wasn’t made 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.

The greatest remaining limitation in virtualising macOS on Apple silicon is its inability to run many apps from the App Store. Although some do run without problems, any that check their App Store credentials will fail, as a VM can’t be signed into the App Store. 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, even though they can connect using the host’s 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.

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.

Usage

Some examples of what you can use a macOS VM for:

• run apps compatible with Sonoma but not Sequoia, on M4 and M5 Macs that can’t run Sonoma;
• run apps in a custom environment, e.g. with different region and language settings;
• check and access potentially malicious documents or apps in a locked-down environment;
• test compatibility with multiple versions and localisations of macOS;
• work with highly sensitive data, in an isolated environment;
• access a different iCloud account simultaneously;
• run beta-test versions of macOS 27.

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, and support FileVault;
• access iCloud and iCloud Drive only when both host and guest are running Sequoia or later;
• but they can’t run most App Store apps.

One of the new features coming in the next update to Tahoe, taking it to macOS 26.4, is a Rosetta warning. When you run Intel code on an Apple silicon Mac, macOS will start warning you that you won’t be able to do that in the future. At first, those will be infrequent, but as time passes their cadence will increase. This article explains why, and what you can do about it.

Virtualisation, emulation and translation

Although we’d all love to be able to run only native apps on Apple silicon, that isn’t always possible. Sometimes the app we need to use is only available for another platform, most commonly Intel. You can’t run code for a different processor in a virtual machine, though. VMs run at near-native speed only because the instructions they’re running are for the same processor. What they’re virtualising are the operating system calls, which are passed through to the host.

The traditional way to run code on a different processor is by emulation in a software engine that converts from one instruction set to another. That’s comparatively slow even on modern high-speed processors, so Rosetta 2 opts for a different approach that proved highly successful in the transition from PowerPC to Intel processors from 2006: it translates the code before running it natively. Rosetta 2 does this so well that the translated code often runs almost as fast as it would on the original processor.

Problems

One of the most common reasons for still requiring to run Intel code on Apple silicon stems from the fact that you can’t mix Arm and Intel code in the same process. Although an app might be Universal, and can run entirely on Arm, if it needs to load code modules that are still only available for Intel, then the whole app must be run for Intel, and be translated by Rosetta.

There are also two no-go areas that can’t be addressed by Rosetta: kernel extensions, and virtual machines running an operating systems for a different architecture. If you wanted to run an Intel version of Windows or Linux on your Apple silicon Macs, then you’d have to use emulation. Although this has been done for older Intel-only versions of macOS, it’s painfully slow and fragile.

One less common limitation of Rosetta 2 is that it doesn’t support AVX512 vector instructions, although it does support AVX and AVX2 instructions; that should affect very few apps.

Timescale

To help in forward planning, Apple has already set out its intentions:

• Fall 2026, just 6 months away now, macOS 27 will run only on Apple silicon Macs, but will continue to enjoy full Rosetta 2 support. Security-only support will continue for Sequoia and Tahoe.
• Fall 2027, macOS 28 will lose full Rosetta 2 support, although it will retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks”. Security-only support will continue for Tahoe.
• Fall 2028, all support will cease for Intel versions of macOS.

Running Intel code in the future

If you do still depend on running Intel code, the best solution will be to replace that with an update that will run native on Arm. Apple’s increasing Rosetta warnings are intended to nudge us, and the few developers who haven’t yet produced Universal versions of apps, plug-ins, etc., to do so.

The most intractable problems are with code from developers who either can’t or won’t support Apple silicon. If their code is tied to hardware products that may never be addressed, and you may find the only solution is to keep some Intel Macs in service. But for most other situations, you should be able to continue running Intel code in a macOS virtual machine.

You can test this now using your favourite virtualisation app. Set up a suitable VM and install your app in it. In this example I opted to run my utility Mints using Rosetta rather than natively.

Just as in the host, when you first try to run the app, Rosetta will intervene and offer to translate it for you. The first time you do that, Rosetta will need to be downloaded first.

I chose Mints for this demonstration, as its Mach Absolute Time feature runs in Intel mode when Mints has been translated by Rosetta, as shown here.

Virtualising earlier versions of macOS doesn’t offer as wide a range of features, but if you can run your Intel-only app in Sonoma or later, using Rosetta translation, it should run very well in a VM of the same version of macOS, on a host running macOS 28 after full Rosetta support has been removed. And that should continue to work until a future version of macOS is no longer able to run such an old VM. Hopefully that will be long after 2028, but now is the time to try it.