Mac.apk: Android apps as native macOS processes, and what it still cannot do

An Android runtime built directly on macOS, with no Linux under it

Mac.apk is described as running Android apps natively on Apple Silicon, and the README is emphatic about what that excludes: no emulator, no virtual machine, no Linux underneath. Nothing boots Android in the background, there is no Linux kernel running, and nothing is interpreted instruction by instruction. Instead the project implements the Android application environment on top of macOS directly, and a wiki page explains how it works.

The visible result is that apps behave like Mac applications. They launch as ordinary macOS processes, draw through the Mac's GPU, and execute on the CPU at native speed. They appear in the Dock, get their own windows with a back button next to the traffic lights, resize and rotate like any Mac window, and follow the light and dark appearance of the system. Android TV apps work from the keyboard, and game launchers can start the other apps you have installed.

The audience is narrow and specific: somebody on an Apple Silicon Mac who wants a few Android apps to run, and who would rather not keep an emulator image around. It is not aimed at the general Android compatibility problem, and the primary language of the repository being Java is a hint about how much of the Android side is reimplemented in the open.

The project is explicit about its maturity. The README calls it alpha, early software under active development, where some apps run beautifully, some run partially and some do not run yet, and says it is stable enough to use and interesting enough to explore.

Four steps from download to a running app, and a slow first launch

The quick start in the README is four steps. First, download the disk image from the Releases page and drag Mac.apk into Applications, which works normally because the app is signed and notarized by Apple. Second, open Mac.apk and click Install next to Runtime in the top left. Third, open Settings using the gear, find File types, click Make Default and approve the macOS prompt. Fourth, double-click an .apk file, or one of the other package formats, or drag it onto the Mac.apk window:

.apk
.apkm
.xapk
.apks
.apkx

The third step is the one that catches people out. Until you have declared the file types as handled by Mac.apk, the system has no idea what to do with a package you double-click, so the association has to be made explicitly through the Settings pane and the macOS prompt that follows.

The cost of the first launch is stated plainly: the first launch of any app is slow, up to a minute for a large one, while Mac.apk prepares it, and later launches are fast. That preparation step is per app, so installing several apps means paying that wait several times, and it is the most likely first impression of a slow system.

The disk image itself is around 280 MB, and each installed app takes roughly one and a half to three times the size of its APK, which is the practical cost of holding an Android runtime alongside the app.

App data outlives the app bundle, and logs live in one folder

The file layout of an installed app is unusual enough to be worth knowing before you start removing things. The README states that each app's data lives in a directory under Application Support, named after the app's package:

~/Library/Application Support/MacApk/<package>
~/Library/Logs/macapk/

The consequence is stated as a note: dragging an app to the Trash leaves that data behind, while Uninstall in the Mac.apk window cleans it up and can keep your saves for a reinstall. So the normal macOS reflex of emptying the Trash does not remove the app's files, and the difference between the two removal paths is not cosmetic. One leaves a directory of app data in your user account, the other is designed to clean it and to preserve saves if you intend to reinstall the same app.

The second path, the logs directory, matters when something goes wrong. The README asks people reporting problems to send the Mac.apk version, the macOS version, the app and where they got it, what happened, and the app's log from that folder, either by email to the address in the repository or by opening an issue. It also says to look the log over before posting it publicly, which is a sensible warning: a log from a running app may contain more about your machine than you intend to share.

The wiki has dedicated pages for files and privacy, for managing apps, and for reporting problems, so the details of both paths are documented outside the README.

The compatibility list is the real specification

Instead of a feature list, the README points at a compatibility list as the answer to which apps work, and the badges in the repository show the current tally: 71 apps tested, 58 fully playable, 10 partly working and 3 not yet.

Those numbers are more informative than they look, because they are measured per app by hand. A compatibility layer that reports 58 of 71 fully playable is not a general Android environment, it is a long list of specific successes. The 10 that partly work are the interesting category, because partial usually means the interface appears and some features do nothing, which is the kind of behaviour that only shows up after a few minutes of use. The 3 that do not run yet are the honest floor.

The wiki table of contents shows how much of the day-to-day experience lives outside the README: a page on installing apps, pages on app stores and how apps are installed, pages on controls and input, on windows and appearance, on files and privacy, and on Google accounts and Play Services, plus flags, a flags reference, a developer menu, known issues, troubleshooting and a reporting problems guide. There is also a page for developers and publishers, which says the project serves no ads and supports no in-app purchases by design, and that a publisher who would rather their app not run on Mac.apk can ask for that by email.

For a user picking apps, the right workflow is to check the compatibility list first and the known issues page for the exact build second.

macOS 26.4 and Apple Silicon are hard floors, not preferences

The system requirements are stated as a table with no flexibility. macOS 26.4 (Tahoe) or newer is required, and macOS 27 works from v1.0.1702, so the newer system needed a build from late in the release line. Any Apple Silicon Mac is supported, including MacBook Neo, and Intel Macs are not supported at all.

That last line is the one that decides the audience. A compatibility layer that only runs on Apple Silicon cannot help anyone on an Intel Mac, and it rules out virtualised Intel environments as well, since the requirement is about the processor rather than the operating system.

The storage numbers follow from the design. Around 280 MB for Mac.apk itself, and each installed app takes roughly one and a half to three times the size of its APK, so a device with a handful of apps is looking at a gigabyte or so of additional storage. On a laptop with limited space that is a real constraint, and it is the kind of number that is easier to accept before installing than afterwards.

The release history shows how active the work is. v1.0.1732 was published on 2026-10-06, v1.0.2237 on 2026-10-19 and v1.0.2279 on 2026-10-20, and the last push was on 2026-10-20 as well. The known issues are tracked per release, which is the right way to do it when builds ship daily, and it also means the issues list you read has to match the build you installed.

The source tree contains the runtime, the loader and the shim

Everything that makes the project work is in the repository, and the README names the pieces: the Android framework reimplementation, the native runtime, the arm64 loader and Bionic shim, the ARM32 recompiler, and the macOS app. BUILDING.md explains how to build it and CONTRIBUTING.md how to send a fix, and the README asks for app reports as well as code.

The directory layout supports that description. There is a runtime/ directory for the runtime side, a launcher/ directory for the macOS application, a scripts/ directory for the build automation, a signatures/ directory, a thirdparty/ directory alongside a THIRD_PARTY_NOTICES.txt file, and a debug/ directory. There is also a VERSION file, a SECURITY.md for responsible disclosure, a CLA.md for contribution terms, COMMERCIAL.md for the alternative licence, and TRADEMARKS.md.

The Bionic shim and the ARM32 recompiler are the two names that tell you the hardest part of the work. Android apps expect Bionic, the libc of the Android world, and an ARM32 instruction set for older native libraries, so getting an APK to run on a macOS process means providing those pieces rather than emulating a whole machine.

The licence is the GNU AGPL v3.0, and the README states that a commercial license is available for companies, with the details in COMMERCIAL.md. AGPL has a reciprocal requirement that matters in practice for a project like this, since the terms reach beyond the binary to the network use of modified versions, so a company evaluating it should read COMMERCIAL.md and the licence text before shipping it internally. That is a question for your own legal review rather than for this article.

Editorial conclusion

Adopt Mac.apk if you want to run a handful of Android apps on an Apple Silicon Mac without installing an emulator, and if the apps you care about appear as fully playable in COMPATIBILITY.md. Do not adopt it as a general Android compatibility layer, because the project's own list records 71 apps tested by hand with 58 fully playable, and it requires macOS 26.4 or newer with no Intel support. Before you rely on it, read the known issues page for the exact build you install, since releases move daily and the version you download may differ from the one documented, and check the data location for each app, because uninstalling from the Trash leaves the app's files behind in the Application Support directory.

Frequently asked questions

Official sources

1. kksimp/Mac.apk on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases