Android games, running on Nintendo Switch — for real
Not an emulator. No Android OS underneath. The game's actual ARM64 code runs directly on the Switch's own chip, with a compatibility shim standing in for everything Android normally provides.
What this actually is
It's Wine, basically, except the "Windows app" is an Android game and the "Linux" is a game console. There's no emulation happening and no hidden Android install — the game's native .so library gets loaded and run directly on the Switch's Tegra X1, the same ARM chip that's in a lot of Android phones. What Viridite actually provides is a shim underneath it: enough of libc, JNI, OpenGL ES, and asset/file handling that the game never notices it isn't talking to a real Android device.
Because of that, what runs and what doesn't comes down to what the shim happens to implement, not how "big" or "small" a game is in the abstract. Right now that means older, simple 2D games with an arm64-v8a build, OpenGL ES rendering, no Play Services dependency, and saves that stay on-device. Hill Climb Racing is the one game that's actually been pushed through this end-to-end — see below for exactly what that took.
What's confirmed working, on real hardware
ELF loading and linking with zero unresolved symbols, real libnx threads standing in for pthreads, actual touch input reaching the game's own input handlers, real audio decoding (OGG/MP3/Opus/FLAC) through a custom SDL2_mixer backend, a locked 60fps during gameplay, and saves that persist across launches. Hill Climb Racing also plays on a controller — Viridite drives the game's own gamepad support from the Switch pad, which means it works docked — and the launcher updates itself over the network.
Seen on real hardware
Every screenshot below came off the Switch itself — the launcher saves a copy of each UI screen, and the game loop grabs the actual framebuffer at a few milestone frames. Nothing here is a mockup.
How it's put together
Two repos, chain-loaded into each other instead of one big binary — mostly because a Switch process is stuck in one execution mode (64-bit or 32-bit) for its whole life, so the picker and the engine had to be separable from day one.
Viridite
The picker. Scans your APKs, figures out which native ABI each one ships, and hands off to the right engine when you launch something. Doesn't know how to load an ELF or fake a JNI call — that's not its job.
VNX-Translation-Core
The actual engine — ELF loading, JIT, the Bionic/JNI compat layer, audio, sensors. Everything above is really describing what this repo does.
The full write-up — build steps, the changelog, every bug that got root-caused along the way — is in the docs.