When macOS won’t work with the App Store

Building software to virtualise another operating system on a Mac used to be a flourishing trade. Two major contenders emerged: VMware, which grew in 25 years to have total assets of over $30 billion with over 38,000 employees, and Parallels, a smaller company now a subsidiary of Corel. Broadcom completed its acquisition of VMware a month ago, and is in the throes of its reorganisation; after initially showing no interest in virtualising on Apple silicon Macs, it has failed to catch up rival Parallels, and still doesn’t support macOS guests on M-series Macs.

Parallels has made no secret of its partnership with Apple in virtualisation on Apple silicon, but its popular Desktop range of products now lag behind most of the free virtualisers available. For the moment at least, the field is dominated by independents, and essentially non-commercial, unlike virtualisation of Windows.

Virtualising macOS is important for Apple silicon Macs, as it’s so much simpler and more convenient than booting the whole Mac from a different version of macOS. Whether you’re a developer, researcher, or just need to be able to run older software incompatible with current macOS, macOS virtual machines (VMs) can be a much better choice.

Unlike Intel Macs with T2 chips, Apple silicon models will boot from external storage without reducing their boot security. It’s possible, if finicky, to keep an external disk with several bootable systems on it. When anything goes wrong, though, maintaining those disks can become difficult. As macOS VMs enjoy close to native performance when run, many of the benefits of booting the whole Mac into an old version of macOS are lost.

Besides that, any Apple silicon Mac can run a VM going back to Monterey, but sadly not as far as Big Sur, which lacks the internal support required for Virtio. Those who need to run any version of macOS older than their Apple silicon Mac will thus need to do so within a VM. You then don’t have to hang onto an old M1 Mac mini when you’ve moved your production system to an M3 or M4 model.

Virtualisation also has significant security benefits. During their two years of security-only macOS updates, older boot systems fall steadily behind in patches to known vulnerabilities, progressively becoming more insecure until they’re finally abandoned, as Big Sur already has been. Careful use of a suitably locked-down VM poses far less risk to its host Mac than booting the whole Mac into a more vulnerable version of macOS.

VMs are also far easier to handle, and less wasteful of disk space. Although it’s feasible to keep two or three bootable systems in one container, experience shows that it then becomes preferable to keep more in separate containers of fixed size. As VMs are stored as sparse files, a single folder can contain dozens of VMs of 100 GB nominal size, when each only takes around 15-20 GB of disk space. There’s also a trick you can use to save disk space and trashing a VM during testing: duplicate an existing VM in the Finder, to clone its contents. Once you’re finished with it, trash the clone and repeat as much as you wish.

The biggest limitation, and the elephant in the room, is the complete lack of support for signing in with an Apple ID. iCloud Drive access from a VM is possible through the host, although as apps running in the VM can’t recognise that they’re dealing with cloud storage, that can get fraught at times. But without an Apple ID, no third-party apps distributed through the App Store can be run in a macOS VM on an Apple silicon guest, even if they’re free to use.

While Apple has been steadily improving macOS virtualisation since it was released over two years ago, there has only been silence over Apple ID. This is most probably the result of a direct conflict between the inherent untrustworthiness of VMs and the host Mac’s need to protect the Apple ID and its password. VMs are likely to be running a version of macOS that lacks some if not many of the protections of the current release. The VM may even be deliberately affected by malicious software designed to exfiltrate passwords. While the Virtio driver architecture works well for most services provided by the host, it hasn’t been developed with security in mind, for which it looks quite inappropriate. Finally, VMs are by definition both portable and ephemeral, the antithesis of what you’d want to store and use an Apple ID.

I can’t believe that Apple hasn’t been wrestling with these issues for several years now, but there’s still no solution in sight. Maybe we’ll see some form of proxy arrangement with the host Mac that allows a VM to run App Store apps. Until then it remains the deepest irony, that virtualisation of macOS on Apple silicon is so accessible, unless you want to access apps from Apple’s own store.