Desarrollo móvil híbrido

¿Sabes esa conversación clásica cuando alguien aparece de la nada y dice «tuve una idea para una aplicación»? Pues bien, además de intentar huir de ese gran problema que muchas veces termina siendo ideas un poco poco ortodoxas, también tenemos que pensar qué tecnologías usar en el desarrollo móvil. Y hoy el mundo híbrido es mucho más interesante de lo que solía ser.

El panorama actual: React Native, Flutter y Expo en la primera línea

Cuando miramos el mercado actual, tres nombres dominan completamente el escenario del desarrollo híbrido. React Native sigue muy fuerte, especialmente en mercados como Portugal, donde la mayoría de los proyectos híbridos que se ven por ahí todavía apuestan por esta tecnología. Y no es casualidad - si tienes un equipo que ya domina JavaScript, tiene todo el sentido aprovechar ese conocimiento.

Flutter también está ganando mucho terreno, principalmente entre desarrolladores que vienen de backgrounds más variados. Para quien tiene experiencia en C#, Kotlin o Java, el lenguaje Dart termina teniendo una curva de aprendizaje más suave. Y la verdad es que se ven cada vez más vacantes para Flutter, incluso para juniors, lo que era una novedad hasta hace poco tiempo.

Pero una de las grandes sorpresas ha sido Expo. ¿Recuerdas cuando todo el mundo decía que Expo iba a morir allá por 2019? Pues bien, no solo no murió sino que la propia documentación oficial de React Native ahora recomienda empezar proyectos nuevos con Expo. Es como si fuera una capa que quita mucha de la complejidad del React Native tradicional.

La revolución del rendimiento: Bridgeless e Impeller

Una de las cosas que más me impresiona es cómo la cuestión del rendimiento, que era el talón de Aquiles del desarrollo híbrido, está mucho más resuelta. ¿Recuerdas los tiempos de PhoneGap y Cordova? Era una diferencia brutal entre híbrido y nativo. Hoy en día, esa diferencia es mucho menor.

En React Native, el gran cambio fue la nueva arquitectura sin bridge. Antes, siempre que necesitabas comunicarte con algo nativo, tenía que pasar por un puente que hacía la traducción de una cosa a otra, y eso era síncrono. Ahora, el código JavaScript va allí y habla directamente con lo nativo. La diferencia de rendimiento ya no es tan grande comparada con lo nativo.

Por el lado de Flutter, tuvieron una evolución interesante con el motor de renderizado. Empezaron con Skia, luego cambiaron a Impeller para conseguir animaciones más fluidas. Flutter consigue entregar 60 frames por segundo como máximo, lo que trae animaciones mucho más cercanas a la experiencia nativa.

El desafío de la fragmentación de dispositivos

Ahora, no vamos a fingir que todo es un camino de rosas. Una de las cosas que más aleja a la gente del mundo móvil es la fragmentación de dispositivos. Si tomamos un iPhone, es un solo sistema operativo, todo bien, pero tenemos varios iPhones, cada uno con su rendimiento. En Android, la situación se amplía mucho más - no solo tenemos muchas versiones diferentes de Android sino también muchos sabores de sistemas personalizados por los fabricantes.

Ya tuve experiencias bastante complicadas con eso. Una vez tuve un bug en un determinado cliente que usaba un LG no sé qué, y el teclado no funcionaba de la misma manera que en los otros dispositivos. Para hacer debug, dio un poco de trabajo porque no hay emulador específico para LG.

Xiaomi, por ejemplo, pasó mucho tiempo con un bug en el que cuando tomabas una captura de pantalla, la pantalla se oscurecía porque la grabación de la pantalla ocurría unos microsegundos después, cuando la animación estaba oscureciendo. Entonces las capturas de pantalla siempre salían un poco más oscuras.

Afortunadamente, hoy tenemos herramientas como BrowserStack, que es de pago y online. Puedes cargar tu APK o IPA y te da una gama de dispositivos reales que puedes probar online. Ayuda bastante cuando trabajas en proyectos que se usan tanto en tablets como en dispositivos variados.

Design Systems: iOS vs Android

Una cosa interesante es cómo Apple tiene esa obsesión histórica con la consistencia. Todo tiene que tener «cara de Apple». Y ves una evolución en los design systems de los dos sistemas operativos que llegó a un nivel de madurez donde, en general, las aplicaciones Android que ejecutas tienen cara de Android, y las aplicaciones iOS tienen cara de iOS.

La diferencia está en el enfoque. React Native compila los componentes React en componentes nativos de hecho. Es decir, si está usando el componente nativo, cuando hay una actualización de iOS o Android, sigue usando el nativo. Ganas ese «look and feel» más cercano al sistema operativo.

Por otro lado, Flutter tiene una premisa diferente porque trabaja con Canvas - dibuja los componentes en la pantalla en lugar de usar el componente nativo. Cuando sale una actualización del sistema operativo, tienes que estar atento a la documentación de Flutter para saber cuándo estará disponible la nueva versión de Material Design para Android y de Cupertino para iOS.

Son premisas diferentes. Si quieres estar siempre en la última versión del diseño del sistema operativo, React Native no sufre de eso. Pero si quieres crear una identidad propia de la empresa, menos del sistema operativo, Flutter puede ayudarte bastante en esa dirección.

Expo: De patito feo a recomendación oficial

Una de las cosas más interesantes de seguir es la evolución de Expo. Hubo un tiempo en que, si querías hacer algo más complejo, tenías que hacer «eject» de Expo porque no daba abasto. Ahora ya no es así. Probablemente podrás mantenerlo por mucho tiempo sin necesidad de eyectar.

Expo abstrajo mucha de la complejidad de cosas muy útiles. Antes, si querías poner una fuente en React Native, tenías que hacer varios pasos para instalar una simple fuente, que es algo que en todo proyecto vas a tener. Expo abstrae eso de una forma hermosa. Hoy tiene muchas bibliotecas listas para usar Firebase, Stripe, autenticación con Apple y Google, cámaras, giroscopio, Bluetooth...

Y una cosa que mucha gente no sabe: la propia documentación de React Native ahora dice que si quieres iniciar un proyecto, debes empezar con Expo. Parece que realmente quieren reemplazar el CLI tradicional.

Mercado laboral: Diferentes realidades

Cuando miramos el mercado laboral, vemos realidades muy diferentes dependiendo de la región. En Portugal, por ejemplo, hay una proximidad mucho mayor con React Native. Se ven bastantes vacantes de React Native, y para la gente que viene de la web, tiene sentido - ya saben JavaScript.

Ya en Brasil, por ejemplo, hay un crecimiento interesante de Flutter. La gente que tiene background en backend, que viene de C#, Java o Kotlin, encuentra la curva de aprendizaje de Dart más accesible.

Una cosa interesante es que se ven cada vez más vacantes para Flutter junior, lo que era una novedad. Antiguamente, las empresas siempre querían a alguien con experiencia, pero ahora ya hay espacio para quien está empezando.

Tiendas alternativas: Una nueva realidad

Una cosa que está moviendo el ecosistema son las tiendas de aplicaciones no exclusivas. En iOS, eso ya es una realidad en Europa por el Digital Markets Act. En Android siempre existieron varias tiendas, pero ahora en iOS también empezamos a ver alternativas.

Para quien desarrolla y sube a las tiendas, en términos de código no cambia nada porque al final vas a generar un paquete (IPA, APK) y el sistema operativo sabe manejar eso. Pero donde puede haber implicaciones es en el ciclo de desarrollo y distribución.

Apple siempre fue más restrictiva - toda esa procesión para subir una app, va y viene, es rechazada, vuelve a ser subida... Pero eso también garantiza que alguien está mirando para asegurarse de que lo que se va a publicar no tiene nada malicioso.

El ecosistema Dart: Más que solo Flutter

Una cosa interesante es ver cómo el ecosistema de Dart está creciendo más allá de Flutter. Hay iniciativas como Shelf, que es una biblioteca para hacer web services, y Serverpod, que es un backend hecho en Dart orientado principalmente a Flutter.

La idea es simple: si tienes una persona especialista en Flutter, ¿por qué diablos vas a aprender Dart para generar una app? Normalmente, cuando eso sucede, la app no es el producto principal - es para atender una demanda específica del mercado.

Pero si estás empezando una startup o una tecnología nueva, y alguien del equipo ya conoce Flutter, puede ser una elección tan buena como cualquier otra. Tiene sus trade-offs, pero también tiene sus ventajas.


Capacitor: El sucesor de Cordova

Otro cambio interesante es la transición de Cordova a Capacitor. Ionic, que antiguamente usaba Cordova por debajo de los paños, ahora usa Capacitor por defecto. La premisa de Capacitor es ser un «Cordova mejorado» - una versión diferente que asume las responsabilidades de comunicación con lo nativo, pero de forma más eficiente.

Xamarin RIP, MAUI Hello

Y ya que estamos hablando de frameworks que murieron, no podemos olvidar a Xamarin. Algunos se pusieron muy felices e hicieron aquel velorio vikingo, pero ahora Microsoft vino con MAUI (Multi-platform App UI) para reemplazarlo.

MAUI es una evolución natural de Xamarin. El principal cambio es en la arquitectura - en lugar de tener un proyecto separado para cada plataforma, ahora es un solo proyecto donde cada carpeta tiene su target específico. Debajo del capó cambió mucho, y ahora usa el .NET moderno para ejecutar.

Animaciones: La obsesión del mobile

Una cosa que cualquier persona que trabaja con mobile se da cuenta rápidamente es la obsesión que este mundo tiene con animaciones y transiciones. Si no tienes animaciones fluidas, el usuario sentirá que la aplicación es menos responsive o que tiene problemas.

Tanto React Native como Flutter hicieron inversiones enormes en esta área. React Native implementó engines de juegos para hacer animaciones más fluidas, y Flutter tiene esa perspectiva de los 60 frames por segundo para traer animaciones más acordes con el uso nativo.

Linx: La innovación china

Una novedad interesante viene de China con Linx, desarrollado por ByteDance (la empresa detrás de TikTok). Llegó como una «revolución» en el universo de React Native, enfocado en convertir desarrolladores web a mobile y optimizado para el «instant first frame», es decir, en el momento en que haces clic en la aplicación, debe ser instantánea.

Consideraciones para la elección de framework

Cuando se trata de elegir un framework, todo depende del contexto. Si tienes un equipo que ya sabe JavaScript, ¿para qué diablos vas a aprender Dart para generar una app? Normalmente, cuando eso sucede, la app no es el producto principal - es para atender una demanda específica del mercado.

Pero si estás empezando una startup o una tecnología nueva, y alguien del equipo ya conoce Flutter, puede ser una elección tan buena como cualquier otra. Tiene sus trade-offs, pero también tiene sus ventajas.

Consejos para diferentes perfiles

Para quien aún no ha entrado en el mercado, el consejo es enfocarse mucho en la base: lógica de programación, HTML/CSS (aunque no te vayas a enfocar en web, te servirá mucho), y el lenguaje que elijas - ya sea JavaScript, Dart, u otro.

Para quien ya desarrolla pero no tiene experiencia mobile, el camino es tomar el lenguaje que ya dominas y ver si tiene alguna opción para mobile. Si eres desarrollador C# o Java, mira Flutter. Si vienes de la web con JavaScript, React Native tiene sentido.

¿Y para quien ya está en un punto más avanzado de la carrera? Solo decir «depende» y hablar de trade-offs. Esa es la realidad - no hay una solución perfecta para todos los casos.

El futuro del desarrollo híbrido

El desarrollo híbrido ha llegado a un punto de madurez impresionante. La diferencia de rendimiento con el nativo es cada vez menor, las herramientas están más maduras, y el ecosistema es más rico.

La elección entre frameworks ya no es tanto sobre cuál es técnicamente superior, sino sobre cuál se adapta mejor al contexto del equipo, del proyecto y de los objetivos. Y eso es algo bueno - significa que tenemos opciones sólidas para prácticamente cualquier escenario.

Al final de cuentas, como diría cualquier desarrollador experimentado: depende. Pero al menos ahora tenemos dependencias de calidad para elegir.