Android Horizon
Android Horizon logo

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.

Read this first: this is a very early, experimental project — most of the code was written by Claude (Anthropic's AI) working alongside a non-developer who does the hardware testing and calls the shots on direction. Treat it accordingly. Check the compatibility page before assuming your game will run — it probably hasn't been tried yet.

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 Android Horizon 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.

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.

APK browser
The launcher's APK browser
Loading screen
Live loading screen with real-time compat log
Result screen
Launch result screen
Game splash frame
Fingersoft splash — frame 30
Game frame 300
In-game — frame 300
Game frame 900
In-game — frame 900

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.

The full write-up — build steps, the changelog, every bug that got root-caused along the way — is in the docs.