Deep dive

Virtualization.framework vs. QEMU on Apple Silicon

Not a verdict, but an engineering comparison. One is a purpose-built Apple API with a small, curated device set; the other is a general-purpose machine emulator that predates Apple silicon by well over a decade and added a hardware-accelerated backend for it. Where they differ matters more than which is "better".

By Gaoliang Luo · Published September 22, 2026 · Updated September 28, 20264 min read

In this article

Two different starting points
Hardware acceleration: the same silicon under both
Where they diverge: emulating other architectures
Devices: curated or exhaustive
Guest operating systems
The entitlement most comparisons skip
Where performance differences come from
Building with each
Which to reach for

Two different starting points

Virtualization.framework was built as a native macOS API for one job: run Linux or macOS guests on a Mac using the CPU's virtualization extensions. QEMU is a general-purpose machine emulator and virtualizer that emulates dozens of CPU architectures and hundreds of hardware configurations; its Apple silicon support is an accelerated backend added to that much older, much broader project. Neither fact makes one better, but together they explain nearly every difference below.

Hardware acceleration: the same silicon under both

This surprises people expecting a bigger gap. On Apple silicon, QEMU's -accel hvf uses Apple's Hypervisor framework, the same low-level API that gives Virtualization.framework access to ARM's EL2 extensions (see the ARM performance deep dive). For an arm64 guest on an arm64 Mac, both tools ask the same hardware to do the same job. Neither is faster at CPU traps, memory translation or interrupt delivery, because neither implements that layer; Apple's silicon and Hypervisor framework do.

Where they diverge: emulating other architectures

This is the categorical difference. QEMU's TCG (Tiny Code Generator) translates a different CPU architecture's instructions into the host's in software, which is how it boots an x86-64 OS on an Apple silicon Mac, at emulation speed with no hardware help. Virtualization.framework has no such mode. It only runs same-architecture guests, accelerated, by design. If you need to boot an OS built for a CPU your Mac doesn't have, QEMU is the only one of the two that can. Can you install x86 Linux on an Apple Silicon Mac? covers the practical side, including why you often don't need to.

A nice piece of trivia in the other direction: QEMU has a vmapple machine type that implements the device model Virtualization.framework gives macOS guests, without using Apple's framework code. Two independent implementations arriving at the same device model suggests Apple's design isn't arbitrary.

Devices: curated or exhaustive

Virtualization.framework's device list is deliberately short: the virtio set in the device inventory post (block storage, network, sockets, console, entropy, memory balloon) plus Mac-specific graphics and shared-folder devices. QEMU's catalog is enormous, with dozens of emulated legacy devices and many machine types, built up over two decades of supporting real historical hardware. That breadth lets QEMU run systems Virtualization.framework was never meant to, but it's also more to configure correctly, and more of it is software emulation rather than paravirtualization.

Guest operating systems

Virtualization.framework officially supports two guest families: Linux, on Apple silicon and Intel Macs, and macOS, on Apple silicon only (see the fundamentals). QEMU's list is far longer: the BSDs, a long tail of Linux distributions, and older or niche systems. If the guest you need isn't Linux or macOS, Virtualization.framework isn't an option, whatever else is true.

The entitlement most comparisons skip

A practical difference with nothing to do with speed: an app that uses Virtualization.framework needs the com.apple.security.virtualization entitlement, which Velo Workspaces' entitlements file carries alongside its sandbox and file-access entitlements. QEMU has no such gate. It's open source, builds and runs without any Apple approval, and behaves the same whether or not it goes near the App Store. For a native, sandboxed Mac app that entitlement is part of the cost of entry; for a cross-platform open-source tool it doesn't come up.

Where performance differences come from

Since both can use the same acceleration, real differences between a Virtualization.framework VM and an HVF-accelerated QEMU VM mostly come from the I/O layer on top: which virtio devices are used, how disk caching and synchronization are set (the caching trade-off in the device inventory post is an example), and how much of the device model is paravirtualized versus emulated. A well-configured VM on either, for a same-architecture guest, should land in the same range. A QEMU guest under TCG emulation of a foreign architecture is a different, much slower game by design.

Building with each

Virtualization.framework is a native Swift and Objective-C API that fits Apple's code signing, sandboxing and notarization. The trade-offs are the restricted entitlement and being limited to what Apple exposes. QEMU is a large C codebase with its own build system and configuration surface, runs on Linux and Windows as well as macOS, and has two decades of community tooling and documentation behind it. The trade-off is that none of it is native to Apple's ecosystem, and configuring it well takes more specialist knowledge.

Which to reach for

Virtualization.framework fits when the job is running Linux or macOS guests inside a sandboxed Mac app with Apple silicon acceleration, which is exactly what Velo Workspaces does. QEMU, often through UTM (which can use either backend), fits when you need broader guest or architecture support: cross-architecture emulation, an OS outside Linux and macOS, or one tool that behaves the same on macOS, Linux and Windows. Different requirements, not a ranking.