Deep dive

Virtualization.framework vs. QEMU on Apple Silicon

Not a verdict — an engineering comparison of two genuinely different tools that happen to overlap on "run a VM on an Apple Silicon Mac." One is a purpose-built API with a curated device set; the other is a general-purpose machine emulator old enough to predate Apple Silicon by over a decade, with a hardware-accelerated backend bolted on for this platform specifically. Where they actually differ matters more than which one is "better."

Two different starting points

Virtualization.framework was built from the start as a native macOS API for one job: run Linux or macOS as a guest, on Apple Silicon or Intel Macs, using the host CPU's virtualization extensions directly. QEMU is a general-purpose machine emulator and virtualizer that predates Apple Silicon entirely — it emulates dozens of CPU architectures and hundreds of hardware configurations, and its Apple Silicon story is a hardware-accelerated backend added to that much older, much broader project. Neither fact makes one better; it explains almost every difference below.

Hardware acceleration: the same silicon, underneath both

This is the part that surprises people expecting a bigger gap: on Apple Silicon, QEMU doesn't run guests in pure software emulation by default. Its -accel hvf flag engages Apple's own Hypervisor framework — the exact same low-level API that gives Virtualization.framework access to ARM's EL2 virtualization extensions, covered in the ARM performance deep dive. For a same-architecture guest (ARM64 Linux on an ARM64 host) with HVF engaged, both tools are ultimately asking the same CPU hardware to do the same job. Neither is "faster" at the CPU-trap, memory-translation, or interrupt-delivery layer, because neither one implements that layer itself — Apple's silicon and Apple's Hypervisor framework do.

Where they actually diverge: emulation reach

This is the real architectural difference, and it's categorical, not a matter of degree. QEMU's TCG (Tiny Code Generator) can translate an entire different CPU architecture's instructions into the host's, in software, guest instruction by guest instruction — which is how QEMU can boot an x86_64 or even a completely unrelated architecture's OS on an Apple Silicon host, with no hardware acceleration possible for that guest, at emulation speed rather than native speed. Virtualization.framework has no equivalent mode at all: it only ever runs a same-architecture guest, accelerated, full stop. If what you actually need is "boot an OS built for a CPU this Mac doesn't have," QEMU is the only one of the two that can do it; Virtualization.framework categorically cannot, by design, not as a current limitation.

There's a neat piece of trivia in the other direction, too: QEMU ships its own vmapple machine type, which implements the same device model Virtualization.framework exposes to a macOS guest — without using any of Apple's own framework code. Two independent implementations converging on the same device model is a reasonable signal that Apple's design here isn't arbitrary.

Device model: curated vs. exhaustive

Virtualization.framework's device list is deliberately small — the VIRTIO set covered in the device inventory post: block storage, network, socket, serial, entropy, memory balloon, plus Mac-specific graphics and shared-folder devices. QEMU's device catalog is enormous by comparison — dozens of emulated legacy devices, many distinct machine types, because it has spent over two decades accumulating support for real historical hardware, not just what a modern paravirtualized guest needs. That breadth is exactly what lets QEMU run operating systems Virtualization.framework was never built to support — but it's also more surface area to configure correctly, and more of it is pure software emulation rather than hardware-accelerated paravirtualization.

Guest OS support

Virtualization.framework officially supports two guest families: Linux (Apple Silicon and Intel Macs) and macOS (Apple Silicon Macs only, booting official IPSW restore images) — covered in the fundamentals post. QEMU's supported-guest list is far longer: Windows, the BSDs, a long tail of Linux distributions, and older or niche operating systems that have no place in Virtualization.framework's curated model at all. If the guest OS you need isn't Linux or macOS, Virtualization.framework isn't in the running regardless of any other tradeoff here.

The entitlement gate most comparisons skip

This is a real, practical difference that has nothing to do with performance. Using Virtualization.framework at all requires the com.apple.security.virtualization entitlement — verified directly in Velo Workspaces' own entitlements file, where it's flagged  right above the sandbox and file-access entitlements. Apple restricts this entitlement to developers building virtualization software specifically, granted case by case rather than automatically. QEMU has no equivalent gate: it's open-source, builds and runs without any Apple approval, and the same binary behaves identically whether or not it's ever going near the App Store. For a team building a native, sandboxed Mac app, that gate is a real cost of entry; for a cross-platform open-source tool that was never going through App Review, it's simply not a consideration.

Where performance differences actually come from

Given both tools can ride the same hardware acceleration, the meaningful performance differences between a Virtualization.framework VM and an HVF-accelerated QEMU VM mostly aren't about which framework you picked — they're about I/O device implementation choices layered on top: which VIRTIO devices are used, how storage caching and synchronization modes are configured (the caching-mode tradeoff in the device inventory post is a concrete example), and how much of the device model is paravirtualized versus emulated in software for a given guest configuration. A carefully configured VM on either platform, for a same-architecture guest, should land in the same neighborhood; a QEMU guest running under TCG emulation for a foreign architecture is playing an entirely different, much slower game by design.

Developer and user experience

Virtualization.framework is a native Swift/Objective-C API, integrated into Apple's code-signing, sandboxing, and notarization pipeline as a first-class citizen — the tradeoff is the restricted entitlement above, plus being locked to what Apple's curated API actually exposes. QEMU is a large C codebase with its own build system and configuration surface, genuinely cross-platform (the same project runs on Linux and Windows, not just macOS), with a correspondingly larger community of tooling and documentation built up over two decades — the tradeoff is that none of it is native to the Apple ecosystem, and configuring it well takes more specialized knowledge than a curated, typed Swift API does.

Which one to reach for

Virtualization.framework makes sense when the job is specifically "run Linux or macOS as a guest, natively integrated into a sandboxed Mac app, with Apple Silicon-accelerated performance" — which is the exact shape of what Velo Workspaces does. QEMU (often fronted by UTM, which can use either QEMU or Virtualization.framework as a backend) makes sense when the actual requirement is broader guest OS or architecture support than Virtualization.framework offers — genuine cross-architecture emulation, an OS outside the Linux/macOS pair, or wanting one tool that behaves the same on macOS, Linux, and Windows. Different requirements, not a strictly-better-or-worse ranking.