Apple Silicon host required, no way around it

A macOS guest needs an Apple Silicon Mac as the host — on Intel, Linux guests are still fully supported, but macOS guest creation isn't available at all. This isn't a Velo Workspaces limitation to work around; it's how Apple's Virtualization framework draws the line, and every macOS-guest code path in the app is conditionally compiled for arm64 only.

"Download an official image" means exactly one thing here

Every post in the Linux series so far has been about picking which official image — which distro, which release. macOS removes that choice entirely: the official path fetches the single latest supported macOS build for this specific Mac, full stop, using Apple's own restore-image API. There's no version picker, no browsing a catalog of older-but-still-supported releases the way you'd pick an Ubuntu LTS or a specific Fedora release.

If you specifically need something other than the current latest build, the local-file path is still there — the same drop zone that takes an ISO, DMG, or IMG also accepts an .ipsw file directly, so a restore image you've sourced yourself works the same way a hand-picked Arch Linux ARM image does in that series. The official picker just won't hand you a choice on its own.

The GPU story here is the opposite of every Linux post in this series

This blog has covered, more than once, that Apple's Virtualization framework gives a Linux guest virtio-gpu — a paravirtualized 2D framebuffer with no path to the host's actual GPU — which is exactly why AI Bridge exists as a workaround for AI inference specifically. A macOS guest doesn't hit that wall at all: Apple's platform gives it a dedicated Metal-backed graphics device, built specifically to provide near-native GPU performance to a macOS guest through the Metal API. Real GPU acceleration, not a 2D fallback — the constraint covered repeatedly for Linux guests, including in the Parallels/UTM comparison, simply doesn't apply to this guest type.

Input feels native for the same underlying reason: a macOS guest gets real trackpad and keyboard passthrough, including multi-touch gestures — two-finger scroll, pinch-to-zoom, Mission Control swipes — not just basic pointer and keystroke forwarding. Combined with the graphics story, a macOS guest is meant to feel like using another Mac, in a way a Linux guest's console never tries to.

Shared folders, with no mount command

Every Linux post in this series has included a manual mount -t virtiofs step for shared folders. macOS guests skip it: Apple's platform mounts every shared folder automatically under /Volumes/My Shared Files/<name> the moment the guest boots, through a reserved automount mechanism rather than the per-folder tags a Linux or Windows guest still needs. One real caveat worth knowing: an older macOS guest that predates this mechanism simply won't recognize the automount tag and will mount nothing — the same silent "nothing happens until you notice" failure mode as an unsupported host elsewhere in this app, not an error message pointing at the actual cause.

The gotcha: a macOS workspace's disk isn't self-contained

This is the one worth knowing in advance, the same spirit as the Netplan/MAC-address gotcha in the Ubuntu post. A macOS guest's hardware model, machine identifier, and auxiliary boot storage are stored beside its disk image, not inside it — three separate files in a metadata folder that travels with the workspace. Copy or move just the .img disk file on its own — to back it up, share it, or move it by hand — and you get a workspace that can't start, because the platform data it needs to boot isn't there. If you're moving a macOS workspace around outside the app's own tooling, the disk alone was never the whole picture.

What doesn't come along for the ride

Two honest scoping notes, both real gaps rather than oversights. Rosetta here isn't a Velo Workspaces feature at all. The VirtioFS share and the manual binfmt registration covered throughout the Ubuntu, Debian, and Fedora posts are specifically a Linux-guest mechanism, gated to Linux in the app itself. A macOS guest doesn't need any of that: it's a complete, ordinary macOS installation, so running an x86-64 Mac app just triggers Rosetta 2 the standard way, the same as it would on real Apple Silicon hardware — nothing Velo Workspaces has to wire up, because there's no host/guest boundary to bridge for it.

AI Bridge is scoped to Linux guests too. If what you actually want is the host-GPU model-serving setup described in the AI Bridge architecture post, that's a Linux workspace's feature specifically — a macOS guest doesn't need it for the same reason it doesn't need Rosetta's workaround: it already has real GPU access of its own.

Related reading: the Linux side of this — Ubuntu, Debian, Fedora, and Arch Linux on Apple Silicon; the architecture behind AI Bridge and why it exists specifically for Linux guests; how the GPU story compares to other VM apps on the same hardware; and, if you seal a macOS guest as a base image, a naming convention worth using since the app itself tracks no version history between generations. Or download Velo Workspaces and try it yourself.