⏱️ Lectura: 9 min
A project called Klepton achieves something Meta and Apple never officially connected: running Quest games, Meta’s virtual reality headset line, directly on the Apple Vision Pro, without asking a Just-In-Time compiler for help. Developer shinyquagsire23 published the code on GitHub as a relinker and compatibility layer that translates ARM64 Android APKs into native Apple binaries.
📑 En este artículo
The Klepton Vision Pro repository has 34 stars and 3 forks, and it already has a playable use case: Beat Saber currently runs on both macOS and visionOS, with minor graphical glitches but fully functional.
TL;DR
- Klepton translates ARM64 Android APKs (Quest) into native binaries to run on macOS and visionOS, without JIT.
- It’s an open source project by shinyquagsire23 on GitHub, with 34 stars and 3 forks.
- klepton-ld converts Android .so libraries into Apple .dylib and .framework files before execution.
- OpenGL ES 3.2 is translated with a vendored ANGLE (GLES 3.0, Metal backend); Vulkan goes through MoltenVK.
- Klepton patches every use of the x18 register because macOS resets it on every context switch.
- Beat Saber already runs on macOS and visionOS with minor graphical glitches; Steam VR Link is still in development (WIP).
- The project only supports ‘Java-thin’ apps: no ART, no full embedded JVM.
- Klepton can patch .so files at runtime with mmap, useful only on macOS, where Apple does allow JIT.
What happened
Klepton Vision Pro isn’t an emulator in the classic sense. It doesn’t interpret instruction by instruction or translate Dalvik bytecode: it takes the ARM64 binaries from a Quest APK, practically without touching the instruction bytes, and relinks them against its own runtime written for macOS and visionOS. The result is an app that runs at native speed, because the processor executes the same ARM64 code that ran on Meta’s headset.
The project’s own README is explicit about its scope: Klepton ‘currently focuses on Java-thin applications only (no ART, no JVM)’. In other words, it works with games that use Android only as a thin bootstrap layer (typically engines like Unity with IL2CPP), not with apps that heavily depend on the Android virtual machine. That design decision explains why the first success case is a game made in Unity: Beat Saber.
Context and background
Meta sells Quest as a closed platform running modified Android; Apple sells Vision Pro with visionOS, a completely different system based on the XNU kernel with no official support for running Android binaries. Until now, moving content from one ecosystem to the other meant rewriting the game from scratch against Apple’s APIs: Compositor Services, ARKit, RealityKit.
Klepton avoids that rewrite by reimplementing, at the library level, the system pieces a Quest APK expects to find: libklepton_bionic covers libc, libm, libdl, pthread, and liblog; libklepton_ndk reimplements ALooper, ANativeWindow, and ASensor; libklepton_jni provides a synthetic JavaVM and JNIEnv; and libklepton_ovrp reimplements the Oculus SDK’s ovrp_* functions. The original game believes it’s still running on Android.
Technical architecture and how it works
The heart of the project is the klepton-ld tool, which converts each .so library in the APK into a loadable Apple .dylib or .framework. Those libraries, mostly unmodified at the instruction level, are linked against Klepton’s runtime instead of against Bionic (Android’s libc).
For graphics, Klepton doesn’t rewrite the game’s render engine: it translates the API it uses. OpenGL ES 3.2 goes through a vendored version of ANGLE configured as GLES 3.0 with its Metal backend, and Vulkan is translated to Metal via MoltenVK. Both are mature graphics translation libraries already used outside this project, which saves Klepton from having to write its own shader translator.
One of the finest details of the project is how it handles the x18 register. Both Android and macOS reserve that register for internal system use, but macOS zeroes it out on every context switch. Many older Android apps still use x18 anyway, so klepton-ld patches every access to x18 so it uses per-library TLS (thread-local storage) slots instead, preventing the original binary from corrupting mid-flight.
| Frontend | Platform | Status | Script |
|---|---|---|---|
| Beat Saber (viewer) | macOS on Apple Silicon | Functional, minor graphical glitches | build_run_viewer.sh |
| Beat Saber (Vision Pro) | visionOS | Functional, minor graphical glitches | build_run_vpro.sh |
| Steam VR Link | macOS | In development (WIP) | build_run_slink.sh --shell --view |
flowchart TD
A["Android ARM64 APK (Quest)"] --> B["klepton-ld (relinker)"]
B --> C[".dylib / .framework"]
C --> D["Klepton Runtime"]
D --> E["libklepton_bionic: libc, libm, pthread"]
D --> F["ANGLE GLES 3.0 (Metal backend)"]
D --> G["MoltenVK (Vulkan over Metal)"]
F --> H["Compositor Services / ARKit"]
G --> H
subgraph Native frontend
H
end📌 Note: Klepton can also patch .so libraries at runtime via mmap, but that path only works on macOS, where Apple does allow JIT. visionOS forbids it, so everything there has to be relinked ahead of time.
How to try it
The project is, for now, exclusive to macOS on Apple Silicon (Xcode is needed for the visionOS target). There’s no build for Windows or Linux: the toolchain depends on Apple frameworks like Metal, ARKit, and Compositor Services, which don’t exist outside that ecosystem. According to the repository’s BUILDING.md guide, host dependencies are installed with Homebrew:
brew install pkg-config sdl3 apktool
apktool d -f -o beatsaber beatsaber.apk
make checkThe first command installs the host dependencies (including apktool, needed to unpack the APK). The second decompiles the APK, which the user must obtain on their own (Klepton doesn’t distribute it). make check runs the project’s full regression sweep to confirm the build works before touching anything else.
With that ready, the repo includes quick-start scripts for each frontend:
./build_run_viewer.sh # build and run Beat Saber on macOS
./build_run_vpro.sh # build and run Beat Saber on Vision Pro
./build_run_slink.sh --shell --view # Steam VR Link frontend (WIP)Each script builds the corresponding runtime and launches the native frontend. To confirm the app is using the graphics translator and not silently failing, the repo documents debug environment variables in DEBUG_ENV_VARS.md, useful for isolating whether an issue comes from the relinker, ANGLE, or MoltenVK.
Impact and analysis
Klepton Vision Pro doesn’t solve the general problem of porting any Android app to Apple: its own stated scope, ‘Java-thin’ apps with no ART or JVM, leaves out a huge portion of the Android catalog, especially apps that aren’t games built in Unity or similar engines. But for the specific niche of VR games with IL2CPP, avoiding a full rewrite against RealityKit is a real difference: the engine and gameplay logic are preserved as-is, and only the system and graphics layer underneath changes.
💭 Key point: Klepton doesn’t translate ARM64 instructions to another architecture, macOS and visionOS already run on Apple Silicon (ARM64), so the game executes the same machine code. All of Klepton’s work happens at the operating system and graphics layer, not on the CPU.
That’s also why the project was able to avoid JIT almost entirely: if it had to emulate a different architecture (x86 on ARM, for example), translating instructions on the fly would be nearly mandatory. By staying within native ARM64, Klepton only needs to resolve symbols and reimplement APIs, not reinterpret machine code.
What’s next
The current status, according to the README itself, is: Beat Saber functional on macOS and visionOS with minor graphical glitches, and Steam VR Link still under active work (WIP), along with generalization improvements and build tooling. As of this article, there’s no public list of upcoming supported games or a dated roadmap.
⚠️ Heads up: Klepton is a personal project, not a Meta or Apple product, and it doesn’t distribute APKs: the user needs to legally obtain their own copy of the game they want to decompile with apktool. Also, applications that depend on scripting runtimes like LuaJIT or V8 could actually need real JIT, something only viable on macOS, not on visionOS.
📖 Summary on Telegram: View summary
Try it yourself: install the dependencies with Homebrew, decompile your own APK with apktool, and run make check to see the project’s full regression sweep on your own Mac.
Frequently Asked Questions
What exactly is Klepton?
It’s an open source relinker and compatibility layer that translates .so libraries from ARM64 Android APKs (built for Quest) into .dylib and .framework binaries that run natively on macOS and visionOS, without needing a Just-In-Time compiler.
Do you need a jailbreak to use it on Vision Pro?
The repository doesn’t document any jailbreak requirement; the workflow described in BUILDING.md uses standard Apple development tools (Xcode) to build and run the runtime on visionOS.
What games run with Klepton today?
The only case documented as functional end-to-end is Beat Saber, on both macOS and visionOS, with minor graphical glitches. Steam VR Link is under active development (WIP).
Does Klepton emulate the Android virtual machine (ART or JVM)?
No. The project explicitly focuses on ‘Java-thin’ applications, with no ART or full embedded JVM, which in practice limits support to games built with engines like Unity/IL2CPP.
Why does Klepton barely need JIT?
Because both Quest and macOS/visionOS run on ARM64 processors: the APK’s machine code doesn’t need to be translated to another architecture, only relinked against a different runtime. JIT would only be needed for apps with scripting runtimes like LuaJIT or V8, and it’s only viable on macOS.
Is this an official Meta or Apple project?
No. It’s a personal, independent project published by developer shinyquagsire23 on GitHub, with no declared affiliation with Meta or Apple.
References
- Klepton repository on GitHub: source code, README, and the project’s build guide.
- MoltenVK: the library Klepton uses to translate Vulkan to Metal.
- ANGLE: Google’s project, of which Klepton vendors a GLES 3.0 version with a Metal backend.
- visionOS documentation: Apple’s official reference for the Vision Pro’s operating system.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Kevin Doyle en Unsplash
0 Comments