SwitchRECOMP Turns Switch Games Into x86 Programs. That Is Why Your Steam Deck Is Invited and Your Retroid Is Not

2026-11-09 · News and analysis

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

We have spent the last month writing about a toolchain that rebuilds Switch games into real apps for phones and Macs, and the whole explanation rested on one fact: the Switch and your phone both use the ARM64 instruction set, so the game's own code can just run.

The sharpest piece of evidence for that was a negative. An Intel Mac cannot do it. Not slowly, not partially. A fast computer with plenty of memory is locked out because its processor speaks a different language.

That argument is still correct. It also has a mirror image, and in November that mirror image got its first project you could actually download and use.

SwitchRECOMP takes the same Switch game and the same ARM64 code, and instead of running it directly, it translates it into C and compiles that into an x86-64 program. The output is a Windows executable. So the machine the other route locks out, the ordinary x86 PC, is the only machine this route serves.

Two approaches to the same problem, and the hardware requirements are exact opposites.

We should say up front that we are not discovering this argument today. We made the x86 half of it back in September, writing about Suyu's recompiler mode, and the conclusion there was that ARM handhelds gained nothing from it. What is new is that the x86 route now has a live project behind it rather than a dead one, and that it no longer needs an emulator sitting underneath. Both halves of that are worth unpacking.

Everything here assumes you are playing games you already own. We do not link to game files, key files, firmware, or dumping tools, and we do not explain how to obtain any of them.

The Short Version

• What it is. A static recompiler. Your game's code is translated from ARM64 into C once, then compiled into a native program. The game's data is left alone and read as it is.
• What comes out. A Windows executable plus a separate file holding the game code translated to x86-64, plus a data folder and a settings file.
• Which devices. x86 handhelds and PCs. A Steam Deck, a ROG Ally, a Legion Go, a Windows desktop.
• Which devices it will never reach. Every ARM handheld. No Retroid, no Anbernic, no AYN, no Odin. Not a performance limit, a language one.
• Requirements. Windows 10 or 11, 64-bit, and a GPU with OpenGL 4.3 or newer. An optional Vulkan renderer is Windows only and wants Vulkan 1.3.
• Steam Deck. The project's own manual routes Deck owners through Proton, even though its release also ships a Linux build. More on that below, because it is the one thing we cannot resolve cleanly.
• The licence has teeth. It is AGPL version 3 with extra terms. Every fork, and every game you recompile with it, has to keep the project's startup screen and credit.
• It is not alone. Two other projects are doing the same job. One ships Windows builds. One has published no release at all.
• Build time is a real cost. One compiler takes minutes and produces a faster game. The other takes seconds and produces a slower one. You pick.

The Split Down the Instruction Set

This is the useful idea in this article, so it goes first.

There are now two families of project turning Switch games into things that are not emulators, and they are solving the same problem in opposite directions.

Family one: run the original code. The Switch is ARM64 and so is your phone, so hand the game's own compiled instructions to the chip and let it execute them. Nothing is translated. This is nxnative, S2Arm, nx2android and Anka Native, and we cover them in the native ports guide and the Switch 2 on Android piece.

Family two: translate the code once. Read the game's ARM64 instructions, write out equivalent C, and compile that for whatever chip you actually have. The translation happens on your computer before you ever press start. This is SwitchRECOMP, and it is the same technique behind the PC ports of older Nintendo games we wrote about in what decompiled and recompiled games actually are.

Now the consequence, which is cleaner than it has any right to be:

Neither one is better. They are for different hardware, and between them they now cover most of what people actually own. If you have been reading our coverage and concluding that this whole scene passes Steam Deck owners by, that stopped being true.

The reason an Intel Mac could not join family one is the reason x86 handhelds can lead family two. Family one has no translation step to pay for, which is its whole advantage and also its whole restriction. Family two pays that cost once, in advance, which is slow and annoying and then never costs you anything again.

What Changed Since Suyu

In September 2026 the emulator Suyu shipped a version with a Recompiler mode that did the same ahead of time translation to x86-64. We covered it, and we were critical of the framing for three reasons. Two of those three have now moved.

• The project was over. Suyu's recompiler arrived in its final release and the repository was archived days later. That route had no future the moment it appeared. SwitchRECOMP is actively shipping, which is the difference between a curiosity and a thing you might use.
• The emulator was still underneath. Suyu's Recompiler mode shipped bundled with its emulation backend, so graphics, audio and system services all still ran through the emulator. That is why we said the word "native" was doing a lot of load bearing. SwitchRECOMP is standalone: there is no emulator, just translated code plus a runtime.
• The architecture problem did not move at all. x86-64 output meant ARM handhelds gained nothing in September, and it means exactly the same thing today.

And the same caveat still applies here

Fairness demands we point this at the new project too, because the distinction is narrower than its description suggests.

SwitchRECOMP does not need an emulator for the processor. That part is genuinely gone, translated away at build time. But its runtime still stands in for the Switch's operating system services, and it still rebuilds the game's graphics by interpreting what the Maxwell GPU was being asked to do. That is emulation. It is just emulation of the console around the game rather than of the chip inside it.

So "native" is more earned here than it was with Suyu, and it is still not the whole truth. The honest description is that the expensive per instruction work is gone and the console simulation is not.

How It Works

The game splits into two parts, and they get treated completely differently.

The code is the executable portion of your dump. This is what gets read instruction by instruction, turned into C, and compiled. It happens once per game, on your PC. If you later update the game, you recompile.

The data is everything else. Models, textures, music, text. None of it is compiled. The finished program just reads it out of a folder the way the game always did.

Around the translated code sits a runtime written in C, and this is where the actual engineering is. It stands in for the Switch's operating system, answering the requests the game makes for files, memory, threads and controller input. It also stands in for the Switch's Maxwell graphics hardware, rebuilding the game's draw calls on OpenGL, or on Vulkan if you turn that on.

So the thing you end up running is not an emulator in the usual sense. There is no processor being simulated frame by frame. There is a program containing your game's logic, talking to a library that pretends to be a Switch.

What You Need

Stated plainly, because the project states it plainly.

• Windows 10 or 11, 64-bit.
• A GPU with OpenGL 4.3 or newer, with current drivers. This is a low bar by 2026 standards and almost anything x86 clears it.
• A compiler, which the project fetches for you on first run. No admin rights needed.
• Your own dump of a game you own, already extracted into its code and data folders, using your own console's keys. We are not covering that part.

On the compiler there is a genuine choice to make, and it is the kind of tradeoff you rarely get offered:

• The slower compiler takes several minutes on a large game the first time and produces a noticeably faster result.
• The fast compiler finishes in seconds and produces a slower game.

Either way it is a one time cost per game. If the code has not changed, the next run reuses what it already built.

The interface is a deliberate joke: it looks like the Switch home menu, works with a mouse, keyboard or controller, and lists your recompiled games in a row with their own icons pulled out of the dump.

The Steam Deck Question

Here is the part we cannot tie up neatly, and we would rather say so than guess.

The project's player manual contains one sentence about this: Linux and the Steam Deck work through Proton. Proton is the compatibility layer Valve uses to run Windows games on SteamOS. So the documented path for a Deck owner is to run the Windows build inside Proton, exactly as you would with any Windows game in your Steam library.

But the project also ships a Linux build in its release, and its build instructions include a native Linux target with an X11 display backend. Those two facts do not sit comfortably together. Either the Linux build is for recompiling games rather than playing them, or the manual simply has not caught up with the release.

Our position: if you are on a Deck, the documented and supported route is Proton, and that is what we would try first. The Linux build exists and may well work natively. We have not run either, and we are not going to assert which one a Deck owner should use until somebody measures it.

What is not in doubt is that an x86 handheld is the intended audience. A Steam Deck, a ROG Ally, a Legion Go and a MSI Claw are all x86-64 machines with Vulkan and OpenGL drivers well past the requirement. Our Steam Deck retro gaming guide covers the general setup, and EmuDeck is where most Deck owners organise this kind of thing.

Why Your ARM Handheld Will Never Run This

Worth being direct, because this is the question that follows.

The output of this tool is an x86-64 program. Your Retroid, your Odin, your Anbernic and your Thor all have ARM chips. An ARM chip cannot execute x86-64 instructions. There is no setting, no driver and no faster model that changes this.

Could the project target ARM instead? In principle, yes. It emits C, and C compiles for anything. In practice there would be no reason to, because family one already does that job better: if your chip is ARM64 you should just run the game's original code and skip the translation entirely. The two families exist because each one is the right answer for a different chip.

So the practical reading for Android handheld owners is that this specific project is not for you, and the native ports route is. For Linux handheld owners on cheap ARM hardware, neither is, and the PortMaster scene remains the realistic route to native games.

The Licence Detail Worth Knowing

Most project licences are boilerplate. This one is not, and it will matter to anyone thinking about forking it.

It is AGPL version 3, which already requires that anyone distributing a modified version publishes their source. On top of that the project adds its own terms: every copy, fork and derived work must keep the credit to the project and its lab name, keep the notice file, and keep the startup screen that both the recompiler and every recompiled game display when they launch.

That last clause is unusual. It means a game you recompile carries the project's splash screen, and a fork cannot remove it. Whether that holds up as an enforceable addition to the AGPL is a question for someone with a law degree, and we are not going to pretend to answer it. It is simply worth reading before you build anything on top of this.

The optional Vulkan renderer sits under a different licence again, and a build that includes it becomes a GPL version 3 work overall.

Where the Code Came From

Credit where the project gives it, because the provenance here is interesting and it explains why a new project can render commercial games so quickly.

The Vulkan renderer is not original work. It is the same renderer used by a Metroid Dread recompilation project, and its graphics engines, macro interpreter and texture decoder are ported from Eden and yuzu, the mature Switch 1 emulators. The project says so in its own changelog.

That is the pattern across this entire scene. Nothing is being built from scratch. Nine years of Switch 1 emulator work is being pointed at new problems, which is why milestones that sound enormous keep falling in days. We made the same observation about the Switch 2 emulator forks.

The project also sits in a family of recompilers by the same lab covering older handheld and console hardware, which is where the technique was worked out.

It Is Not the Only One

Three projects are attempting this, and the differences are instructive.

• SwitchRECOMP is the one with a published release containing both Windows and Linux builds, a graphical interface, and an actual player manual. It is the only one of the three a non developer could use today.
• A second project, written in Rust, publishes Windows builds and has a genuinely well organised architecture document. It is a few weeks older.
• A third publishes no release at all. The code is there, the issue templates are there, the documentation is extensive, and there is nothing to download.

That third case is the one to keep in mind whenever you see this category written up. We have made a habit of checking release asset lists rather than popularity, because in this scene the busiest looking project is routinely not the one with a working download. It has caught us out before and it will again.

Should You Bother?

Honest answer: not yet, unless you enjoy the process more than the result.

The reasons are the same as every other project in this space. You need a dumped game from your own console, which filters out most people immediately. Compatibility is unproven and the project publishes no compatibility list we could check. And the games named in its changelog are specific titles its author happened to be debugging, which is not the same as a tested library.

What has changed, and it is worth noting, is the shape of the question. For a month the answer to "can my x86 handheld do any of this" was no, because the only route needed an ARM chip. That answer is now yes in principle. Whether it is yes in practice for the game you want is something nobody has measured.

If you want Switch games on a Steam Deck today, emulation is still the answer and it is a good one. Our Eden vs Kenji NX vs Citron covers the route that actually works.

Frequently Asked Questions

Will SwitchRECOMP run on my Retroid or Anbernic?

No, and it never will in this form. It produces x86-64 programs and those devices have ARM chips, which cannot execute x86-64 instructions. This is a language mismatch, not a speed problem. The route for ARM handhelds is the native port toolchain instead.

Does it work on a Steam Deck?

The project's manual says Linux and the Steam Deck work through Proton, which is Valve's layer for running Windows software on SteamOS. Its release also contains a Linux build and its build system has a native Linux target, so a native route may exist too. We have not tested either and would start with the documented Proton path.

Is this an emulator?

Not in the usual sense. Your game's code is translated to C and compiled into a real program before you play, so there is no processor being simulated while you play. The operating system and graphics hardware are still stood in for by a runtime library, so it is not a pure native port either. It sits between the two.

How is this different from running Switch games natively on a phone?

They are opposites. The phone route works because the Switch and the phone share the ARM64 instruction set, so the game's code needs no translating, and that is exactly why it cannot work on an x86 PC. This route translates the code to x86-64 at build time, which is why it works on a PC and cannot work on a phone.

Do I need keys or a dumped game?

Yes. You need a legally dumped copy of a game you own, extracted with your own console's keys. The project ships no games, no keys and no firmware, and downloads none. Without your own dump it does nothing.

How long does recompiling take?

Several minutes for a large game with the slower compiler, which produces a faster game. Seconds with the fast compiler, which produces a slower game. Either way it is a one time cost per game, and the result is reused unless the game's code changes or you update the game.

Why does my recompiled game show someone else's logo at startup?

Because the licence requires it. The project's extra terms say every copy, fork and recompiled game must keep its startup screen and credit. It is deliberate, not a bug.

Related Reading

• Switch games running natively on Apple and Android — the other family, and why it needs an ARM chip
• A Switch 2 game running natively on Android — how far that other family has got
• Suyu's recompiler mode — the first attempt at this route, and why we were harder on it
• What decompiled and recompiled games actually are — the technique behind this one, explained from scratch
• Switch 2 emulators in 2026 — the third route, which is actual emulation
• Lichii: a Switch 2 emulator you can download — and why handhelds are still not invited to that one
• Steam Deck retro gaming guide — the general setup on the device this most benefits
• EmuDeck setup — how most Deck owners organise this
• Eden vs Kenji NX vs Citron — the route that works on a Deck today
• The legal status of emulation in 2026 — the backdrop