By ByteBot
Mac.apk v1.0.2279 shipped today, October 20, 2026, and it does something that every previous “Android on Mac” solution has avoided: it runs unmodified Android APKs as native macOS processes on Apple Silicon — no virtual machine, no Linux kernel, and no emulation layer underneath. The project is in public alpha, open source under AGPL-3.0, and 82% of tested apps already work out of the box.
Not an Emulator — That Is the Point
Every prior attempt at running Android apps on macOS — BlueStacks, Genymotion, Google’s Play Games beta — worked by spinning up a full Android virtual machine. Mac.apk does not. Instead, it converts Android’s Dalvik bytecode (.dex files) into standard JVM bytecode using a companion tool called dex2jvm, then executes the result natively on Apple Silicon’s HotSpot JVM. The Android application environment is reimplemented directly on top of macOS, so apps launch as ordinary macOS processes, render through the Mac’s native GPU pipeline, and run on the CPU at full speed.
That conversion step is what makes the project technically interesting. Dalvik bytecode and JVM bytecode are similar but not compatible — different calling conventions, different method size limits, different handling of some instruction types. The dex2jvm converter handles the translation in about 22 seconds on average, compared to 340 seconds for enjarify — 15 times faster — and rejected only one class across ten test apps, where enjarify rejected nearly ten thousand.
What Works and What Does Not
Of 71 apps tested so far, 58 run fully and 10 run partially. Apps appear as standard macOS applications: Dock icons, resizable windows, Cmd+Tab support, GPU-accelerated rendering. The Mac.apk GitHub repository maintains a growing compatibility list updated with every build.
The limitations are real and worth knowing before you get excited. Google Play Billing will not work — in-app purchases require Play Integrity attestation that Mac.apk cannot satisfy. Ad networks are blocked for the same reason. Apps that require SafetyNet or Play Integrity to launch — including many banking and streaming apps — simply will not run. The project also does not yet support CompactDex (.cdex) files or Android App Bundles (.aab), which cuts out some modern app packaging formats.
The Sandbox Trade-off
The security concern developers are raising is the absence of a sandbox. On Android, every app runs in an isolated process with restricted file access. On Mac.apk, however, an Android app runs with the same permissions as your macOS user account. That is fine for a trusted app you already use on your phone, but it is a meaningful risk if you are installing APKs from untrusted sources. Treat it like any other unsigned binary you run on your machine — with appropriate caution.
Requirements, Access, and the Bigger Picture
Mac.apk requires Apple Silicon (M1 or newer) and macOS 26.4 (Tahoe) minimum — Intel Macs are not supported. The runtime takes about 280 MB; each installed app needs roughly 1.5 to 3 times its APK size. First launch is slow — up to a minute for larger apps while JIT compilation runs — but subsequent launches are fast. The Mac.apk project page has signed and notarized builds for download.
The project is licensed under AGPL-3.0, meaning any product you ship that builds on it must open-source its changes under the same terms. Voltare offers a commercial license for companies that want to bundle or distribute without those requirements — which signals that this is being built as infrastructure, not just a personal experiment. For cross-platform developers, the implication is straightforward: if Mac.apk matures, Android developers could reach Mac users without any code changes, without App Store review, and without Catalyst or Flutter. Whether Apple responds with policy or technical countermeasures is the open question. The project is trending on Hacker News today with 296 upvotes, and the builds are shipping daily. For now, 82% of tested apps run — a high bar for something this new.
