Mac.apk is not an emulator. It does not boot a virtual machine, run a Linux kernel, or interpret instructions. Instead, it reimplements the Android application framework directly on top of macOS, so that Android apps launch as ordinary macOS processes, draw through the Mac's GPU, and execute on the CPU at native speed. Apps appear in the Dock, get resizable windows with macOS traffic-light controls, and follow the system's light/dark mode. The project is the work of Kaleb Keithley, operating under the name Voltare, and is released as open source under the GNU AGPL v3.0 with a separate commercial license available. The technical approach is closer to Wine (the Windows compatibility layer for Linux) than to any Android emulator. Mac.apk includes an arm64 loader, a Bionic shim (Android's C library replacement), an ARM32 recompiler for older 32-bit apps, and a full reimplementation of the Android framework — the Java-level APIs that apps actually call. It bundles ANGLE for OpenGL-to-Metal translation, MoltenVK for Vulkan support, an OpenJDK-based JRE, and AOSP platform resources. Every component ships with its own license and source availability, including LGPL-compliant source for GLib and libintl attached to each release. The project requires macOS 26.4 (Tahoe) or newer and any Apple Silicon Mac, including the MacBook Neo. Intel Macs are unsupported. The runtime takes approximately 280 MB of disk, with each installed app consuming roughly 1.5 to 3 times its APK size. First launches can take up to a minute for large apps while Mac.apk prepares them; subsequent launches are fast. There is a critical security caveat that deserves emphasis: Android apps running under Mac.apk execute as native code with the full permissions of the user's macOS account. There is no phone-style sandbox. An APK can read and write any file the user can access. The project explicitly warns users to treat APKs exactly as they would any program downloaded and run on a Mac — a meaningful departure from the sandboxed model mobile users expect. The project is in alpha. A hand-tested compatibility list tracks which apps work, which run partially, and which fail. Mac.apk serves no ads and supports no in-app purchases by design, which means the Android app economy's revenue model is deliberately excluded. Publishers can contact the developer about partnerships or to request their apps not run on the platform. This is a direct confrontation with the walled-garden model on both sides — Apple's control of what runs on Macs, and Google's control of how Android apps monetize. The generative potential here is significant. If Mac.apk matures, it breaks the assumption that Android apps require Android hardware or an Android OS. It gives developers a new distribution surface they did not build for, gives Mac users access to a library of millions of apps, and does so without requiring Google's blessing or Apple's App Store. The fact that it is open source means the approach can be studied, forked, and extended by anyone. The fragility is equally real. A solo-developer project reimplementing an entire application framework is an enormous maintenance surface. Android evolves rapidly, and every new API, every new permission model, every new GPU feature requires corresponding work in Mac.apk. The lack of app sandboxing is a structural security gap that will matter the moment any user installs a malicious APK. And the legal exposure — running third-party apps outside their intended platform with no in-app purchase support — is the kind of thing that attracts cease-and-desist letters.
