However compact and portable Macs become, there’s still nothing like plugging an external drive into any Mac and getting to work in your familiar home environment. What used to be so quick and simple with older Macs is still possible on Apple silicon, but negotiating ownership and Secure Boot makes it more fiddly and prone to failure. Rather than booting the whole Mac from your mobile SSD, why not open a Virtual Mac instead?

Forget, for the moment, the fact that in its current incarnation lightweight virtualisation of macOS on Apple silicon doesn’t support Apple ID or iCloud. Turn its storage limitations on their head: instead of its shared folders holding files for both the guest and host, use them for your working documents. Most importantly, stop thinking of lightweight virtualisation as some sort of party trick or novelty.

The goal in this demonstration is to build and run my app SilentKnight from its Xcode project, entirely within a lightweight Ventura VM run from an external SSD connected to my Mac Studio M1 Max. To start with, I picked a fast and capable SSD, an OWC Envoy Pro SX 4 TB, connected to the Studio using a Thunderbolt 4 cable. The VM is the same that I built for testing disk performance, 120 GB in size, here run with 4 cores and 16 GB of memory.

The most difficult part proved to be installing Xcode, which is something of a beast at the best of times. Knowing the potential benefit in performance, I first tried running a copy of Xcode 14.1 from the VM’s shared folder. To make this easier to access from the host Mac, I created a nested folder within that, and a Finder alias for the host to give direct access into the share. However, when I tried to launch Xcode from there it wouldn’t oblige, even after several minutes of bouncing in the Dock as it verified.

My next attempt was to copy the Xcode app from the shared folder into the Applications folder in the VM. That promised to be painfully slow, predicting two hours to complete the copy, so I went for a five-mile walk, at the end of which the copy had failed with a strange error. My final attempt was to download the compressed .xip presentation of Xcode available to developers, copy that into the VM’s Applications folder, then expand-install it in place. That proved both quick and free from error. Although I couldn’t run Xcode from the VM’s shared folder, I copied a couple of my Xcode projects into that, including that for SilentKnight.

First launch of Xcode was brisk, and it soon installed its tools into the VM, and was ready for me to open my SilentKnight project. Once I had addressed its signature issues, described below, SilentKnight built quickly and the product ran happily, just as it would when running native on my production Mac.

This screenshot shows the newly built SilentKnight running correctly in front of its project, in Xcode, all in my mobile VM totalling 141 GB. However intellectually pleasing it might appear, don’t try building your own virtualiser in a VM, as nested virtualisation isn’t supported, so your app won’t be able to run.

The biggest limitation to this is in signing and notarization, as a result of lightweight macOS VMs not having access to services requiring Apple ID or iCloud. Because I was unable to connect Xcode to my developer account, I was unable to sign the built app with my Developer ID Application certificate and to send it for notarization. What I have here is fine for local development and testing, but not for distributing a product to others.

As my Mac Studio only handed over the equivalent of four of its P cores and 16 GB of memory to the VM, it still had four remaining P cores and its two E cores, and another 16 GB of memory in which I could run apps on the host. All disk space used was on my external SSD too, and the host macOS and its internal SSD only had to host the VM.

The major remaining obstacle to using lightweight macOS VMs as mobile virtual Macs is their lack of support for Apple ID and the services that enables, including iCloud. While improving write performance to the disk image used as the VM’s boot volume group remains an important goal for Apple, a little ingenuity and a fast SSD can accomplish near-native performance. But until Apple removes the Apple ID constraint, the mobile virtual Mac will remain of limited use.