¿Apps híbridas o apps nativas? Un breve análisis comparativo de tecnologías móviles

-«¿Qué opción tecnológica elegimos para el desarrollo de la app?, ¿Mejor tecnología híbrida o quizá nativa?» son algunas de las preguntas a las que nos enfrentamos cuando arranca un nuevo proyecto de desarrollo de una aplicación móvil. Este artículo va de eso mismo: a lo largo de este post hemos querido explicar, a través de una breve y siempre-cuestionable-y-por-lo-tanto-hecha-con-humildad comparativa, las ventajas e inconvenientes de las Apps Nativas y de las Apps Híbridas.

Antes de empezar, queremos dejar claro que ninguna de las dos opciones que vamos a analizar es per sé mejor que la otra. Simplemente queremos compartir la reflexión previa que hacemos nosotros en cada proyecto de desarrollo de una App móvil, con el fin de poder ayudaros a elegir mejor.

Definiendo los tipos de aplicación

Entrando un poco en materia y para poner en contexto, merece la pena realizar una breve presentación de los dos tipos de aplicaciones que posteriormente procederemos a comparar:

¿Qué es una aplicación híbrida?

Aplicaciones desarrolladas en HTML, CSS y Javascript que corren sobre una capa de abstracción / framework (Apache Cordova, Ionic, React Native, Capacitor…) que proporciona acceso a los recursos del terminal de forma neutral al tipo de dispositivo. Por ello, mediante este paradigma, se desarrolla una única aplicación común que luego se prepara para cada plataforma (con pequeños ajustes funcionales si fuera necesario).

¿Qué es una aplicación nativa?

Aplicaciones desarrolladas sobre el lenguaje de programación nativo (Java, Swift, Objetive-C,…) del dispositivo. Estas aplicaciones son 100% dependientes de la plataforma. Por ello, hay que desarrollar y mantener una aplicación completa para cada plataforma destino (iOS, Android u otros).

10 criterios de valoración para elegir entre aplicaciones nativas e híbridas

A lo largo de los años desarrollando tanto aplicaciones móviles híbridas como nativas, hemos comprobado que la selección de la tecnología dependerá de la casuística y necesidades de negocio de cada cliente y cada proyecto. Para ello, en Irontec hemos buscado una serie de criterios sobre los que analizar las dos opciones. Se trata de una serie de indicadores que nos permiten ver las ventajas y desventajas de los dos tipos de apps.

Los indicadores recogen las necesidades desde el punto de vista del cliente y sus necesidades de negocio, así como de las necesidades tecnológicas a cubrir:

1. Time-to-market del desarrollo inicial: se refiere al tiempo para llevar la aplicación a mercado desde el concepto al despliegue con el mismo número de recursos.
2. Time-to-market de nuevas funcionalidades: se refiere al tiempo para llevar a mercado cualquier desarrollo evolutivo del producto inicial con el mismo número de recursos.
3. Tiempo para ajustar una nueva funcionalidad/lanzamiento a diseño: se refiere al tiempo necesario para ajustar de forma precisa un nuevo desarrollo al diseño aprobado por cliente.
4. Experiencia del usuario: en este punto se refiere a la experiencia general del usuario al utilizar la aplicación.
5. Reutilización de código: se refiere a la capacidad para reutilizar código entre plataformas.
6. Sencillez para mantener el código: se refiere a la facilidad para mantener código desde el punto de vista de minimizar “bugs” o fallos de programación, realizar desarrollos evolutivos, portar código entre plataformas y formar al equipo técnico encargado del desarrollo.
7. Rendimiento de la aplicación: se refiere al rendimiento de la aplicación en consumo de recursos de CPU y memoria del terminal.
8. Look & Feel de la aplicación: se refiere a la posibilidad de personalizar el diseño para adaptarlo a las necesidades específicas aprobadas por el cliente.
9. Capacidad para convivir Nativo-Híbrido: se refiere a la posibilidad de hacer convivir partes de desarrollo nativo con partes de desarrollo híbrido.
10. Coste de desarrollo: se refiere al coste final que tendría un proyecto dependiendo de si elegimos desarrollarlo de forma híbrida o nativa.

Comparativa (easy-mode-on) entre aplicaciones nativas e híbridas

Ahora que tenemos claro las características básicas, conozcamos las principales diferencias entre Apps Nativas y Apps Híbridas en función de cada uno de los diferentes criterios de valoración establecidos.

1. Time-to-market del desarrollo inicial

En las aplicaciones híbridas se trabaja sobre un único código base para todas las versiones de aplicación, por ello, con los mismos recursos, el time-to-market de este tipo de aplicaciones podría ser más corto. En ocasiones podemos encontrarnos con tareas que requieran hacer diferenciación entre plataformas. En este caso se requeriría de un doble desarrollo, pero siempre será un subconjunto de tareas menor que la totalidad del proyecto.

Como riesgo se podría identificar que puesto que la aplicación ha de probarse en ambas plataformas, se podrían encontrar problemas de compatibilidad entre versiones que las nativas no presentan.

En el caso de las aplicaciones nativas el time-to-market es mayor. No necesariamente tiene que ser el doble por lo explicado arriba, pero si que será cercano al doble. Las aplicaciones nativas requieren conocimientos específicos de cada una de las plataformas, por lo que generalmente los equipos de desarrollo están duplicados. Para conseguir un tiempo de lanzamiento igual tendríamos que invertir algo más, pero ese es otro punto :).

2. Time-to-market de nuevas funcionalidades

Una vez que la aplicación está desarrollada, muchos clientes requieren de un desarrollo evolutivo continuo de la misma. Para nosotros resulta importante analizar cuánto puede costar en tiempo y dinero lanzar nuevas funcionalidades en el futuro. En el caso de las aplicaciones híbridas no es necesario mantener dos tecnologías diferentes y dos códigos base diferentes, por lo que con los mismos recursos podemos producir nuevas funcionalidades de forma más rápida.

Sí que existe un riesgo en la compatibilidad de los terminales que puede hacer que en algunos casos aislados el despliegue sea más costoso de lo que sería un desarrollo nativo. No obstante, la evolución de los frameworks de desarrollo híbrido como por ejemplo Capacitor, han minimizado en gran medida este riesgo.

En el caso de las aplicaciones nativas, habitualmente se requiere del doble de recursos, pero por otro lado nos podría permitir añadir funcionalidades individuales a cada plataforma para probarlas antes de su completa integración. Desde Irontec consideramos que es una práctica no muy bien percibida por el usuario, pero que en ocasiones podría ser necesaria.

3. Tiempo para ajustar una nueva funcionalidad/lanzamiento a diseño

Este criterio afecta al equipo responsable del diseño de la aplicación, tanto diseño UX/UI como diseño gráfico propiamente dicho. En el caso de las aplicaciones híbridas, se cuenta con mayor facilidad y flexibilidad a la hora de modificar elementos de la UI (motion, vistas, controles personalizados, etc). Esto no significa que una aplicación híbrida sea más usable, bonita o rápida. Significa que en las aplicaciones híbridas se pueden modificar elementos estándar de la UI con una menor inversión de tiempo.

En el caso de una aplicación nativa se requiere de ajustar/adaptar cada plataforma de forma individual. Concretamente en el caso de Android la aplicación de motions y animaciones fuera de lo estándar ofrecido por el SDK nativo resulta especialmente costosa.

4. Experiencia de uso

Este punto es quizá uno de los más complejos de evaluar. Si bien es cierto que con las tecnologías actuales, es posible crear una experiencia de uso muy similar a una nativa, en algunos terminales antiguos, el rendimiento y por lo tanto la experiencia de uso puede ser algo inferior. Esto también pasa con los desarrollos nativos en terminales antiguos. Por lo tanto en este punto vemos que podría haber una diferencia mínima.

En la actualidad, en nuestro entorno, identificamos que es muy reducido el grupo de usuarios que realmente reclama una experiencia de uso nativa. Dependiendo del tipo de aplicación y de si la misma está correctamente desarrollada, hoy en día es complejo identificar la diferencia entre ambas. Sin embargo existen algunas ventajas en el uso de aplicaciones nativas. Por ejemplo en aplicaciones de alta carga gráfica como juegos o simuladores, la experiencia de uso es muy superior. Además, las transiciones y cambios de vista son más “naturales” dentro de los desarrollos nativos. Sobre un desarrollo basado en las SDKs oficiales los patrones de diseño son los que el usuario ya conoce. Obviamente este punto se resuelve en una aplicación híbrida con un proceso de diseño de UX adecuado. Finalmente es común que la aplicación fluya mejor cuando es 100% nativa.

Por lo tanto en este punto, nuestra conclusión sería que si la aplicación no requiere grandes cargas gráficas y se implementa adecuadamente tanto el diseño de UX como la programación, ambas soluciones darán una experiencia de uso satisfactoria. En aplicaciones con requerimientos gráficos potentes como juegos, visualización 3D, animaciones, etc, las aplicaciones nativas tendrán ventaja.

5. Reutilización de código

El código de una aplicación híbrida es portable a otras plataformas con una complejidad mínima, siempre y cuando estas cuenten con soporte para dichas aplicaciones (Android Auto, Android Tv, etc). En este caso se mantiene un único código base, con lo que la duplicidad/triplicidad/XXXdad de funcionalidades no existirá.

Sin embargo, ante desarrollos muy específicos para cuales no existen herramientas previamente creadas (plugins) en las plataformas híbridas, el tiempo de desarrollo aumenta considerablemente y en muchas ocasiones hay que contar con tiempo y esfuerzos de desarrolladores de aplicaciones nativas para realizar estas tareas adicionales.

6. Sencillez para mantener el código

En este punto la existencia de un código único para la aplicación base, a pesar de que puedan existir personalizaciones específicas para cada plataforma, da una clara ventaja a la aplicación híbrida. Esto nos permite simplificar las tareas de mantenimiento de código, refactorización de funcionalidades, procesos de pase a producción, etc.

7. Rendimiento de la aplicación

El hecho de que una aplicación híbrida corra sobre un entorno “virtual” hace que su rendimiento sea un poco menor por definición. Sin embargo hoy en día esto se minimiza el problema utilizando una UI formada por controles nativos configurados y posicionados mediante CSS y un SGML. Por lo tanta esta diferencia de rendimiento se ve minimizada. Actualmente hay aplicaciones que mueven una listas de cientos/miles de fotos a 60fps como una nativa… porque son nativas en ese sentido.

Sin embargo, como base se puede considerar que una aplicación nativa cuenta con un rendimiento superior y un menor consumo de recursos. Sobre todo si se realizan tareas pesadas como procesamiento gráfico a 60fps, movimiento de elementos 3D como un juego. En este caso dependemos directamente del sistema operativo y de la SDK nativa, que siempre será algo mejor.

También podría ser necesario acceder a elementos específicos del dispositivo como cámaras térmicas, lectores NFC industriales, etc. En este caso el desarrollo sobre aplicación nativa puede ser completamente necesario.

8. Look & Feel de la aplicación

Pese a haber múltiples librerías que imitan las guías de iOS y Android, se encuentran problemas de compatibilidad de CSS entre versiones de Android y sus navegadores así como en ciertas versiones de UIWebView de iOS. Por norma general, no es complicado darle un Look & Feel nativo a una app híbrida siempre y cuando se mantenga la compatibilidad con versiones modernas de las plataformas Android e iOS.

En el caso de las aplicaciones nativas, conseguir un Look & Feel idéntico entre plataformas es más complejo. Sin embargo, habitualmente se busca un término medio en el que se haga uso de los patrones a los que el usuario está acostumbrado y la adecuación de la aplicación al diseño gráfico, de UX y de UI aprobados por el cliente.

9. Capacidad para convivir nativo-híbrido

En ese caso ambas opciones son iguales. A día de hoy integrar partes nativas dentro de una aplicación híbrida y partes híbridas dentro de una aplicación nativa es sencillo.

10. Coste de desarrollo

Tal y como hemos mencionado en el primer punto sobre el time-to-market, el coste de los desarrollos híbridos multiplataforma será siempre inferior, ya que utilizamos la misma base de código en todas las plataformas, por ejemplo: iOS, Android, MacOS, Windows etc.

En las aplicaciones nativas, al tener que generar un código diferente para cada plataforma, los costes de desarrollo crecen de forma proporcional al número de plataformas en las que va a estar disponible la aplicación desarrollada.

Algunas conclusiones finales

Tal y como adelantamos en la presentación del documento, Irontec cuenta con equipos de desarrollo que pueden responder al proyecto tanto desde una aproximación tecnológica híbrida como nativa. Bajo esta premisa las conclusiones que se extraen a continuación pretenden ser una valoración subjetiva extraída únicamente de nuestra experiencia profesional y de las necesidades comunes que percibimos en muchos clientes (que no en todos 😉).

En nuestra opinión hay dos elementos clave que identificamos en casi todos los proyectos a los que nos enfrentamos: tiempo y dinero. Como explicamos a lo largo de este post, en el caso de las aplicaciones híbridas tanto el time-to-market (inicial y evolutivo), como los costes son menores, por lo tanto se presenta como una muy buena opción para el desarrollo de aplicaciones que no hagan uso de elementos como gráficos 3D, uso superintensivo de CPU o tengan una vinculación directa con elementos hardware como cámaras térmicas, lectores NFC industriales, etc.

En proyecto en los que se establece una estrategia centrada en el usuario, los aspectos relacionados con la experiencia de uso y look&feel son claves. En este aspecto, es cierto que todos recordamos algunas aplicaciones híbridas del pasado en el que el rendimiento era sensiblemente inferior (primeras versiones de Phonegap hicieron mucho daño a este tipo de aplicaciones). Sin embargo hoy en día la evolución de los sistemas híbridos produce aplicaciones con rendimientos casi similares a los nativos, con posibilidades de adaptar la apariencia de la aplicación a las necesidades más específicas, que permite reutilizar componentes del sistema de diseño establecido con mayor facilidad. Por ello, consideramos que una aplicación híbrida también es más aconsejable en este aspecto. Si que será importante analizar si existen todos los plugins que vamos a requerir en la plataforma híbrida que utilicemos, ya que en caso negativo, será necesario contar con un esfuerzo extra.

Un breve apunte para finalizar. Aunque esta comparativa analiza ambos enfoques desde un punto de vista generalista, existen multitud de excepciones y casos particulares. Por ejemplo podrías desarrollar una aplicación híbrida con personalizaciones muy grandes para cada plataforma que requieran códigos base diferentes. También podrías desarrollar una aplicación nativa con tecnología Xamarin que permite mantener un único código base con implementaciones específicas solo para la capa de frontend, etc. El caso es que como comentábamos al inicio de este artículo, cada proyecto requiere pensar en sus necesidades y particularidades 🙂

Esperamos que os haya ayudado a clarificar estos dos enfoques, pero si tenéis cualquier duda o discrepancia no dudéis en dejar un comentario abajo. Y por su puesto si necesitáis ayuda para hacer realidad vuestro proyecto tecnológico no dejéis de contactar con nosotros.