How to Run Android Apps on a Mac Without an Emulator (58 of 71 Apps Work)
Search "how to run Android apps on Mac" and for years you got the same answer: install an emulator, give it a big chunk of your RAM, and wait while a whole phone OS boots inside your laptop. Mac.apk says you can skip that part. You double-click an .apk and it opens as a normal macOS app with a Dock icon, no Android underneath.
Short version: it works for 58 of the 71 apps its author tested, it needs macOS 26.4 on Apple Silicon, and anything that checks Play Integrity won't run, with banking apps the first example HN commenters reached for. For those, an emulator that boots a full Android, like BlueStacks Air or the Android Studio one, is still the better bet.
It hit Hacker News at 319 points and 173 comments, and a good chunk of the thread argued over whether "native" is even the right word. I went through what it runs, where it breaks and how to install it, then lined it up against the Android Studio emulator, BlueStacks Air and Waydroid. I haven't benchmarked anything; every number comes from the linked repo, docs and user reports.
How Mac.apk runs Android apps on a Mac without an emulator
The architecture page is pretty clear about the approach:
- DEX bytecode gets converted to standard Java bytecode on first launch (the converter is called dex2jvm), cached, then run on a bundled JRE built from OpenJDK.
- The Android framework is Mac.apk's own reimplementation, written to match AOSP. Windows, audio, location and controllers map to macOS APIs.
- arm64 native libraries run as-is. Apple Silicon is 64-bit ARM, so there's nothing to translate. Android's C library and the other system libraries are Mac.apk's own, built on top of macOS's libraries. The wiki says "there's no Linux kernel anywhere."
- ARM32 libraries get recompiled to arm64 once, ahead of time, and cached. If an APK ships both, the 64-bit code wins.
- Graphics go through ANGLE for OpenGL ES and MoltenVK for Vulkan, both ending up on Metal.
So "no emulator" holds up. "No virtual machine" is where HN pushed back, and they had a point. There's a JVM in there, and a commenter noted the README's own diagram shows a "built-in Java runtime." I'd call it a Wine-style compatibility layer, which is what the wiki calls it too. I think the label matters less than the thread did: nothing boots, and apps show up as ordinary macOS processes.
Requirements and install: the macOS version is the catch
From the README:
- macOS 26.4 (Tahoe) or newer. macOS 27 works from v1.0.1702.
- Apple Silicon only. Intel Macs are not supported.
- Disk: about 280 MB for Mac.apk itself, plus roughly 1.5 to 3 times each app's APK size.
- License: AGPL-3.0, with a commercial license available. The official app is free.
That macOS floor rules out plenty of Macs BlueStacks Air still supports. Check yours first:
sw_vers -productVersion # needs 26.4 or higher
uname -m # needs arm64
Then check which native code the APK you care about ships:
unzip -l some-app.apk | awk '{print $4}' | grep '^lib/' | cut -d/ -f2 | sort -u
If you see arm64-v8a, you're in the best case. armeabi-v7a goes through the recompiler. If all you see is x86 or x86_64, keep your expectations low: the docs only describe ARM paths and don't mention x86 at all. If nothing prints, the app is pure Java/Kotlin and only goes through the DEX conversion.
Install is four steps, per the README:
1. Download the disk image from the Releases page and move Mac.apk into Applications.
2. Open it and click Install next to "Runtime:" in the top left.
3. In Settings, under File types, click "Make Default" and approve the macOS prompt.
4. Double-click an APK, or drag it onto the Mac.apk window.
By the numbers: 58 of 71 tested apps fully work
The compatibility list has 71 hand-tested apps: 58 fully playable, 10 partly working, 3 not yet.
Working, among others: Minecraft, Candy Crush Saga, Subway Surfers, Asphalt Legends, Rocket League Sideswipe, Plague Inc., Telegram, Signal, VLC, Organic Maps, RetroArch, F-Droid, Aurora Store, and the Epic Games Store. Read the fine print, though: for Asphalt, Telegram, Signal, VLC and several others the sound column says "not tested". The table also has 84 rows for those 71 apps, because each tested version gets its own row; Hill Climb Racing 1.71.1, for one, crashed at startup while the versions around it work.
The partly working group tells you more about where the layer is still thin:
- Duolingo: can't create an account or log in.
- Reddit: Google login fails and scrolling is odd.
- Instagram: layout problems, choppy video, broken sound.
- Thunderbird: Google sign-in works, but the Thunderbird login itself fails.
- NewPipe: some videos play audio only and buffer constantly.
Others in that bucket: Mastodon only shows one post, Aegis can't use the camera, and Geometry Dash Meltdown breaks after its full-screen ads.
Not working: Efteling (stuck on the welcome screen), Jetpack 2 (stuck at 59%), and Gallery (file permissions).
The list skews toward offline games and open-source apps, which is a flattering sample. Banking apps aren't on it, and the Play Services page explains why.
Google Play Services: what works and what never will
The Play Services wiki page is more honest than most READMEs. Mac.apk ships its own implementation of "the parts most apps use" and says outright: "Mac.apk isn't a Google-certified Android device and doesn't claim to be."
| Feature | Status |
|---|---|
| Google sign-in via the Mac.apk account | Works |
| Play licence checks | Works, using your account |
| Push notifications | Partly: apps get real tokens, end-to-end delivery not verified |
| Play Billing | Doesn't work, no purchases |
| Play Integrity | Doesn't work, no hardware-attested verdict |
| Apps requiring Google-signed Play Services | Don't work |
The no-Play-Integrity row decides it for a lot of people. In the HN thread, people named banking apps and games with SafetyNet-style checks as the obvious failures. Another named apps as ordinary as train schedules. One commenter auditing baby-tracking apps said that in "about 10% or so of cases" an app was close to impossible to emulate without a Google Play account verified against Google's servers. Nobody can patch that, because Play Integrity exists to detect exactly this kind of environment.
Mac.apk vs Android Studio emulator vs BlueStacks Air vs Waydroid
| | Mac.apk | Android Studio emulator | BlueStacks Air | Waydroid |
|---|---|---|---|---|
| Approach | Compatibility layer, no Android boot | Full Android VM | Emulator | Android container on Linux |
| macOS | 26.4+ | 12+ | 11+ | No macOS host, needs Linux |
| Chip | Apple Silicon | Not specified in the docs | Apple Silicon (M1 to M4) | n/a on macOS |
| RAM | Not specified | 16 GB recommended | 8 GB min, 16 GB recommended | Not specified |
| Disk | ~280 MB + 1.5 to 3x APK | 16 GB recommended | 12 GB | Not specified |
| Play / app store | Own partial Play Services, no Integrity/Billing | Google Play system images available | BlueStacks Store | LineageOS-based image |
| Setup | Drag to Applications, install runtime | IDE + SDK + system image | Installer | Linux host + install |
Sources: Android emulator docs, BlueStacks Air specs (also on Wikipedia), Waydroid docs.
My read:
- If you build Android apps, stay on the Android Studio emulator. You want a real Android build with real Play Services, and Mac.apk is a reimplementation by design.
- If you just want to play games, BlueStacks Air is still the safe default for compatibility, and it runs on Macs back to Big Sur. The trade-off is in the HN thread: one user asked whether it's "full of chinese ads nowadays", and another agreed the ads are a problem but said "there really isn't anything out there as reliable as it." Mac.apk says it serves no ads.
- Waydroid is a good Linux tool, but on a Mac it means running a Linux VM first, which is the overhead you were trying to get away from. (It runs an Android 13 image based on LineageOS, per its docs.)
- Mac.apk is best for the single app with no desktop version that you're tired of reaching for your phone to use, as long as you're on Tahoe and the app doesn't call Play Integrity.
Before you double-click a random APK
This is the part of the README I'd underline: apps run with your user account's permissions, without a phone-style sandbox. An APK that would be locked inside its sandbox on a Pixel can read your home directory here. Only install APKs from places you trust (F-Droid, the developer's own releases, Aurora Store), not from a mirror site you found on page four of search results.
- The first launch of a large app can take up to a minute while the DEX conversion runs. Later launches use the cache.
- App data used to live inside each app's .app bundle, so trashing the app took your saves with it, and HN complained. Per the current README it lives in ~/Library/Application Support/MacApk/<package>, and Uninstall in the Mac.apk window can keep your saves for a reinstall. Back that folder up if you care about game progress.
- It's alpha. One HN commenter called it "obviously vibe-coded and therefore unlikely to be stable", and a short sub-thread argued about Claude being listed as a contributor. Fair to watch, but 58 of 71 tested apps working is still a real result.
My take: for the "can I run this one Android app on my Mac" crowd, Mac.apk is the most interesting answer in years. It won't replace the emulator for development or BlueStacks for Play-dependent games while Play Integrity exists. For an open-source app or an offline game, it's the lightest option I know of. Someone on HN wanted it for the app of a cheap Chinese cat feeder that asks for a suspicious number of permissions, and another commenter replied that this is exactly the kind of app you should keep in an emulator. I agree: no sandbox means sketchy apps belong in a VM.
Which Android app would you actually want running on your Mac, and why does it still not have a desktop version? And if you've tried Mac.apk on something that isn't on the compatibility list, tell me whether it worked.
Sources
- kksimp/Mac.apk on GitHub
- Mac.apk COMPATIBILITY.md
- Wiki: How Mac.apk Works
- Wiki: Google Accounts and Play Services
- Hacker News discussion
- Android Emulator docs
- BlueStacks Air system specifications
- BlueStacks on Wikipedia
- Waydroid docs
Mentions
Mac.apk: Run Android apps natively on Apple Silicon Macs (3.6k stars) What it does All text below is quoted directly from the project README. >Mac.apk: Run Android apps natively on Apple Silicon Macs What it is: - Mac.apk runs Android apps directly on Apple Silicon. - Apps launch as ordinary macOS processes, draw through the Mac's GPU, and execute on the CPU at native speed. - Android TV apps work from the keyboard, and game launchers can start your other installed apps. - There is no emulator here, and no virtual machine. - Nothing boots Android in the background, there is no Linux kernel running underneath, and nothing is interpreted instruction-by-instruction. - Mac.apk implements the Android application environment on top of macOS directly. >Double-click any .apk (or .apkm, .xapk, .apks, .apkx), or drag it onto the Mac.apk window. Repository kksimp/Mac.apk Repository stats |Metric|Value| |:-|:-| |Stars|3,551| |Forks|129| |Last release|v1.0.2303 (2026-10-21)| |Languages|Java 69.4%, C++ 22.5%, Objective-C++ 3.7%| |Contributors|7| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (28 commits)| |AI co-authored commits|Claude: 28| Main contributor |Field|Value| |:-|:-| |Name|Kaleb Simpson| |GitHub|@kksimp| |Commits to this repo|66 (top contributor)| |Bio|AI-augmented systems problem solver. I build iOS, macOS, and web| |Company / Location|Voltare / South Carolina| |Followers|26| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
2EzKeRpRvJGx6hC2s2B87fNcx7DWghLscdvXw4jjpump 3.4k stars on github claimed github.com/kksimp t.co
New Claim Report: github.com/kksimp just claimed 0.8 SOL for $MACAPK on @Pumpfun pump.fun
想在自己的Mac电脑上跑安卓APP，但又不想下载虚拟机，可以试试这个项目。 Mac.apk 实现了在 Apple Silicon 上直接秒开安卓应用。 GitHub：kksimp/Mac.apk
エミュレータもVMも使わずMacでAndroidアプリを動かす。Androidフレームワーク再実装とarm64ローダー、ARM32リコンパイラでmacOSプロセスとして実行し、検証65本中51本が完全動作。互換レイヤー方式の実例 / Mac.apk: Run Android apps natively on Apple Silicon Macs kksimp/Mac.apk
How to Run Android Apps on a Mac Without an Emulator (58 of 71 Apps Work) Search "how to run Android apps on Mac" and for years you got the same answer: install an emulator, give it a big chunk of your RAM, and wait while a whole phone OS boots inside your laptop. Mac.apk says you can skip that part. You double-click an .apk and it opens as a normal macOS app with a Dock icon, no Android underneath. Short version: it works for 58 of the 71 apps its author tested, it needs macOS 26.4 on Apple Silicon, and anything that checks Play Integrity won't run, with banking apps the first example HN commenters reached for. For those, an emulator that boots a full Android, like BlueStacks Air or the Android Studio one, is still the better bet. It hit Hacker News at 319 points and 173 comments, and a good chunk of the thread argued over whether "native" is even the right word. I went through what it runs, where it breaks and how to install it, then lined it up against the Android Studio emulator, BlueStacks Air and Waydroid. I haven't benchmarked anything; every number comes from the linked repo, docs and user reports. How Mac.apk runs Android apps on a Mac without an emulator The architecture page is pretty clear about the approach: - DEX bytecode gets converted to standard Java bytecode on first launch (the converter is called dex2jvm), cached, then run on a bundled JRE built from OpenJDK. - The Android framework is Mac.apk's own reimplementation, written to match AOSP. Windows, audio, location and controllers map to macOS APIs. - arm64 native libraries run as-is. Apple Silicon is 64-bit ARM, so there's nothing to translate. Android's C library and the other system libraries are Mac.apk's own, built on top of macOS's libraries. The wiki says "there's no Linux kernel anywhere." - ARM32 libraries get recompiled to arm64 once, ahead of time, and cached. If an APK ships both, the 64-bit code wins. - Graphics go through ANGLE for OpenGL ES and MoltenVK for Vulkan, both ending up on Metal. So "no emulator" holds up. "No virtual machine" is where HN pushed back, and they had a point. There's a JVM in there, and a commenter noted the README's own diagram shows a "built-in Java runtime." I'd call it a Wine-style compatibility layer, which is what the wiki calls it too. I think the label matters less than the thread did: nothing boots, and apps show up as ordinary macOS processes. Requirements and install: the macOS version is the catch From the README: - macOS 26.4 (Tahoe) or newer. macOS 27 works from v1.0.1702. - Apple Silicon only. Intel Macs are not supported. - Disk: about 280 MB for Mac.apk itself, plus roughly 1.5 to 3 times each app's APK size. - License: AGPL-3.0, with a commercial license available. The official app is free. That macOS floor rules out plenty of Macs BlueStacks Air still supports. Check yours first: sw_vers -productVersion # needs 26.4 or higher uname -m # needs arm64 Then check which native code the APK you care about ships: unzip -l some-app.apk | awk '{print $4}' | grep '^lib/' | cut -d/ -f2 | sort -u If you see arm64-v8a, you're in the best case. armeabi-v7a goes through the recompiler. If all you see is x86 or x86_64, keep your expectations low: the docs only describe ARM paths and don't mention x86 at all. If nothing prints, the app is pure Java/Kotlin and only goes through the DEX conversion. Install is four steps, per the README: 1. Download the disk image from the Releases page and move Mac.apk into Applications. 2. Open it and click Install next to "Runtime:" in the top left. 3. In Settings, under File types, click "Make Default" and approve the macOS prompt. 4. Double-click an APK, or drag it onto the Mac.apk window. By the numbers: 58 of 71 tested apps fully work The compatibility list has 71 hand-tested apps: 58 fully playable, 10 partly working, 3 not yet. Working, among others: Minecraft, Candy Crush Saga, Subway Surfers, Asphalt Legends, Rocket League Sideswipe, Plague Inc., Telegram, Signal, VLC, Organic Maps, RetroArch, F-Droid, Aurora Store, and the Epic Games Store. Read the fine print, though: for Asphalt, Telegram, Signal, VLC and several others the sound column says "not tested". The table also has 84 rows for those 71 apps, because each tested version gets its own row; Hill Climb Racing 1.71.1, for one, crashed at startup while the versions around it work. The partly working group tells you more about where the layer is still thin: - Duolingo: can't create an account or log in. - Reddit: Google login fails and scrolling is odd. - Instagram: layout problems, choppy video, broken sound. - Thunderbird: Google sign-in works, but the Thunderbird login itself fails. - NewPipe: some videos play audio only and buffer constantly. Others in that bucket: Mastodon only shows one post, Aegis can't use the camera, and Geometry Dash Meltdown breaks after its full-screen ads. Not working: Efteling (stuck on the welcome screen), Jetpack 2 (stuck at 59%), and Gallery (file permissions). The list skews toward offline games and open-source apps, which is a flattering sample. Banking apps aren't on it, and the Play Services page explains why. Google Play Services: what works and what never will The Play Services wiki page is more honest than most READMEs. Mac.apk ships its own implementation of "the parts most apps use" and says outright: "Mac.apk isn't a Google-certified Android device and doesn't claim to be." | Feature | Status | |---|---| | Google sign-in via the Mac.apk account | Works | | Play licence checks | Works, using your account | | Push notifications | Partly: apps get real tokens, end-to-end delivery not verified | | Play Billing | Doesn't work, no purchases | | Play Integrity | Doesn't work, no hardware-attested verdict | | Apps requiring Google-signed Play Services | Don't work | The no-Play-Integrity row decides it for a lot of people. In the HN thread, people named banking apps and games with SafetyNet-style checks as the obvious failures. Another named apps as ordinary as train schedules. One commenter auditing baby-tracking apps said that in "about 10% or so of cases" an app was close to impossible to emulate without a Google Play account verified against Google's servers. Nobody can patch that, because Play Integrity exists to detect exactly this kind of environment. Mac.apk vs Android Studio emulator vs BlueStacks Air vs Waydroid | | Mac.apk | Android Studio emulator | BlueStacks Air | Waydroid | |---|---|---|---|---| | Approach | Compatibility layer, no Android boot | Full Android VM | Emulator | Android container on Linux | | macOS | 26.4+ | 12+ | 11+ | No macOS host, needs Linux | | Chip | Apple Silicon | Not specified in the docs | Apple Silicon (M1 to M4) | n/a on macOS | | RAM | Not specified | 16 GB recommended | 8 GB min, 16 GB recommended | Not specified | | Disk | ~280 MB + 1.5 to 3x APK | 16 GB recommended | 12 GB | Not specified | | Play / app store | Own partial Play Services, no Integrity/Billing | Google Play system images available | BlueStacks Store | LineageOS-based image | | Setup | Drag to Applications, install runtime | IDE + SDK + system image | Installer | Linux host + install | Sources: Android emulator docs, BlueStacks Air specs (also on Wikipedia), Waydroid docs. My read: - If you build Android apps, stay on the Android Studio emulator. You want a real Android build with real Play Services, and Mac.apk is a reimplementation by design. - If you just want to play games, BlueStacks Air is still the safe default for compatibility, and it runs on Macs back to Big Sur. The trade-off is in the HN thread: one user asked whether it's "full of chinese ads nowadays", and another agreed the ads are a problem but said "there really isn't anything out there as reliable as it." Mac.apk says it serves no ads. - Waydroid is a good Linux tool, but on a Mac it means running a Linux VM first, which is the overhead you were trying to get away from. (It runs an Android 13 image based on LineageOS, per its docs.) - Mac.apk is best for the single app with no desktop version that you're tired of reaching for your phone to use, as long as you're on Tahoe and the app doesn't call Play Integrity. Before you double-click a random APK This is the part of the README I'd underline: apps run with your user account's permissions, without a phone-style sandbox. An APK that would be locked inside its sandbox on a Pixel can read your home directory here. Only install APKs from places you trust (F-Droid, the developer's own releases, Aurora Store), not from a mirror site you found on page four of search results. - The first launch of a large app can take up to a minute while the DEX conversion runs. Later launches use the cache. - App data used to live inside each app's .app bundle, so trashing the app took your saves with it, and HN complained. Per the current README it lives in ~/Library/Application Support/MacApk/<package>, and Uninstall in the Mac.apk window can keep your saves for a reinstall. Back that folder up if you care about game progress. - It's alpha. One HN commenter called it "obviously vibe-coded and therefore unlikely to be stable", and a short sub-thread argued about Claude being listed as a contributor. Fair to watch, but 58 of 71 tested apps working is still a real result. My take: for the "can I run this one Android app on my Mac" crowd, Mac.apk is the most interesting answer in years. It won't replace the emulator for development or BlueStacks for Play-dependent games while Play Integrity exists. For an open-source app or an offline game, it's the lightest option I know of. Someone on HN wanted it for the app of a cheap Chinese cat feeder that asks for a suspicious number of permissions, and another commenter replied that this is exactly the kind of app you should keep in an emulator. I agree: no sandbox means sketchy apps belong in a VM. Which Android app would you actually want running on your Mac, and why does it still not have a desktop version? And if you've tried Mac.apk on something that isn't on the compatibility list, tell me whether it worked. Sources - kksimp/Mac.apk on GitHub - Mac.apk COMPATIBILITY.md - Wiki: How Mac.apk Works - Wiki: Google Accounts and Play Services - Hacker News discussion - Android Emulator docs - BlueStacks Air system specifications - BlueStacks on Wikipedia - Waydroid docs
Run Android apps natively on Apple Silicon Macs (No VM or emulator) First: Don't shoot the messenger. If don't need or like it that's totally fine. Just wanted to share this awesome FOSS project called Mac.apk. It allows you to run Android apps (apks) natively on Apple Silicon Macs. So what? You can already do that with a VM, brah? Unlike traditional methods, there’s no heavy emulator, no VM running in the background, and no Linux kernel underneath. It acts as a compatibility layer directly on top of macOS (similar to Wine for Linux apps), translating code, mapping graphics straight to Metal and letting ARM64 native code fly at full speed. preview.redd.it And yes, there will also be bugs too. And not all apps will work, but anyone trying to bridge the 2 ecosystems, this might fit the bill. You can check out the project page and GitHub repo here: - Website: projects.voltare.us - GitHub: kksimp/Mac.apk - Mac.apk App Compatibility List (71 apps tested: ✅ 58 work · ⚠️ 10 partly work · ❌ 3 don't work yet.) Now, what about the other way around? 😊 Just kidding.... If you're thinking, "Now we just need Android apps on iOS,"...well, turns out there’s an app for that too! Check out Husk: Leviidev/Husk It lets you run Android environments/apps on iOS, although with a translation layser and emulation. And keep in mind it does require sideloading, but good news: no jailbreaking necessary!
卓易通怎么来了 Mac.apk: Run Android apps natively on Apple Silicon Macs kksimp/Mac.apk t.co
Mac.apk: Can Android Apps Run Natively on Mac? Mac.apk: Can Android Apps Run Natively on Mac? Source: kksimp/Mac.apk Today's biggest tech story and why it matters — big tech. This is news commentary only, not financial or investment advice. Honestly, ditching heavy virtual machines is the only way cross-platform desktop software actually makes sense. Would you run phone apps on your laptop, or leave them on your phone? #macapk #android #macos #applesilicon #techupdate #technology #technews #ai #gadgets #bigtech #startup #innovation #software #shorts
Android apps running native on macOS View Article | Discussion + AI Summary Summary of HN discussion 🧵👇