On GitHub, someone published droidnative — an Android port of nxnative (the very project that runs Switch games natively on iPhone, iPad, and Mac). The author calls things straight: it's not an emulator. A game on the Switch and a game on the phone are the same ARM64 code, so it runs on the CPU as-is. The repo has 1,300 commits, so this is no evening hack.
The mechanics are almost embarrassingly simple. The game code is rewritten only where the host is needed: system calls, thread registers. The host then answers the Switch's syscalls and SDK services. NVN graphics are translated to Vulkan and handed to the GPU. There's no CPU emulation anywhere in the chain.
Building works only from your own dump. NSP or XCI files go in as input; for Switch 2, a .nup or a dump folder. On Mac, the DroidPlay app does everything with one button. On the command line, the --game-apk flag builds a standalone APK; without the flag, the game goes to the launcher on a device connected via adb. On Windows and Linux, you run python scripts/nxnative_android.py.
The numbers are the author's, from real runs. Pokémon Brilliant Diamond 1.3.0 — 60 fps in Eterna City on the Ayn Odin 2 and OnePlus Pad 3. Animal Crossing: New Horizons 3.0.3 — 30 fps on all three test devices, including the Retroid Pocket 5. Super Mario Odyssey on the Retroid Pocket 5 — 38 fps on the opening cutscene. Breath of the Wild on the Odin 2 — around 20 fps on the Great Plateau. Meanwhile, Mario Kart World on the world map — around 55 fps.
This doesn't look like a coincidence. Handheld Android consoles like the Odin 2 and Retroid are no longer a niche toy, while nxnative stayed Apple-only by the maintainer's choice — the Android branch had to be moved into a separate home. Plus, the Switch 2 is already in people's hands, and .nup appearing in the supported formats list is no accident. Our assessment: the port grew out of a desire to play on your own hardware, not out of a business plan.
What does this change? The project's main thesis challenges the habit of equating "running a Switch game" with "spinning up a CPU emulator." There's no CPU emulation here, and that's exactly why 60 fps looks real rather than promotional. For the handheld console market, it's an argument: the hardware can already do it — it's just a matter of translating NVN to Vulkan. For a phone owner, nothing changes: the dump, keys, and build remain on them.
Who wins. Owners of arm64 devices with Vulkan and their own cartridge library — obviously. The port's author gets attention for the project. Who loses, in our view, is Nintendo: legally, the project rests on "bring your own game," but ready-made APKs with games inside will still spread across forums. This isn't a prediction about a lawsuit — it's an observation of how projects like this tend to unfold.
All we have is a README and a table of runs from the author himself. There are no third-party independent benchmarks. Switch 2 support is claimed formally: Mario Kart World is in the table, but there's no separate breakdown of what exactly makes Switch 2 games run and with what glitches. The list of working games is short, and crashes get one line — "crashes on Adreno 650 due to the driver's shader compiler." You should verify it yourself: build it on your own device and see, rather than trusting the table.
.nup. Trust the format in the README or wait for public runs on a real console library?Forecast: within a quarter, the list of working games in the README will grow, but stable launches on the Adreno 650 won't happen until the driver's shader compiler is worked around.
Disclaimer: not officially confirmed; the project is unofficial, unaffiliated with Nintendo or game publishers, and relies entirely on your own dumps.
Source: github.com · post in Telegram