Layers y aplicaciones mobile híbridas

Los layers pueden ser una maravilla si hablamos de comida o de niveles de abstracción. Si trasladamos eso a tratar de ganar tiempo introduciendo layers por encima de una plataforma móvil; el tema ya no es tan agradable.

En estos 10 años de Sodep, el negocio del Software Factory y los diferentes proyectos y tipos de clientes, nos ayudaron a mantenernos actualizados y conocer nuevas tecnologías año a año.

Hemos aprendido the hard way suficientes veces que:

nuevo != mejor

Las tecnologías mobile híbridas custom made o vía frameworks, las progressive Web apps, o una de las más recientes: React Native; seducirían a cualquiera que tenga que manejar el presupuesto de un proyecto informático. Nuestros clientes no fueron la excepción a esto.

De experiencias similares pudimos identificar ciertos aspectos técnicos que hacen a cualquier plataforma que busque abstraer capas entre el Hardware, Sistema Operativo, y lo que finalmente ve o usa el usuario final.

1. Experiencias con tecnologías similares

Cuando utilizamos un framework para UI que actúa como una capa extra a la versión nativa; siempre habrá un trade off con la performance, limitadas funcionalidades y problemas de seguridad.

You always get lost in translation

Siempre se pierde algo en cualquier traducción. Las traducciones entre layers no son la excepción.

La experiencia acumulada @Sodep

1.1 Genexus (desktop) [2011]: En teoría, una ventaja era poder producir código fuente en múltiples lenguajes. La realidad, nos mostraba que el código generado por ej. en Java no eran más que wrappers a llamadas JNI (librerías nativas para cada plataforma).

1.2 JSF (web) [2013-2014] : La teoría decía que se podía generar interfaces Web o mobile escribiendo JSF/Java; en lugar de HTML y JS. En la práctica, terminás customizando HTML y JS puro, a veces escrito desde componentes Java. Una pérdida enorme de recursos server-side; generar siempre un enorme DOM sumado a las decenas de librerías JS descargadas, fueran o no necesarias para la página en cuestión.

1.3 PhoneGap/Cordova (mobile) [2014-2015]: Eran básicamente Web apps; que tienen bridges para acceder a ciertas funcionalidades nativas (GPS, cámara, etc.); con una performance malísima; prácticamente inusable.

1.4 Aplicaciones custom utilizando JSBridge (iOS/Android) [2014-2016]: Hicimos nuestra propia implementación de bridges usados desde un WebView. Para 7 diferentes apps nos resultó productivo, eran sencillas,  poco uso de funcionalidades nativas; y usadas básicamente para mostrar información con muy poco de tráfico hacia al server. Al querer hacer aplicaciones más complejas en navegación, múltiples pantallas, y empezar a acceder a funcionalidades nativas relacionadas con el HW del teléfono; ya se empezaba a perder performance y a complicarse el debug.

Todas estas tecnologías tienen algo en común con las tecnologías híbridas de moda en la actualidad:

Relativamente fácil de hacer el startup y producir resultados simples en corto tiempo. Un prototipo sale con poco esfuerzo.

Todas compartieron también los mismos problemas.

• No escalan bien. Al crecer la complejidad la performance se va al tacho.
• Lleva mucho esfuerzo mantenerse actualizado entre versiones.
• La mayoría de las dependencias de terceros embedded hacen que las actualizaciones de seguridad tarden más en llegar.

En los casos mobile:

• Los stores y sus reglas a menudo rompen builds con actualizaciones forzadas o prohíben la publicación debido a restricciones que son mucho más complicadas para los generadores de app cumplirlas.
• Se pierde la potencia de los IDEs de las plataformas nativas y sus herramientas: Debug, Instant run, profiling, análisis de los binarios, etc.
• Pasás de usar un lenguaje compilado a un scripting, cuando el proyecto crece a decenas de miles de líneas: God help us all.

via GIPHY

• Tenés que hacer doble debug: Debug del lenguje intermedio (JS o lo que sea) y debug a nivel de la plataforma nativa, porque no sólo tu código tendrá bugs, también los n bridges que acceden a las funcionalidades nativas.
• Las constantes traducciones entre capas son demasiado costosas para las CPUs de los devices de gama media o baja.
• Por lo general el UI se ve como un enlatado o un foráneo, como si construyeras una casa con bloques pre-fabricados.
• El tamaño de la APP generada es mucho mayor. No hay escapatoria a esto, se tiene que incluir los engines para las traducciones/layers. Una arquitectura de ejemplo, como la de RN mostrada a continuación dejará esto más claro.

2. React Native

En varias oportunidades recibimos solicitudes para usar la nueva moda del ahorro:  React Native (RN).

RN es una herramienta desarrollada por Facebook, con el objetivo de escribir código en ReactJS y generar aplicaciones para iOS y Android. Fue hecha open source en el año 2015, tiene apenas 4 años en el mercado abierto.

La arquitectura de RN, tiene varios niveles de abstracción, con el supuesto objetivo de crear una experiencia "casi nativa" (según palabras de Facebook).

Como informáticos, sabemos que cada traducción, cada capa de abstracción nueva, tiene su penalización en términos de consumo de memoria y de ciclos de CPU.

Este es un gráfico simplificado de la arquitectura de RN.

2.1 Limitaciones de React Native y riesgos

El principal cliente de RN es Facebook. La gobernanza del proyecto se centra en las necesidades de sus apps para la red social, postergando cambios propuestos por la comunidad. Esta práctica es común cuando está por detrás una gran empresa, Apple hacía lo mismo con webkit.

La cantidad de módulos RN muestra lo complejo que es mantener cada bridge a alguna funcionalidad nativa.

Como muestra de la inestabilidad, basta un botón:

El repositorio que atiende los mapas tuvo 2k+ issues en menos de 4 años (el primer issue es del 2016).

A la fecha 300+ abiertos.

3. Decisiones para iniciar un proyecto

¿Otros contendientes como Flutter, Ionic, Xamarin encontraron La Fórmula Mágica?

¿Pudieron escapar a estas limitaciones intrínsecas de tener que traducir algo nativo a otra tecnología creando nuevas capas?

No, no es técnicamente posible.

React Native pidió feedback a los developers que la usan: ¿qué no te gusta de RN?

Sería muy interesante conocer lo que opinan los developers sobre estas otras tendencias.

Como programador, a ratos líder de proyectos y a ratos emprendedor; no podría coincidir más con la esperanza de poder escribir una vez y que pueda tener en las plataformas mobile, apps corriendo lo antes posible y con el menor presupuesto.

La obsesión por la calidad, la experiencia y los detalles técnicos por detrás nos muestran otro camino.

via GIPHY

Una pregunta que les recomiendo se hagan dentro del equipo, incluyendo a los que idearon el producto y a quiénes irán a desarrollarlo es: ¿Cuál es mi driver para el proyecto?

• Time to market: Es algo innovador y necesitamos algo rápido para probar y ver si el producto prende.
• Presupuesto: No tenemos otra opción que hacerlo híbrido, porque tenemos clientes en ambas plataformas. Si el prototipo o MVP sale bien, podríamos conseguir más presupuesto.
• Calidad: Buscamos la mejor experiencia para el usuario, una solución de calidad que dure muchos años, cuyo mantenimiento sea el menos problemático.

Como Sodep, nuestro consejo a varios clientes fue y sigue siendo:

Si es una app que pensás usar por muchos años, querés brindar a tus usuarios la mejor experiencia y a tu proyecto/equipo de developers el menor costo de mantenimiento, optá por las soluciones nativas.

En todo proyecto de desarrollo, los factores que contribuyen al éxito son varios: La  calidad de developers en cada tecnología es uno de ellos; a igual calidad de developers las plataformas nativas son la mejor alternativa.

Con app híbridas, tu techo de calidad siempre será mucho más bajo.

Nuestro consejo es que analices detenidamente las necesidades, el tiempo que durará y los recursos de tu proyecto.

Si tenés la opción de ir por una app nativa; tené por seguro que los resultados serán mejores.