¿Aplicaciones web o aplicaciones nativas?

No es la primera vez que hablamos de aplicaciones web o nativas y las ventajas de unas sobre las otras. Actualmente, como ya hemos visto, romper la barrera entre ambos campos es más fácil con herramientas como Titanium, de Appcelerator (el curso que nosotros tenemos de aplicaciones móviles), PhoneGap o, en campos más avanzados, Ionic. Estos entornos de desarrollo tienen la ventaja de que dar el paso de un lado a otro es relativamente fácil. Relativamente porqué no debemos olvidar que debe haber cierta habilidad de nuestra parte a la hora de programar y estructurar el proyecto, como también vemos en el curso.

Pero entonces, si el paso de una categoría a otra es tan “sencillo”, ¿de qué sirve en la actualidad plantearnos si tirar en una dirección u otra? La respuesta es sencilla. No siempre tenemos los recursos físicos o económicos para hacer una app nativa, o la sencillez del proyecto no requiere la dificultad de la segunda opción. Vamos a ver cual es el panorama actual en esto.

Aplicaciones nativas vs aplicaciones web

Si bien es cierto que las aplicaciones nativas son más estables que las web, en las segundas podemos encontrar ciertas ventajas que para iniciar el proyecto nos puede venir de maravilla. Los tiempos han cambiado y en la actualidad hay muchos recursos para hacer aplicaciones con lenguajes 100% web, como JavaScript, HTML5 o editar estilos con CSS. De hecho, otras plataformas han adoptado esta característica haciendo de la sintaxis algo propio. ¿Qué significa esto?

Por ejemplo, Android Studio de Google utiliza una hoja de estilos en XML para que, de manera sencilla, podamos editar el aspecto de nuestra aplicación. Hasta la fecha, esto lo hacíamos con “pico y pala”: con el lenguaje nativo, si queríamos hacer una marquesina, primero debíamos declarar una caja para que seguidamente en las propiedades designáramos el color, tamaño, etc. Pero esas propiedades sólo servían para ése elemento, no se compartían.

Si observamos CSS, su magia es la capacidad de crear una hoja de estilos general, para todos los elementos, y luego asignar clases más concretas para objetos específicos. En vista de que esto era lo más óptimo, y el crecimiento del uso de los smartphones y las tabletas, los desarrolladores decidieron que era lógico trasladar dicha facilidad a la programación de aplicaciones, y lo cierto es que fue lo más sensato. Esto dio pie al nacimiento de las aplicaciones web, programas que, si bien no aprovechan del todo los recursos físicos de nuestro teléfono, eran capaces de generar una página que se visualizaba correctamente en todas las plataformas. Podías visitarla desde el PC o desde el teléfono que siempre se pintaba todo en pantalla como tocaba (recordad que en el PC la pantalla es horizontal mientras que en el teléfono, por lo general, vertical). Pero seguimos hablando del pasado.

¿Cuál es la realidad actual? ¿Alguna vez habéis entrado en Google maps y os ha pedido que compartáis vuestra ubicación? Las aplicaciones web cada vez son más capaces de comunicarse con vuestro dispositivo y esto está creando una evolución en la que, poco a poco, la barrera entre las apps web y nativas se cierra. Aquí es donde entra el papel de los entornos híbridos. Para que me entendáis, cojamos la plataforma de Apple como ejemplo, iOS. Necesitamos su paquete de desarrollo, Xcode, para poder hacer apps, y si queremos entrar en el mundo nativo, usaremos ObjectiveC o Swift. Si no los conocéis, como todo lenguaje al principio, deberéis pasar por una fase de aprendizaje, y os podéis preguntar “Sería maravilloso poder hacer una app en iOS con mis conocimientos de lenguajes web…”. Y por eso nacieron dichos entornos híbridos. Aunque al principio algo arcaicos, en la actualidad son tan potentes como uno que se dedique únicamente a la programación nativa, y por eso han ganado tanta popularidad.

Una vez más insisto en que nada será tan óptimo como un lenguaje nativo, pero cuando el tiempo va a contrarreloj, se agradece mucho que con un sólo código podamos compilar en distintas plataformas, y este es el otro punto a tener en cuenta de todo esto.

Multicompilación

Antes he dicho que dar el paso del campo de las aplicaciones web a las nativas es muy sencillo pero no os he dicho por qué. Esto es gracias a que disponemos de la posibilidad de compilar en varias plataformas. “¿Por qué si mi aplicación se ve bien en todas las plataformas debo hacerla de nuevo para añadir alguna función sólo presente en el teléfono?” como puede pasar en el caso del acelerómetro. Sería perder tiempo, ¿no? Es mejor coger toda la base que ya os habéis creado y definir que cuando entres con el teléfono, te de las funciones restantes, y una vez lo tienes, generar la aplicación en las plataformas que deseáis publicar: Android, iOS, Windows Phone. Incluso Blackberry, el eterno olvidado en combate.

Mi conclusión a todo esto es que ya no hay un factor determinante a la hora de decidir si hacer una aplicación nativa o una web. Debemos cogerlo como algo escalar, empezar con lo más sencillo (web) para finalmente evolucionar a la más compleja (nativa), ya que, gracias a esto, podemos tener listo un producto e ir mejorando poco a poco hasta llegar a las expectativas que teníamos al inicio del proyecto. Quiero dejar también escrito que todas estas palabras son aplicables a las aplicaciones por lo general. Los juegos si que necesitan un tratamiento más cercano, pese a haber motores que gozan de multicompilación. Pero, como todos sabemos, un juego ya es una estructura mucho más compleja que una aplicación, y es algo que, sin haber programado jamás, no debemos meternos de cabeza de buenas a primeras, mas bien ir creciendo como desarrolladores e ir alcanzando nuestro objetivos poco a poco.

¿Conocíais todos estos aspectos? Como podéis ver, el panorama actual de las apps web o nativas ha cambiado mucho, y desde luego tenemos muchas posibilidades en nuestras manos a diferencia de hace 3 o 4 años atrás.

Curso relacionado: Curso de Desarrollo de Aplicaciones Móviles