Mac.apk 如何在 Mac 上免模擬器執行 Android 應用程式(71 款中 58 款可正常運作)
How to Run Android Apps on a Mac Without an Emulator (58 of 71 Apps Work)
Mac.apk 可讓 Android APK 在 Apple Silicon Mac 上以 macOS 應用程式方式執行;相容清單列出的 71 款應用程式中,58 款完全可用、10 款部分可用、3 款未能運作。
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:
- Download the disk image from the Releases page and move Mac.apk into Applications.
- Open it and click Install next to "Runtime:" in the top left.
- In Settings, under File types, click "Make Default" and approve the macOS prompt.
- 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
.appbundle, 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
來源:DEV Community · dev.to