Cómo desarrollar una aplicación móvil híbrida
10 febrero, 2019Si tu objetivo es crear una aplicación móvil, hoy en día tienes una gran variedad de opciones a tu alcance para hacerlo. Antes de optar por desarrollar una aplicación móvil híbrida, es posible que te plantees la clásica implementación en Java (Android) o Swift / Objective-C (iOS).
Puede que el mayor inconveniente de utilizar esta práctica de desarrollo móvil nativo sea la «duplicidad» de tu aplicación. Si quieres que tu app se use en diferentes tipos de dispositivos, no te quedará otra que implementar dos versiones: una para Android y otra para iOS. Y ni siquiera hemos hablado de Windows Phone. Una vez tengas tu aplicación en las app store, cualquier ampliación o mantenimiento deberá hacerse en cada una de las tecnologías por separado. Esto, obviamente, incrementa tiempo y coste de desarrollo.
Aplicaciones híbridas al rescate
Esto es algo que los desarrolladores de tecnologías móviles se dieron cuenta hace ya años. Siendo así, rápidamente surgió una alternativa: desarrollar la aplicación móvil híbrida. Una aplicación móvil híbrida no es más que una app construida en un lenguaje que permite generar una versión de la misma para cada una de las principales tecnologías móviles, es decir, Android, iOS y Windows Phone. Adiós al problema de la «duplicidad». Sin embargo, desde las primeras aproximaciones en Phonegap, pronto surgió otro dolor de cabeza: el rendimiento. Las primeras aplicaciones híbridas que surgieron tenían problemas notorios en este sentido. Rápidamente te dabas cuenta que la aplicación que estabas usando era híbrida. Acciones tan simples en apps nativas como transiciones entre páginas o despliegues de menús se hacían verdaderamente complejas (¡y lentas!) de ejecutar.
Afortunadamente desde entonces ha llovido mucho. Hoy en día ya tenemos en el mercado una serie de herramientas más avanzadas. Éstas nos permiten desarrollar nuestra app multiplataforma sin los problemas mencionados o, cuanto menos, minimizándolos todo lo posible. Échémosles un vistazo:
1. Ionic
Este framework trabaja en el clásico Cordova (antiguo phonegap) utilizando tecnologías web (HTML + CSS + JS). Al final, la aplicación no es más que un WebView que muestra una web.
Obviamente, esta web puede tener una apariencia de aplicación móvil y, por tanto, parecer nativa. De hecho los estilos que se muestran en distintas plataformas (Android / iOS / Windows Phone) no tienen por qué ser los mismos, lo que ofrece una experiencia de aplicación nativa aún mayor.
Al ser la tecnología web tan estándar, el desarrollo de aplicaciones móviles híbridas en Ionic se hace extremadamente simple y poco costoso. No cuesta demasiado encontrar desarrolladores web y la curva de aprendizaje es mínima. Con el curso de front-end para diseñadores tendrías más que suficiente para empezar. En muy poco tiempo puedes disponer de tu app lista para las tres plataformas. Por otro lado, la comunidad Ionic es increíble. Dispones de una infinidad de recursos a la hora de desarrollar que minimizan la posibilidad de quedarte estancado en un problema en pleno desarrollo.
Ahora bien, el problema de raíz que vuelve a tener Ionic es el rendimiento. Al ser una web que se ejecuta sobre un navegador, existen ciertas interacciones que no se ejecutan de forma tan ágil como se esperaría. En acciones como transiciones entre páginas, arrastre de elementos o selección de objetos se nota la diferencia con respecto a una app nativa. Esto limita el uso de esta tecnología en aplicaciones móviles. A grandes rasgos, habitualmente se utiliza en aplicaciones sin mucha funcionalidad y con acciones simples y concretas. Otro uso muy extendido es para aplicaciones internas empresariales, donde esta «falta de fluidez» no es tan importante.
2. Xamarin
Xamarin ofrece la posibilidad de generar las correspondientes versiones en Android, iOS y Windows Phone en base a un núcleo común. La principal ventaja de este framework es que acabas obteniendo una aplicación «nativa» real. Este hecho rompe la barrera del problema del rendimiento visto hasta ahora. No se trata de un Webview que ejecuta una web, si no que cada plataforma ejecuta su propia versión de la aplicación, pese a que el core es común.
El lenguaje que se utiliza para desarrollar en Xamarin es C#, del framework .NET. De hecho, con el curso de desarrollo full-stack .NET tendrías las bases más que suficientes para implementar tu aplicación en esta tecnología. Sí que es cierto que la curva de aprendizaje no es tan rápida como en Ionic y se requieren algunos conocimientos específicos de Xamarin.
Como no podía ser de otra manera, esta opción también tiene sus inconvenientes. Puede que uno de los problemas más importantes sea que se requiere un desarrollo específico para la interacción con el usuario en cada plataforma. En la imagen anterior, el UI Layer. Este hecho retoma en una pequeña proporción la «duplicidad» original de las aplicaciones nativas. Otro inconveniente es que el entorno de desarrollo es complejo y tedioso de configurar.
De nuevo, esta opción se hace óptima cuando la el desarrollo de la aplicación móvil híbrida es simple y sin muchos flujos. Si la funcionalidad visual crece, el tiempo de desarrollo crece tres veces más rápido. También es una buena opción cuando el core del negocio ya está en .NET. Al ser éste un lenguaje muy utiliza por grandes empresas, es muy común que haya procesos de negocios ya implementados en C#. Si esta situación se da, simplemente es cuestión de desarrollar la capa de User Interface para cada dispositivo y ¡listo!
3. React Native
React es una tecnología web relativamente nueva, lleva cerca de 5 años en el mercado. Su concepto y su sintaxis hacen que un desarrollador de front-end tenga una curva de aprendizaje muy rápida. Tanto es así, que en el curso de front-end para diseñadores hay un apartado exclusivo para esta tecnología. Una de sus variantes es React Native, que permite construir aplicaciones móviles híbridas en React. A diferencia de la tecnología híbrida basada en web vista con Ionic, React Native genera sus propias aplicaciones móviles híbridas a través de controladores UI nativos.
Dado que la aplicación que se ejecuta es nativa, el rendimiento es muy cercano al nativo real y la duplicidad de código es mínima. Sí que es cierto que, para determinadas circunstancias, se requiere código específico para cada plataforma, pero son casos muy concretos. La base de React es la separación de la aplicación en componentes reusables, lo que facilita increíblemente el desarrollo.
Como defecto destacable, se podría decir que, al utilizar Controladores UI Nativos, nunca se tiene un control total sobre la aplicación generada. Es el framework de React Native el que construye la aplicación, lo cual genera una «caja negra» para el desarrollador. En determinados casos, esto puede generar problemas de rendimiento o gestión de memoria realmente complejos de solucionar.
Por lo general, esta es una opción muy adecuada para aplicaciones más avanzadas. Al estructurar la aplicación en componentes reusables, la escalabilidad de la aplicación es muy alta, pudiendo construir apps complejas de forma simple. De hecho, existen ya varios ejemplos de aplicaciones reales que utilizan este framework, como Facebook, Instagram, Aribnb o UberEats.
4. Flutter
Como novedad (lleva aproximadamente 3 años en el mercado), tenemos a Flutter: la alternativa de Google. En esencia, funciona de forma muy similar a React Native. A partir de un lenguaje común, se generar aplicaciones nativas «reales». Ahora bien, este framework utiliza Widgets propietarios y una serie de herramientas UI específicas para generar componentes visuales con una fluidez y una visualización increíbles.
El rendimiento de una aplicación Flutter es increíblemente similar a una aplicación móvil desarrollado con código nativo. Por otro lado, dado que Google soporta este framework, la comunidad y la documentación de esta herramienta es cada vez mayor y avanza a pasos agigantados.
Como contrapartida, se podría decir que Flutter utiliza Dart como lenguaje de programación. A diferencia del resto de tecnologías vistas hasta ahora, Dart es un lenguaje que, pese a que apareció en 2011, su uso no es en absoluto muy extendido. Este hecho hace que encontrar desarrolladores Dart sea un reto digno de mención. Por otro lado, al ser Flutter un framework «recién salido del horno», la comunidad no es muy grande y la posibilidad de encontrarse un problema que nadie más se haya encontrado antes en pleno desarrollo es relativamente alta. Aún así, esto es algo que previsiblemente cambiará en el corto plazo, siempre y cuando Flutter se posicione fuertemente en el mercado.
Vale… Entonces, ¿qué uso?
Obviamente, la decisión de utilizar una tecnología u otra es muy subjetiva. De hecho, es muy probable que incluso expertos en tecnología que lean este artículo no estén en absoluto de acuerdo con lo que se explica en esta sección. Aún así, te vamos a dejar una serie de consejos para que puedas elegir correctamente la tecnología de tu applicación móvil híbrida:
-
Evalúa el equipo
Como es natural, tu equipo de trabajo podrá condicionar en gran medida la tecnología a escoger. Si tengo en mi equipo expertos en Java y en Swift, no nos vamos a lanzar a aprender Dart simplemente por los beneficios que ofrece una aplicación en Flutter. Hay que sopesar las curvas de aprendizaje y la pérdida de experiencia cuando se salta de tecnología
-
Valora la complejidad de la aplicación
Es decir, enumera los casos de uso de tu aplicación. Si te salen flujos muy variados y muy complejos, es posible que una solución como React Native te ayude. Sin embargo, si tu aplicación es simple y sin demasiadas vistas, puede que una implementación en Ionic te permita tener tu app lista mucho más rápido y el mantenimiento sea más simple.
-
Identifica elementos ya existentes
Si no partes de cero, es posible que tu aplicación se base en un sistema ya existente. De ser así, la elección de una u otra tecnología puede venir condicionada por la capacidad de integración de tu app móvil en el proyecto en el que estés. Por ejemplo, si tu proyecto está en .NET, es posible que usar Xamarin te permita reutilizar lógica de negocio ya implementada. Si por el contrario, el proyecto está hecho en tecnologías web clásicas, puede que se integre mejor con Ionic.
-
Considera el público objetivo
La falta de fluidez de aplicaciones híbridas puede ser un problema o no. Especialmente en función de si tu aplicación está orientada a un público general o a uno en concreto. Por ejemplo, consideremos a los trabajadores de un almacén que utilicen una app para registrar los envíos que entran y salen. Probablemente les importe poco la falta de fluidez de la app al cambiar entre pantallas de una aplicación en Ionic. Ahora bien, si la aplicación es una red social, el escenario cambia. Puede que los usuarios sean más sensibles a estos aspectos y prefieran aplicaciones construidas en React Native o Flutter.