Glonce

Klepton runs Android VR APKs on Apple Vision Pro

toolsThe Glonce editorsHacker News🔥64Glonce rating64Impact50Novelty68Relevance65Surprise58Players32Credibility82
Klepton runs Android VR APKs on Apple Vision Pro

Klepton is a project that lets Android ARM64 VR APKs run on Apple Vision Pro without requiring JIT compilation. Its companion tool, klepton-ld, translates Android .so libraries into loadable Apple .dylib and .framework libraries, which then link into the Klepton runtime; the guest code (translated Mach-O binaries such as libil2cpp, libunity and libunityopus) keeps its instruction bytes mostly unmodified, while imports are resolved against a set of Klepton runtime libraries that reimplement Android's bionic libc, NDK surfaces (ALooper, ANativeWindow, ASensor, AAsset), a synthetic JNI/JavaVM layer, and Oculus's ovrp API. On the graphics side, GLES 3.2 calls are translated to a vendored ANGLE implementation of GLES 3.0 running on its Metal backend, and Vulkan calls go through MoltenVK; the frontend layer then maps onto Apple's Compositor Services, ARKit, GameController and AVAudioEngine. Klepton currently supports only "Java-thin" applications, meaning it does not implement Android's ART or a JVM. One specific low-level problem the project had to solve: both Android and macOS reserve the x18 register, but many older Android apps still use it anyway, and macOS zeros x18 on every context switch; klepton-ld patches all x18 usage in guest code so that per-library thread-local-storage slots are used instead. Klepton can also load and patch .so files at runtime via mmap, though the project notes this is only useful on macOS, since Vision Pro does not allow JIT; apps that rely on scripting runtimes expecting JIT, such as LuaJIT or V8, will likely need it and may not run. To build and test the project, users install pkg-config, sdl3 and apktool via Homebrew, decompile their own APK with apktool, run a full regression sweep with "make check", and use provided scripts to build and run macOS or Vision Pro frontends; a Steam VR Link frontend is listed as work in progress. The one confirmed working example is Beat Saber, which the project describes as running on both macOS and visionOS with only minor graphical issues; broader compatibility and build tooling are still being generalized.

Key facts

  • Klepton translates Android ARM64 VR APK binaries into native Apple .dylib/.framework libraries via klepton-ld, without needing JIT compilation.
  • GLES 3.2 calls are translated through a vendored ANGLE running GLES 3.0 on Metal, and Vulkan calls go through MoltenVK.
  • The project supports only Java-thin Android apps (no ART, no JVM implementation).
  • klepton-ld patches all use of the x18 register, since macOS zeros it on context switches while older Android apps still rely on it.
  • Beat Saber is the one demonstrated working app, running on both macOS and visionOS with minor graphical issues; Steam VR Link support is still work in progress.

Why it matters

Vision Pro has no native access to the much larger library of Android-based standalone VR apps, most of which target Meta Quest headsets. Klepton is a binary translation layer, not an emulator: it rewrites Android .so libraries into Apple-native libraries ahead of time and keeps most instruction bytes untouched, which is what lets it avoid JIT compilation, a technique Apple restricts on visionOS. That approach also covers the graphics stack, remapping GLES 3.2 and Vulkan calls onto Apple's own Metal-based ANGLE and MoltenVK implementations rather than requiring apps to be rewritten for Apple's APIs.

Who it affects

Vision Pro owners who want to run existing Android VR content, and developers of Java-thin Android VR titles (built on engines like Unity, judging by the libunity and libil2cpp libraries named in the project) who want their apps to reach Vision Pro without a native port. It also affects Steam VR users, since a Steam VR Link frontend for macOS is listed as in progress.

How to use it

The project is used from source: install pkg-config, sdl3 and apktool with Homebrew, decompile a user-supplied APK with apktool, then run "make check" for a full regression sweep. Separate scripts build and run the macOS frontend, the Vision Pro frontend, and the work-in-progress Steam VR Link frontend. Users must supply their own APK; the project does not distribute app content itself. No pricing or licensing terms are stated in the source.

How solid is it

The only concretely demonstrated result is Beat Saber, which the project states is working on both macOS and visionOS with minor graphical issues. Steam VR Link and general build tooling are explicitly marked as still work in progress. The source names no author, organization or team, gives no release date or version number, and provides no performance benchmarks or measured compatibility figures beyond the Beat Saber example, so the maturity of the project rests on that single demonstrated case.

Risks and caveats

Support is limited to Java-thin apps; anything requiring ART or a full JVM is out of scope. Apps that depend on scripting runtimes expecting JIT, such as LuaJIT or V8, will likely need JIT and may not run correctly, since Klepton's runtime patching of .so files via mmap is described as useful mainly on macOS, where JIT is actually permitted, not on Vision Pro itself. Beyond Beat Saber, no other specific games or apps are named as tested or working, and the register-level patching required (such as the x18 workaround) points to a project that is still handling low-level compatibility issues on a case-by-case basis.