Limitations on macOS Virtual Machines
This is a draft summary of the limitations of lightweight virtualisation of macOS on Apple silicon Macs, using the macOS API in late versions of Ventura and early Sonoma, VMs designated VirtualMac2,1.
[…]
Shared folders are only available in Ventura and later VMs. Transferring items using drag and drop is available in all VMs by using Screen Sharing or ARD.
[…]
Apple ID isn’t supported in VMs, and they can’t be connected to iCloud Drive or support apps using CloudKit. This means that VMs can’t run the great majority of App Store apps, apart from Apple’s free products such as Numbers, Pages and Keynote.
[…]
The shared clipboard to allow copy and paste between host and VM currently appears non-functional, at least when using Apple’s example code.
With all the limitations, I’ve never gotten into using macOS VMs the way I expected to. I do testing using a second Mac either directly or via Screen Sharing. It has multiple partitions for different macOS versions, and the data volumes can be rolled back via APFS snapshots to reset things if necessary.
Previously:
- Why You Can No Longer Roll Back a macOS Update
- Beta Updates in a macOS VM
- Public Developer Betas
- macOS 14 Sonoma Announced
- Apple Silicon Virtualization Apps
- How Apple Limits VMs
Update (2023-12-29): Howard Oakley:
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.
Lack of Apple ID-mediated services like iCloud and developer stuff is a killer for me.