42. ¿Cuándo hacer una aplicación nativa y cuándo una híbrida?

En el episodio de hoy vamos a hablar de un tema que ya hemos tocado en otro episodio anterior. Sin embargo esta vez lo vamos a tratar desde un punto de vista menos técnico y que lo pueda entender todo el mundo. El objetivo es que, sin un conocimiento técnico, puedas decidir qué te conviene más, si un desarrollo nativo o un desarrollo híbrido.

Para poder evitar tecnicismos y con el fin de que sea sencillo de entender, vamos a comparar el desarrollo nativo e híbrido de aplicaciones con la presentación de una idea de negocio ante inversores. Sí, seguramente no tenga mucho que ver en un principio, pero a medida que avancemos el episodio veremos que guardan cierta relación.

Bien, empecemos posicionando ambas situaciones. En primer lugar el tema que nos ocupa, crear una aplicación móvil. Nosotros tenemos la intención de crear una aplicación móvil para, obviamente móviles.

En nuestra comparación tendríamos que vamos a explicar una idea de negocio ante inversores. El hecho de crear una aplicación móvil sería la explicación de la idea de negocio, y el destinatario de la acción los móviles, serían los inversores.

Ahora bien, resulta que cuando nosotros vamos a crear una aplicación móvil, realmente no estamos creando una aplicación móvil para el concepto “móviles”. Sino que la estamos creando para dispositivos.

Lo mismo pasa con el explicar una idea de negocio. No estamos explicando una idea de negocio a inversores, sino que al fin y al cabo la estamos explicando a personas. Nuevo término a la comparación, móviles igual inversores, dispositivos igual personas.

Pues bien, resulta que al igual que no todas las personas hablan los mismos idiomas, no todos los dispositivos hablan el mismo idioma, o mejor dicho y para ser más técnicamente correcto, no todos los dispositivos móviles funcionan con el mismo sistema operativo. Otro término a la lista, idioma igual a sistema operativo.

Y esto nos lleva a la siguiente corrección. Cuando queremos crear una aplicación para móviles, realmente no queremos crear una aplicación para móviles. Lo que queremos es crear una aplicación para uno o varios sistemas operativos móviles.

Aquí tenemos que añadirle un componente más a nuestra comparación y para ello nos vamos a imaginar que en nuestro grupo de inversores hay gente que habla distintos idiomas. Pues bien, nosotros no vamos a explicar nuestra idea a los inversores, sino que vamos a querer explicar nuestra idea en uno o varios idiomas a estas personas.

Así que, lo que hemos descubierto hasta ahora es que realmente no hay un único proceso para crear una aplicación móvil que pueda funcionar en todos los dispositivos que hay hoy en día. Sino que tendremos que desarrollar nuestra app para cada sistema operativo que exista, en el caso de que queramos estar en todos.

Dicho de forma rápida, a día de hoy existen dos grandes sistemas operativos, iOS y Android. iOS es el sistema de Apple y que viene instalado en todos los modelos de iPhones y iPads. Android es el sistema que utilizan la otra gran mayoría de dispositivos, da igual la marca, Samsung, HTC, BQ, Huawei entre otros, utilizan este sistema para funcionar. Actualmente la cuota aproximada de cada uno de ellos es de un 80-20 más o menos. 80% de los móviles son Android, 20% son iOS.

Lo cual se traduce a que si queremos crear nuestra app para todos los móviles tendremos que desarrollar nuestra app para Android y iOS. En el caso de que la creemos solo para Android podrá acceder a ella aproximadamente un 80% de la gente y en el caso de que elijamos iOS lo harán un 20%.

¿Qué es un desarrollo nativo?

Bien, la situación que estamos plantando ahora es la de un desarrollo nativo. ¿Qué es un desarrollo nativo?

Un desarrollo nativo consiste en programar, una aplicación para un sistema concreto. Esto quiere decir, que en el caso de crear una aplicación para Android y iOS, en primer lugar se va a crear una aplicación programada en un lenguaje de programación que entiende únicamente Android y otra versión programada en un lenguaje que solo entiende iOS.

Para dejarlo más claro. La versión de nuestra app que salga del desarrollo nativo de Android no funcionará para iOS. Y lo mismo pasará al revés con la versión de iOS. Tendremos una versión para Android y una versión para iOS.

Esto generalmente va a suponer que dos personas o dos equipos estén al cargo de la app. Por un lado la versión de Android y por otro la versión de iOS. Digo generalmente, porque la mayoría de programadores están especializados en uno u otro sistema. Pero también cabe la posibilidad de que algún programador se encargue de las dos versiones. Simplemente es más difícil encontrarlo.

¿Que es un desarrollo híbrido?

Vale, ahora tenemos situado el desarrollo nativo y entendemos de qué trata. Pero, ¿existe una alternativa a él? ¿Existe alguna manera de que un solo desarrollo, en un único lenguaje, la aplicación resultante pueda servir para ambos sistemas?

Sí, y en eso consisten a grandes rasgos las aplicaciones híbridas o desarrollos híbridos.

Lo que hay detrás de este desarrollo híbrido es algo complicado de explicar sin recurrir a tecnicismos y es algo en lo que en este capítulo quiero evitar caer. Para imaginarlo vamos a pensar en que se instala una especie de traductor entre la aplicación y el móvil. Mediante este traductor que vamos a utilizar podremos programar nuestra app en un solo lenguaje y en un solo desarrollo.

Nuestro traductor se va a encargar de traducirle al sistema operativo lo que tiene que hacer. ¿Qué quiere decir esto? Que ahora no necesitamos crear varias versiones de nuestra app para cada sistema en el que queramos estar. Simplemente desarrollando una sola versión, con este traductor que vamos a utilizar, podemos estar en todos los sistemas.

Esto implicará también que necesitemos menos gente para desarrollar el proyecto. Mejor dicho, no sé si menos gente, pero menos tiempo seguro. Una sola persona, o un solo equipo, puede desarrollar esa versión única, mientras que por el otro lado necesitábamos generalmente varias personas para hacer varias versiones.

Y por aquí ya se empiezan a ver los beneficios de la app híbrida. Menos recursos, menos personas, menos coste… Sin embargo no es oro todo lo que reluce. Ni lo bueno es tan bueno, ni lo malo es tan malo. Ambos desarrollos tienen sus pros y sus contras. Ambos desarrollos son perfectamente válidos. Todo depende de la situación y los objetivos de quién quiere desarrollar la app.

¿Aplicación nativa o aplicación híbrida?

Aunque podríamos hablar a nivel técnico de muchas diferencias entre uno y otro desarrollo, no vamos a entrar en eso. Vamos a simplificarlo lo máximo posible e intentar ver los dos desarrollos con sus dos grandes beneficios.

Para el desarrollo híbrido su gran punto fuerte es el coste. Cuando hablo de coste me refiero a tiempo, esfuerzo, recursos, dinero etc. Simplemente vamos a definirlo en una sola palabra, coste. Las aplicaciones híbridas tienen menos coste.

Por el otro lado, el punto fuerte del desarrollo nativo es la calidad. Lo mismo que decía antes. Cuando hablo de calidad me refiero a potencia, fiabilidad, rapidez y fluidez de la aplicación. Las aplicaciones nativas funcionan mejor, tienen más calidad que las híbridas.

Obviamente el punto fuerte de uno es el punto débil del otro. Una aplicación nativa tiene más calidad pero requiere un mayor coste. Una aplicación híbrida tiene menos coste y un poco menos de calidad.

Como digo, aquí siempre estoy generalizando todo. La calidad y el coste de cada desarrollo depende de muchísimas cosas más, pero como digo, quiero hacerlo lo más simple posible para entender estos dos conceptos.

El punto fuerte de la aplicación nativa

¿Por qué una aplicación nativa tiene más calidad o funciona mejor? Básicamente porque estamos programando esa aplicación específicamente para un solo sistema.

En el caso de que desarrollemos una app nativa para Android y iOS. Por un lado, al crear la versión de Android vamos a utilizar el lenguaje específico de Android. Por el otro, para la versión de iOS vamos a utilizar el lenguaje de iOS.

Sin embargo, cuando creamos una aplicación híbrida estamos desarrollando un solo proyecto que, como hemos dicho, tiene un pequeño traductor de por medio. No estamos hablando directamente al sistema sino que hay un intermediario.

En resumen y para entendernos, la comunicación es más fluida, más rápida, en las aplicaciones nativas. Esto hace que el resultado sea mejor. Es como la comunicación de las personas, lo cual nos lleva a recuperar nuestra comparación de la creación de aplicaciones con la explicación de una idea de negocio.

Imagina que tienes que explicar tu idea a dos personas, pero resulta que estas dos personas no hablan el mismo idioma. Una habla inglés y la otra Chino. Pues bien, puedes hacer dos cosas:

Una sería explicarle tú mismo cara a cara, uno a uno, toda tu idea en el idioma que entiendan. Primero la explicarías a la persona que habla inglés y luego a la que habla Chino. Podrás explicarles la idea de arriba a abajo y transmitirles todas tus ganas, toda tu emoción por el proyecto. Esta sería la vía del desarrollo nativo.

Por otro lado, podrías hacer otra cosa. Podrías coger a un traductor y que en vez de explicarles tú la idea, lo hiciera él. No perderías tanto tiempo en explicar la idea uno a uno. Simplemente se lo cuentas al traductor y éll se encarga de después contársela a todos. Tú únicamente habrás explicado la idea una vez. Este sería la vía híbrida.

¿Qué pasa?¿Quién va a tener más poder de convicción? ¿Quién va a poder transmitir más sobre el proyecto que tú mismo? Está claro, que, teóricamente, tú. Por lo tanto el resultado tendría que ser mejor si lo haces de forma nativa.

El punto fuerte de la aplicación híbrida

Retomando lo que contábamos en el punto anterior, si cuentas tú tu idea, estás invirtiendo el doble de tiempo y esfuerzo. Además estamos suponiendo que sabes los dos idiomas.

Si imaginamos que el traductor es gratuito, el coste que te supone el explicar tu idea a dos personas en su idioma es superior a que lo expliques una sola vez al traductor. En otras palabras, el desarrollo híbrido tienen un coste menor.

Alternativas intermedias

Sabiendo esto, hay que llegar a la siguiente conclusión. Si quieres crear una aplicación y quieres premiar por encima de todo la calidad de la misma por encima del presupuesto, haz un desarrollo nativo.

Si por otro lado lo que más te interesa es el presupuesto, porque tienes un límite, haz un desarrollo híbrido.

De todas formas, siempre cabe la posibilidad de que no se quiera todo negro o todo blanco. Quiero decir, que no tienes porque siempre preferir un extremo u otro. Calidad o presupuesto. Pues bien, las alternativas que se me ocurren que se podrían desarrollar serían tres:

Como siempre sabes que puedes escuchar y recomendar este podcast a través de las plataformas como iTunes y iVoox. También puedes contactar conmigo a través de mi formulario de contacto para cualquier duda, sugerencia o proyecto. ¡Nos escuchamos el miércoles que viene a las 8AM!