Why we build a separate engine for every OS

Most Android emulators on desktop are built once, on one stack, and then carried over to every platform through a shared compatibility layer. That's a reasonable engineering decision: one codebase is cheaper to maintain than three. It's just not the fastest way to run Android on someone else's operating system.

Emulade takes the more expensive path. We build and ship a distinct native engine for each platform:

• Windows talks to Windows Hypervisor Platform (WHPX), the same primitive Hyper-V is built on.
• macOS talks to Apple's Virtualization.framework directly, hardware-accelerated on both Apple Silicon and Intel.
• Linux talks to KVM through QEMU, the same stack running most of the cloud.

What this actually buys you

A shared translation layer has to speak a lowest-common-denominator API, then adapt that down to whatever the host OS actually offers. Every one of those adaptation steps is a place where a frame can wait, an input event can queue, or a memory page can get copied that didn't need to be.

Talking to the native hypervisor directly means Android's guest instructions reach your CPU's virtualization extensions (VT-x, AMD-V, or Apple Silicon's own hypervisor support) with nothing standing in between them and your OS. That's the whole point of the architecture. It's not a marketing angle: it's the reason the frame rate work is possible at all.

What it costs

Maintaining three engines means three sets of platform-specific bugs, three release pipelines, and three teams that need to understand hypervisor internals instead of one. When Apple changes something in Virtualization.framework, that's our problem to absorb, not something a shared layer quietly papers over.

We think that trade is worth it. If you want to know exactly what's running underneath your install, the engine breakdown on the homepage shows the real stack for each OS.