nxnative: How Switch Games Run on iPhone and Mac

Two weeks ago somebody got Super Mario Bros. Wonder to boot on a Mac. One game, one commit. As I write this, the same GitHub page lists 78 Switch games, the headlines say they run “natively” on Apple silicon Macs and iPhones, and the README says, flat out, “It is not an emulator”. That claim is half true. The true half is clever. The other half is the part the headlines ran with. So here is the plot of this page: what nxnative is, how much of “native” is real, who can actually use it, the Android version that showed up three days ago, and what Nintendo has done about any of it, which so far is nothing. Nothing here will tell you how to build or install anything.

What is nxnative?

Take the headline off and what’s left is a build script. You give it a Switch 1 game from your own library and the keys from your own console, and it turns the two into an app, for iPhone and iPad or for the Mac. The repository is public under the MIT licence, and the README sets the terms in its first lines: “Nothing from any game is in this repository, and the project is not affiliated with Nintendo or any game publisher.”

The part that got my attention is that it has a sibling. Earlier on the same day as nxnative’s first commit, a different GitHub account published d2r-mobile, which does the same trick for one game, the Switch version of Diablo II: Resurrected. nxnative credits d2r-mobile with developing the approach and says it “started as a copy of its generic parts”. Its first commit was called smbw-mobile, after the Mario game it booted; the repository under its current name showed up the next day. And here is how one game became 78 in a fortnight: the documentation is written for AI coding agents, and a contributor account named “claude” sits in the history with two commits. That is not something you expect to find in a scene project.

Is nxnative an emulator, and is it really native?

Here is the whole thing in desk terms. An emulator like Ryujinx or yuzu pretends to be a complete Switch, chip included. On a Windows PC that means translating every instruction the game runs, because a PC chip and the Switch’s chip speak different languages. An Apple chip and the Switch’s chip speak the same language, ARM64. So nxnative doesn’t fake the chip at all. The game’s own code runs on the iPhone or Mac as it is, apart from a small patch for the things Apple’s system refuses to let a program do. That is the true half of “native”, and it is the clever part.

What nxnative still fakes is everything the game expects around the chip. A Switch game spends its life asking the Switch’s operating system for things: memory, saves, controller input, sound, video. On an iPhone that operating system doesn’t exist, so nxnative supplies a stand-in that answers those requests, a fake Switch OS for the game to talk to. Then there are the graphics. Most Switch games draw with Nintendo’s own graphics system, called NVN, and a few use Vulkan or OpenGL; Apple devices draw with Metal. nxnative rebuilds NVN on top of Metal, with its own layers for the other two, and converts the games’ shaders, the little programs that run on the graphics chip, ahead of time. That conversion mostly works (the hit rate is in At a glance), and the docs list what doesn’t, such as some effects that always draw and a type of shader that doesn’t convert. One more thing to know: the chip patch is tied to one version of one game, so a game update usually means a new job, unless the profile has been checked across versions.

So the fair word is a compatibility layer: the chip side is real, the Switch around it is rebuilt. Wine does this for Windows programs on Linux, and Valve’s Proton does it for Steam games on the Steam Deck. Coverage that says the game code needs no translation is right about the chip and wrong about the graphics and the patch. Coverage that calls it an emulator is wrong about the chip. The “How native” row in At a glance is the accurate version, all four parts of it.

Can you play Switch games on an iPhone now?

Yes, if you have the right iPhone, want one of the listed games, and accept that “play” starts with a Mac. The bar is an iPhone 15 Pro or newer, or an iPad with an M1 chip or later, on iOS or iPadOS 26 or newer, because older iPhones can’t read the compressed textures the games ship with. The project names no models beyond that rule, so going by chip: the 15 Pro and Pro Max clear it, everything Apple has released since clears it, the standard iPhone 15 and older don’t. Then memory and storage both bite. iOS gives an app a few gigabytes by default and closes anything that wants more; the memory allowance the project asks for roughly doubles that on a recent iPhone. And since the whole game is packed inside the app, the big games are huge, Breath of the Wild included, with Monster Hunter Rise bigger still.

One thing to know before you picture it in your hand: most of the testing happened on Macs. A game counts as playable once it runs on a Mac or an iPhone, and a Mac test is enough, so a game’s place on the list may or may not mean anyone has played it on a phone. And here is my read, which the docs don’t say outright: because the code is patched and packed into the app before it ever runs, the app never has to generate code on the fly, which is the thing CPU emulators lean on for speed. The docs only say the code is embedded.

Does it work on a Mac?

Yes, on Apple silicon, and honestly the Mac is the real home of this project. The same script builds a Mac app instead of an iPhone one, and the Mac is where the developers get each new game running and measure it. The Breath of the Wild benchmark in At a glance came from an M4 Pro Mac; every number is the developers’ own, on their own machines, and no independent written benchmark has turned up yet. Intel Macs are out, for the same reason the whole thing works on Apple silicon: the game’s code runs as it is, and an Intel chip can’t run it. An Intel Mac can run parts of the tooling and nothing more. The Mac app, like the iPhone one, is something you build yourself; it doesn’t come through the Mac App Store.

For what it’s worth, I own an M3 Max MacBook Pro, so the Mac side of this applies to a machine on my desk, and I carry an iPhone and own a Switch 2. This page won’t walk you through building anything. I’ve written before that the Odin has largely replaced phone emulation for me.

Which Switch games work?

The headliners are the ones you’d guess: Mario Kart 8 Deluxe, Breath of the Wild, Tears of the Kingdom, Super Mario Odyssey, Super Mario Bros. Wonder, Metroid Dread, Animal Crossing: New Horizons, Pokémon Sword and Shield, Persona 5 Royal, Xenoblade Chronicles 3, the three Bayonettas, Astral Chain and Hollow Knight: Silksong. Super Smash Bros. Ultimate is on the list with the note that it works offline. The games table also records what engine and graphics system each one uses, which is how you learn that Balatro runs on LÖVE through OpenGL and that Hades draws with Vulkan.

Every game on the list is there because someone wrote a profile for it: what to patch in that version, what the stand-in OS has to provide, what still breaks. For a game that isn’t listed, the README says the script “still tries its best” and the result “may not start.” So “78 games” really means 78 specific versions that someone has seen run, plus a lottery for everything else. The 60 fps claims travelled furthest, and they come down to a set of listed games marked at 60 with a specific update, where the Switch runs them at 30, plus one marked as a target, every number the project’s own. What doesn’t work is written down too: no online features, no amiibo, a known-issues list per game, and one limit that is reported rather than settled. An open, unmerged community pull request says Super Mario Galaxy inside Super Mario 3D All-Stars hasn’t been packed because its program is 32-bit code, which Apple silicon can’t run.

Can it play Switch 2 games?

No. Nothing in the gallery or the games table is a Switch 2 title, and the README, the development notes and the agent guide never mention one. Everything on the list is a Switch 1 release, which is the generation the whole approach was built around. Whether that is a wall or just where the work is today isn’t something the project says, so this page records the absence and no more. The Switch 2 has its own scene story this month, a tethered exploit for the console itself, covered in its own tracker. Beyond the Nintendo logo, the two have nothing to do with each other.

Is it on the App Store?

No, and the project publishes no app at all. The repository has no releases, so there is nothing prebuilt to download from it, and its documentation never mentions the App Store, TestFlight or the EU’s alternative marketplaces. The route it describes is the one in its opening lines: you bring your own game and keys, a script produces an unsigned iPhone app, and you sideload it. The building happens on a Mac, and the app lives on your own device and nowhere else. Community-made front ends for the script exist, which changes the number of commands and nothing about the requirements. Android is a different story, and it gets its own section next.

Is there an Android version?

Yes, as of three days ago, and it isn’t nxnative’s own doing. On October 24 a separate developer created nx2android, which calls itself “the Android port of nxnative” and carries nxnative’s code inside it. Same trick: the game’s own code runs on the phone’s chip, a stand-in answers for the Switch’s operating system, and the graphics are, in the project’s words, replayed on Vulkan, which is Android’s equivalent of Metal. It already has a first release, which is more than nxnative itself has, and the same stance: bring your own game and keys, nothing from any game lives in the repository, and the tool never ships or downloads either. Nintendo has said nothing about this one either.

The list is short and the hardware is narrow. Five games are marked playable, Graveyard Keeper 2, NEO: The World Ends with You, Unpacking, Viractal and Xenoblade Chronicles 3, with frame-rate notes that are the project’s own, and every one was tested on a single device, a Lenovo Legion Y700 tablet. The catch for everyone else is the graphics chip. The games’ compressed textures need a chip that can read them, and on Android that means Qualcomm’s Adreno or Samsung’s Xclipse. Phones with Mali or PowerVR graphics are out, which rules out a lot of the Android world at a stroke. One small wrinkle: the README says MIT, the same licence as nxnative, while GitHub’s own licence detector finds none at the repository root.

This is the one that lands closest to home for me. My Android phone is set up for emulation, and the Odin 3 Portal I pre-ordered runs a Snapdragon 8 Elite, the same chip family as the tablet nx2android was tested on. That puts it on the right side of the graphics-chip line and nothing more. Nobody has run this on an Odin, so I won’t tell you it works there, only that this page now watches for it.

Is nxnative legal, and has Nintendo done anything?

Nintendo has done nothing visible as of October 27. Its newsroom is silent, two outlets asked and heard nothing back, and GitHub’s public archive of takedown notices, which runs to October 26, has none naming nxnative, its developer or d2r-mobile. The same archive shows Nintendo is anything but idle on GitHub this month. On October 1 it filed notices against mirrors of the Ryujinx emulator and, separately, against a set of “nswitch” repositories, the latter citing circumvention of the Switch’s protection and naming games including Mario Kart 8 Deluxe, Animal Crossing: New Horizons and Breath of the Wild. On October 23 it filed a revised notice against a Rhythm Tengoku decompilation. None of that touches nxnative. All of it shows the company is reading the website the project lives on.

On the project’s side, the legal position is a stance rather than an argument. The README’s one sentence on the subject is that nothing from any game is in the repository and that the project is unaffiliated with Nintendo or any publisher, and the agent ground rules add that game files, keys and anything extracted from them never go into the repository or a commit and are never printed. Beyond that there is no legal reasoning in the docs at all: no fair-use statement, no interoperability claim. It hasn’t made its case, in writing.

The context you need is the yuzu case, and it needs its label. Nintendo sued Tropic Haze, the company behind yuzu, in Rhode Island in February 2024, and nine days later the court entered a final judgment and permanent injunction for $2.4 million. That judgment was stipulated, meaning the two sides jointly asked the court to enter it; no judge ruled on contested facts. Its wording matters because both sides put their names to it. It found that yuzu “is primarily designed to circumvent” the Switch’s protection measures and play its games, and that developing or distributing software “that in its ordinary course functions only when cryptographic keys are integrated without authorization” violates the DMCA’s ban on trafficking in circumvention devices. nxnative also needs the user’s console keys to unpack a game, at build time. Neither a court nor Nintendo has said whether the judgment’s reasoning reaches it, and this page won’t guess. Two more pieces of context, both reported: Ryujinx, the other major Switch emulator, went dark in October 2024 after, according to a team member’s post, its lead developer was contacted by Nintendo and offered an agreement to stop working on the project; and in January 2025 Nintendo’s deputy general manager for intellectual property, Koji Nishiura, said at the Tokyo eSports Festa, per reports of the lecture, that an emulator is not immediately illegal in itself but can become so depending on how it is used, for instance by copying programs or breaking protection.

How is it different from Ryujinx and yuzu?

Those were emulators and this is a per-game compatibility layer, and each side of that trade costs something. Ryujinx and yuzu pretended to be a whole Switch, which is why they could run more or less any game you handed them, and why on a Windows PC they had to translate the game’s code as it ran. Running Switch code straight on an Apple chip isn’t the new part, either: Ryujinx’s Mac build reportedly did that through Apple’s hypervisor, and d2r-mobile used nxnative’s exact approach first. What’s different here is leaving the rest of the emulator out. That only works because Apple’s chips and the Switch’s chip share a language, and the price is generality: every game needs its own profile. The nearest relatives are Wine and Proton on the PC side. The FEX layer Valve uses to run x86 games on its ARM-based Steam Frame headset is a different animal, because FEX translates chip languages, which is the one job nxnative never has to do. And the two Switch emulators live on, in a small way, inside nxnative: its shader converter comes from Ryujinx, and it names yuzu’s shader instruction tables and Atmosphère’s kernel as references for how the Switch behaves.

Timeline so far

Dates are UTC unless marked, and each entry carries the label it has elsewhere on this page.

What would count as the next real step?

This page adds a dated update when something checkable changes: a takedown notice or legal filing naming the project, or the repository going private or disappearing; any public statement from Nintendo; a published prebuilt app, or any App Store or EU marketplace distribution; an Android version from nxnative itself, or nx2android’s list growing past its five games or its one test device; a Switch 2 game running; the iPhone requirement dropping below the 15 Pro; the game list jumping past a round number like 100; or an independent written benchmark from a credible outlet. Star counts, single new games and coverage that repeats the README don’t count.

Where it stands on October 27: real, moving daily, “native” in the CPU sense and only that sense, Switch 1 games on a narrow set of Apple devices, built by you from your own game and keys, and not a word from Nintendo.