Un proyecto llamado Klepton logra algo que Meta y Apple nunca conectaron oficialmente: correr juegos de Quest, la línea de visores de realidad virtual de Meta, directamente en el Apple Vision Pro, sin pedir ayuda a un compilador Just-In-Time. El desarrollador shinyquagsire23 publicó el código en GitHub como un relinker y compatibility layer que traduce APKs Android ARM64 a binarios nativos de Apple.
El repositorio de Klepton Vision Pro acumula 34 estrellas y 3 forks, y ya tiene un caso de uso jugable: Beat Saber corre hoy tanto en macOS como en visionOS, con fallos gráficos menores pero de forma completa.
TL;DR
- Klepton traduce APKs de Android ARM64 (Quest) en binarios nativos para correr en macOS y visionOS, sin JIT.- Es un proyecto de código abierto de shinyquagsire23 en GitHub, con 34 estrellas y 3 forks.- klepton-ld convierte librerías .so de Android en .dylib y .framework de Apple antes de ejecutar.- OpenGL ES 3.2 se traduce con una ANGLE vendorizada (GLES 3.0, backend Metal); Vulkan pasa por MoltenVK.- Klepton parchea todo uso del registro x18 porque macOS lo resetea en cada cambio de contexto.- Beat Saber ya corre en macOS y visionOS con fallos gráficos menores; Steam VR Link sigue en desarrollo (WIP).- El proyecto solo soporta apps 'Java-thin': sin ART ni una JVM completa embebida.- Klepton puede parchear .so en runtime con mmap, útil solo en macOS, donde Apple sí permite JIT.
Qué pasó
Klepton Vision Pro no es un emulador en el sentido clásico. No interpreta instrucción por instrucción ni traduce bytecode Dalvik: toma los binarios ARM64 de una APK de Quest, prácticamente sin tocar los bytes de instrucción, y los relinkea contra un runtime propio escrito para macOS y visionOS. El resultado es una app que corre a velocidad nativa, porque el procesador ejecuta el mismo código ARM64 que corría en el visor de Meta.
El propio README del proyecto es explícito sobre el alcance: Klepton 'currently focuses on Java-thin applications only (no ART, no JVM)'. Es decir, funciona con juegos que usan Android solo como capa fina de arranque (típicamente motores como Unity con IL2CPP), no con apps que dependen fuerte de la máquina virtual de Android. Esa decisión de diseño explica por qué el primer caso de éxito es un juego hecho en Unity: Beat Saber.
Contexto e historia
Meta vende Quest como plataforma cerrada de Android modificado; Apple vende Vision Pro con visionOS, un sistema completamente distinto basado en el kernel XNU y sin soporte oficial para correr binarios Android. Hasta ahora, llevar contenido de un ecosistema a otro implicaba reescribir el juego desde cero contra las APIs de Apple: Compositor Services, ARKit, RealityKit.
Klepton evita esa reescritura reimplementando, a nivel de librería, las piezas del sistema que un APK de Quest espera encontrar: libklepton_bionic cubre libc, libm, libdl, pthread y liblog; libklepton_ndk reimplementa ALooper, ANativeWindow y ASensor; libklepton_jni ofrece una JavaVM y un JNIEnv sintéticos; y libklepton_ovrp reimplementa las funciones ovrp_* del SDK de Oculus. El juego original cree que sigue corriendo sobre Android.
Arquitectura técnica y cómo funciona
El corazón del proyecto es la herramienta klepton-ld, que convierte cada librería .so de la APK en un .dylib o .framework de Apple cargable. Esas librerías, sin modificar en su mayoría a nivel de instrucción, se enlazan contra el runtime de Klepton en vez de contra Bionic (la libc de Android).
El runtime intermedio de Klepton reimplementa NDK, JNI y las APIs de Oculus.
Para gráficos, Klepton no reescribe el motor de render del juego: traduce la API que usa. OpenGL ES 3.2 pasa por una versión vendorizada de ANGLE configurada como GLES 3.0 con su backend de Metal, y Vulkan se traduce a Metal mediante MoltenVK. Ambas son librerías de traducción de gráficos ya maduras y usadas fuera de este proyecto, lo que le ahorra a Klepton tener que escribir un traductor de shaders propio.
Uno de los detalles más finos del proyecto es el manejo del registro x18. Tanto Android como macOS reservan ese registro para uso interno del sistema, pero macOS lo pone en cero en cada cambio de contexto. Muchas apps Android viejas siguen usando x18 igual, así que klepton-ld parchea todo acceso a x18 para que use slots de TLS (thread-local storage) por librería en su lugar, evitando que el binario original se corrompa en pleno vuelo.
FrontendPlataformaEstadoScriptBeat Saber (viewer)macOS con Apple SiliconFuncional, fallos gráficos menoresbuild_run_viewer.shBeat Saber (Vision Pro)visionOSFuncional, fallos gráficos menoresbuild_run_vpro.shSteam VR LinkmacOSEn desarrollo (WIP)build_run_slink.sh --shell --view
flowchart TD
A["APK Android ARM64 (Quest)"] --> B["klepton-ld (relinker)"]
B --> C[".dylib / .framework"]
C --> D["Runtime Klepton"]
D --> E["libklepton_bionic: libc, libm, pthread"]
D --> F["ANGLE GLES 3.0 (backend Metal)"]
D --> G["MoltenVK (Vulkan sobre Metal)"]
F --> H["Compositor Services / ARKit"]
G --> H
subgraph Frontend nativo
H
end
📌 Nota: Klepton también puede parchear librerías .so en tiempo de ejecución vía mmap, pero esa ruta solo sirve en macOS, donde Apple sí permite JIT. visionOS lo prohíbe, así que ahí todo tiene que estar relinkeado por adelantado.
Cómo probarlo
El proyecto es, por ahora, exclusivo de macOS con Apple Silicon (se necesita Xcode para el target de visionOS). No hay build para Windows ni Linux: la cadena de herramientas depende de frameworks de Apple como Metal, ARKit y Compositor Services, que no existen fuera de ese ecosistema. Según la guía BUILDING.md del repositorio, las dependencias de host se instalan con Homebrew:
brew install pkg-config sdl3 apktool
apktool d -f -o beatsaber beatsaber.apk
make check
El primer comando instala las dependencias del host (incluyendo apktool, necesario para desempaquetar la APK). El segundo decompila la APK que el usuario debe conseguir por su cuenta (Klepton no la distribuye). make check corre el barrido de regresión completo del proyecto para confirmar que el build funciona antes de tocar nada más.
Con eso listo, el repo trae scripts de arranque rápido para cada frontend:
./build_run_viewer.sh # build y corre Beat Saber en macOS
./build_run_vpro.sh # build y corre Beat Saber en Vision Pro
./build_run_slink.sh --shell --view # frontend de Steam VR Link (WIP)
Cada script compila el runtime correspondiente y lanza el frontend nativo. Para confirmar que la app está usando el traductor de gráficos y no fallando en silencio, el propio repo documenta variables de entorno de depuración en DEBUG_ENV_VARS.md, útiles para aislar si un problema viene del relinker, de ANGLE o de MoltenVK.
Beat Saber es hoy el único caso de uso completo y jugable de Klepton.
Impacto y análisis
Klepton Vision Pro no resuelve el problema general de portar cualquier app Android a Apple: su propio alcance declarado, apps 'Java-thin' sin ART ni JVM, deja afuera a una porción enorme del catálogo de Android, sobre todo apps que no son juegos hechos en Unity o motores similares. Pero para el nicho específico de juegos VR con IL2CPP, evitar una reescritura completa contra RealityKit es una diferencia real: el motor y la lógica de gameplay se preservan tal cual, y solo cambia la capa de sistema y gráficos por debajo.
💭 Clave: Klepton no traduce instrucciones ARM64 a otra arquitectura, macOS y visionOS ya corren en Apple Silicon (ARM64), así que el juego ejecuta el mismo código de máquina. Todo el trabajo de Klepton está en la capa de sistema operativo y gráficos, no en la CPU.
Esa es también la explicación de por qué el proyecto pudo evitar el JIT casi por completo: si tuviera que emular una arquitectura distinta (por ejemplo x86 sobre ARM), traducir instrucciones al vuelo sería casi obligatorio. Al mantenerse dentro de ARM64 nativo, Klepton solo necesita resolver símbolos y reimplementar APIs, no reinterpretar código de máquina.
Qué sigue
El estado actual, según el propio README, es: Beat Saber funcional en macOS y visionOS con fallos gráficos menores, y Steam VR Link todavía en trabajo activo (WIP), junto con mejoras de generalización y tooling de build. No hay, hasta la fecha de este artículo, una lista pública de próximos juegos soportados ni un roadmap con fechas.
⚠️ Ojo: Klepton es un proyecto personal, no un producto de Meta ni de Apple, y no distribuye APKs: el usuario necesita conseguir legalmente su propia copia del juego que quiera decompilar con apktool. Además, aplicaciones que dependan de runtimes de scripting como LuaJIT o V8 sí podrían necesitar JIT real, algo que solo es viable en macOS, no en visionOS.
📖 Resumen en Telegram: Ver resumen
Probalo vos: instalá las dependencias con Homebrew, decompilá tu propia APK con apktool y corré make check para ver el barrido de regresión completo del proyecto en tu propio Mac.
Preguntas frecuentes
¿Qué es exactamente Klepton?
Es un relinker y compatibility layer de código abierto que traduce librerías .so de APKs Android ARM64 (pensado para Quest) en binarios .dylib y .framework que corren de forma nativa en macOS y visionOS, sin necesitar un compilador Just-In-Time.
¿Hace falta jailbreak para usarlo en Vision Pro?
El repositorio no documenta un requisito de jailbreak; el flujo descrito en BUILDING.md usa herramientas estándar de desarrollo de Apple (Xcode) para compilar y correr el runtime en visionOS.
¿Qué juegos corren hoy con Klepton?
El único caso documentado como funcional de punta a punta es Beat Saber, tanto en macOS como en visionOS, con fallos gráficos menores. Steam VR Link está en desarrollo activo (WIP).
¿Klepton emula la máquina virtual de Android (ART o JVM)?
No. El proyecto se enfoca explícitamente en aplicaciones 'Java-thin', sin ART ni una JVM completa embebida, lo que en la práctica limita el soporte a juegos con motores como Unity/IL2CPP.
¿Por qué Klepton casi no necesita JIT?
Porque tanto Quest como macOS/visionOS corren en procesadores ARM64: el código de máquina de la APK no necesita traducirse a otra arquitectura, solo relinkearse contra un runtime distinto. El JIT solo sería necesario para apps con runtimes de scripting como LuaJIT o V8, y solo es viable en macOS.
¿Es un proyecto oficial de Meta o Apple?
No. Es un proyecto personal e independiente publicado por el desarrollador shinyquagsire23 en GitHub, sin afiliación declarada con Meta ni con Apple.
Referencias
- Repositorio de Klepton en GitHub: código fuente, README y guía de build del proyecto.- MoltenVK: la librería que Klepton usa para traducir Vulkan a Metal.- ANGLE: el proyecto de Google del que Klepton vendoriza una versión GLES 3.0 con backend Metal.- Documentación de visionOS: referencia oficial de Apple sobre el sistema operativo del Vision Pro.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)