Nintendo Switch Static Recompilation — State of the Art

A general survey of native-code reconstruction (in the N64: Recompiled / Zelda 64: Recompiled sense) for the Nintendo Switch, independent of any specific game. Companion docs: ps3-recomp.md, ps4-recomp.md, ps2-recomp.md, psx-recomp.md, amiga-recomp.md, snes-recomp.md, megadrive-recomp.md, saturn-recomp.md, arcade-recomp.md, engine-based-porting.md — the last is especially relevant here: a very large fraction of the Switch library, especially at the indie/mid-size tier that dominates its catalog by title count, is built on Unreal Engine or Unity, making engine-rehosting a live alternative to CPU-level recompilation in a way it wasn’t for older, pre-Unreal/Unity platforms in this series.

1. Architecture: the first genuine ARM64 target in this series

Every prior platform surveyed here is either non-ARM (m68k, MIPS, PowerPC/Cell, x86-64) or a 32-bit ARM core (ARM7/ARM9/ARM11-class, covered in sibling GBA/DS docs). Switch breaks that pattern: it runs on an NVIDIA Tegra X1 SoC (model T210, “Erista”), with four ARM Cortex-A57 cores implementing the 64-bit ARMv8-A/AArch64 instruction set (one core reserved for the OS, three for games), clocked at 1.02–1.785GHz depending on mode (Wikipedia: Nintendo Switch). The 2019 die-shrink used in Switch Lite and the OLED model (Tegra X1+ / “Mariko,” T210B01) moves to TSMC’s 16nm process for efficiency and closes the “Fusée Gelée” bootROM exploit, but is not a Pascal-generation part — it keeps the same Maxwell GPU architecture (GM20B, 256 CUDA cores) as the original chip, just die-shrunk (Wikipedia: Tegra). Worth stating plainly since it’s a common point of confusion: no Switch revision shipped a Pascal GPU.

For a native x86-64 PC target, this is the first platform in the series where genuine cross-ISA instruction lifting is unavoidable — unlike ps4-recomp.md, where translating x86-64 Jaguar code to a host x86-64 CPU is nearly a non-problem. But the kind of difficulty differs fundamentally from Cell’s SPU asymmetry (ps3-recomp.md) or PS2’s VU1 microcode (ps2-recomp.md): AArch64 is a mainstream, extremely well-documented, tooling-rich ISA — public Arm architecture reference manuals, first-class LLVM/GCC backends, decades of general-purpose compiler/disassembler support that Cell SPUs or PS2’s vector units never had. The translation problem is real, but it’s engineering-scale, not research-scale.

The GPU side has a similar shape. Switch’s primary low-level graphics API is NVN, proprietary and built by Nintendo/NVIDIA specifically for Tegra/Switch, not published outside licensed developers — some later titles additionally support Vulkan. NVN’s own command format is undocumented publicly, much like RSX’s was for PS3, but the underlying hardware isn’t: NVIDIA distributes a public “Linux for Tegra”/Jetson SDK with documented driver architecture and BSP source (NVIDIA Jetson Linux), open-sourced its GPU kernel modules for Jetson and desktop parts in 2022, and the community nouveau driver project has independently reverse-engineered NVIDIA’s command-submission model across GPU generations. That doesn’t hand anyone NVN’s exact encoding, but it means GPU command-stream research here starts from a public hardware/driver baseline PS3’s opaque RSX never had.

2. Critical context: the Yuzu and Ryujinx shutdowns

This is likely the most legally fraught platform in the entire series, and the two flagship emulators were shut down by two distinct mechanisms — worth keeping separate rather than conflating.

Yuzu, developed by Tropic Haze LLC (spun out of the Citra 3DS team, announced January 2018), was the subject of a direct federal lawsuit: Nintendo of America sued Tropic Haze on February 26, 2024. Tropic Haze settled on March 4, 2024 for $2.4 million, with development and official distribution stopping immediately as part of the settlement (Wikipedia: Yuzu (emulator)).

Ryujinx (started October 2017 by “gdkchan,” C#, by 2024 the more feature-complete of the two, with 3,550+ of ~4,300 tested titles playable) was not sued. On October 1, 2024 its GitHub organization and all related assets were removed; a Discord moderator’s public explanation was that gdkchan “was contacted by Nintendo and offered an agreement to stop working on the project, remove the organization and all related assets” — a direct, non-litigated arrangement with the lead developer, not a court case (Wikipedia: Ryujinx).

The aftermath is an active cat-and-mouse landscape, not a clean end state. Suyu, a Yuzu fork launched almost immediately (March 5, 2024, its name a pun on Nintendo’s litigiousness), was hit with a DMCA takedown on GitLab and banned from Discord in April 2024, ceasing development in February 2025 (Wikipedia: Yuzu (emulator)). Its lineage continued through Sudachi and Citron; as of mid-2026, active continuation Citron-Neo calls itself “a reincarnation of the now gone yuzu emulator, stripped down to the bare minimal requirements,” ships weekly builds against current firmware, and uses a GPLv3 fork of the Dynarmic ARM dynamic-recompilation library (citron-neo.github.io; citron-neo/emulator, 393 stars). Ryujinx’s community continuation, Ryubing, has moved its main code repo off GitHub onto self-hosted Forgejo infrastructure — GitHub hosts only peripheral tooling now, a visible sign of continued caution (github.com/Ryubing). Also visible: heavy SEO-spam/scam-repo pollution keyword-stuffed with “Yuzu”/“Ryujinx”/“prod.keys” language, which any survey here has to filter out.

3. Horizon OS and homebrew tooling

Switch’s custom microkernel OS (“Horizon”) is, like PS3’s and PS4’s OS layers, extensively reverse-engineered via a homebrew/CFW community rather than official documentation. libnx (switchbrew/libnx) is the dominant AArch64-only homebrew SDK — roughly 1,400 stars, ~2,200 commits, actively maintained — wrapping Horizon’s syscalls and system services. Atmosphère (Atmosphere-NX/Atmosphere) is the dominant custom-firmware project, over 19,000 stars, spanning the boot chain (Fusée), TrustZone (Exosphère), kernel patches (Thermosphère), and userland sysmodule reimplementations (Stratosphère) — showing deep, working community understanding of Horizon’s kernel/service layer, comparable in spirit to how PS3/PS4 homebrew scenes underpin those docs’ OS sections. Its license notably carries a clause letting Nintendo use contributed code under alternate terms, suggesting at least tacit vendor awareness rather than pure adversarial secrecy.

4. Existing prior art for static recompilation

Searching specifically for genuine ARM64-to-x86-64 static/AOT recompilation of Switch titles — distinct from Yuzu/Ryujinx/Citron-style dynamic recompilation — turns up real but very early, non-mainstream work: not silence, but not maturity either. Two small, recent, independent projects surfaced: bgyss/SwitchRecomp (Rust, 11 stars, started January 2026), whose own README calls it “an early draft” — mostly a specification/scaffolding effort rather than a working recompiler yet — and Nx86-emu/Nx86 (Rust, 1 star, started June 2026), further along technically: a genuine AArch64 decoder, an IR (“NxIR”) with a differential-testing oracle, and an x86-64 lowering/register-allocation backend, built around what it calls “Continuous Dynamic Compilation” rather than pure static output, and which explicitly refuses to compile any commercial title dump as a stated legal boundary. Neither project connects to the established community recurring across this series — the N64Recomp/Zelda 64: Recompiled lineage (“Wiseguy”), ps3recomp (“sp00nznet”), or the broader “R.A.I.D.”-adjacent community touching SNES/Genesis work. No evidence surfaced of that community publicly starting Switch work — a mildly surprising gap given how much more recent and commercially active the Switch library is than most platforms surveyed here, plausibly explained by the acute legal exposure in §2 discouraging exactly the public, named-author projects that exist for PS3.

5. The engine-based-porting angle

Cross-referencing engine-based-porting.md’s thesis, Switch is arguably the best-positioned platform surveyed in this series for engine rehosting over CPU-level recompilation. Both Unreal Engine and Unity have official, Nintendo-licensed Switch export/platform support — real, precedented, NDA-gated SDK offerings through Nintendo’s developer program, not community reverse-engineering — and both have first-class, actively maintained PC-native builds to rehost onto. Because so much of the Switch library, especially the indie/mid-tier scale dominating its catalog by title count, ships on Unreal or Unity rather than bespoke in-house engines, the UnrealScript/Blueprint and Mono-IL/IL2CPP decompilation tooling engine-based-porting.md surveys (UE Explorer, Il2CppDumper, AssetRipper, dnSpy) applies to a larger slice of the Switch catalog than PS3’s or PS2’s. For that slice, recovering script/bytecode and asset content, then feeding a legitimate PC engine build, is likely more tractable than lifting AArch64 machine code at all — §1’s CPU-recompilation problem mainly matters for the native-C++ core of engine titles and the shrinking-but-real share of the library on wholly custom in-house engines.

6. Honest maturity assessment

Switch needs to be ranked on two separate axes, and collapsing them into one score would misrepresent the picture.

Technically, Switch sits in an unusual middle position: harder than PS4 (real cross-ISA lifting is required, unlike x86-64-to-x86-64), but categorically more tractable than PS3 or PS2 (AArch64 is mainstream, fully public, tooling-rich, with no analog to SPU local-store asymmetry or VU1 microcode). The GPU side is similarly medium-tractable — NVN is undocumented, but it sits on Tegra hardware with more public driver/BSP documentation than PS3’s RSX ever had. Dynamic ARM64-to-x86-64 recompilation is proven and mature at emulator scale (Dynarmic, used across the whole Yuzu-fork lineage); genuine static/AOT recompilation is real but embryonic — two small, unaffiliated, sub-year-old projects, not a maturing ecosystem.

Legally, Switch is the most litigated and actively policed platform in this series by a wide margin — a completed federal lawsuit and settlement (Yuzu), a direct developer-level shutdown outside the courts (Ryujinx), a DMCA-driven fork casualty (Suyu), and an ongoing pattern of takedowns pushing successors toward self-hosted infrastructure and legal-adjacent branding (Citron-Neo, Ryubing). None of this speaks to the difficulty of the CPU/GPU translation problem — it’s a separate, independently severe constraint on how openly any recompilation project here could be pursued or published, and it plainly correlates with why this platform, despite technical tractability and enormous commercial relevance, has the thinnest public static-recompilation prior art of any modern platform surveyed in this series.