CrossFly es un framework open source (Apache 2.0) en el que escribes UI y lógica en Java puro y renderiza en la GPU mediante LibGDX/OpenGL, compilando a binarios nativos para Desktop (Windows, macOS y Linux), Android e iOS — más una build WebGL que corre en cualquier navegador moderno — Chrome, Firefox, Safari y otros. Combínalo con CrossFly Sync para datos offline-first.
React Native es el framework open source (MIT) de Meta en el que escribes JavaScript/TypeScript y renderiza usando los widgets nativos de cada plataforma. Su nueva arquitectura (JSI/Fabric/TurboModules) reemplazó el antiguo puente. Apunta a Android e iOS; el desktop es de la comunidad/out-of-tree.
Las diferencias que realmente importan
La nueva arquitectura arregló problemas reales. Aquí está lo que no arregló — y dónde CrossFly es estructuralmente más simple.
La UI sigue montada sobre un único hilo JavaScript
La nueva arquitectura (JSI/Fabric) eliminó el antiguo puente de serialización — una victoria real. Lo que no eliminó es que tu lógica JS corre en un único hilo. Cálculo pesado, listas grandes o animaciones complejas todavía pueden ahogar el hilo de UI y tirar frames; la propia respuesta del ecosistema, FlashList, existe precisamente porque las listas se traban en Android de gama media.
CrossFly no tiene hilo JS alguno en la ruta de render. La UI se dibuja en la GPU desde Java, así que toda la clase de problemas de «el hilo JS está ocupado, así que la pantalla tiembla» simplemente no existe.
Los módulos nativos son una matriz de compatibilidad
Todo lo que el core no cubre — cámara, mapas, Bluetooth, pagos — es un módulo nativo de la comunidad. Mantener docenas de ellos mutuamente compatibles entre Gradle, CocoaPods y cada release de React Native es, en palabras de la propia comunidad, casi un trabajo de tiempo completo; subir de versión rara vez es «solo cambiar el número».
CrossFly es dueño de su stack de render y aprovecha las bibliotecas maduras de la JVM. No hay un zoológico de módulos nativos por plataforma que conciliar, ni ruptura nativa de CocoaPods/Gradle cada vez que cambias de versión.
Las actualizaciones tienen mala fama
React Native es famoso por sus upgrades dolorosos: los cambios que rompen abarcan JS y nativo, los ajustes de AppDelegate/Gradle pueden dejar tu app en pantalla en blanco, y existe un Upgrade Helper oficial porque comparar versiones a mano es así de trabajoso. Quédate un año atrás y encaras migraciones manuales — y la nueva arquitectura ahora es obligatoria, así que los módulos no migrados fuerzan tu cronograma.
Un lenguaje, un toolchain, una superficie pequeña de dependencias y la cultura de retrocompatibilidad de la JVM hacen que los upgrades de CrossFly sean mucho más aburridos — que es exactamente lo que quieres de un upgrade.
El desktop es un añadido, no un destino
El desktop de React Native vive en repositorios separados, mantenidos por la comunidad/Microsoft (react-native-windows/macOS), con su propia cadencia, por detrás del core y de la nueva arquitectura. Es viable, pero es de segunda clase junto a iOS y Android.
El desktop es un destino de primera clase de CrossFly, desde el mismo renderer de GPU que el móvil — un código, un dueño, un comportamiento entre Windows, macOS, Linux, Android, iOS y el navegador.
Dónde CrossFly toma la delantera
Dónde React Native es genuinamente fuerte
CrossFly vs React Native de un vistazo
| Dimensión | CrossFly | React Native |
|---|---|---|
| Lenguaje | Java | JavaScript / TypeScript |
| Renderizado | GPU vía LibGDX/OpenGL | Widgets nativos de la plataforma |
| Threading en la ruta de render | GPU, sin hilo JS | Un hilo JS orquesta la UI |
| Módulos nativos | Pocos (bibliotecas JVM) | Muchos módulos de la comunidad que conciliar |
| Reutilización de Java/backend | Directa (es Java) | Vía módulos nativos / JS |
| Plataformas | Desktop (Windows, macOS, Linux), Android, iOS, web (cualquier navegador) — todas 1ª clase | Android, iOS; desktop out-of-tree |
| Offline-first | CrossFly Sync (bidireccional) | Paquetes de terceros |
| Upgrades | Superficie pequeña, cadencia JVM | Notoriamente trabajosos (Upgrade Helper) |
| Gobernanza | OpenJDK, múltiples proveedores | Meta + comunidad |
| Licencia | Open source (Apache 2.0, Core) | Open source (MIT) |