Desarrollo de aplicaciones móviles multiplataforma

Con este artículo pretendo recoger mi punto de vista, resumiendo lo que he comentado en mis charlas sobre estas temáticas y también las conclusiones tras invertir casi dos años en investigar sobre cómo afrontar este tipo de desarrollos y proyectos.

Desde hace ya unos años, cuando desarrollamos proyectos web de gran envergadura como plataformas SaaS (software como servicio), marketplaces, redes sociales o portales de otro tipo, debemos tener en cuenta la experiencia del usuario que accede a estos servicios web desde el móvil.

Desde el punto de vista del cliente, las preocupaciones u objetivos que más destacan en su feedback suelen ser estos tres:

  • El servicio debe ser accesible desde el móvil
  • Nuestro servicio debe poder ser consumido desde un canal móvil
  • Nuestro servicio debe tener una buena experiencia desde el móvil

Hasta ahora, los desarrolladores web contábamos con la ventaja de poder desarrollar nuestra plataforma y mantenerla de forma centralizada en nuestros servidores, preocupándonos únicamente en la parte frontal de los detalles o soportes de diferentes navegadores.

Habíamos huido del trabajo que suponía el mantener y dar soporte a instalaciones de nuestro software en distintos entornos o sistemas operativos que controlaba el cliente. Esta sensación que creíamos olvidada, ha retornado con la revolución de las aplicaciones móviles que suponen una oportunidad para los negocios que construimos: la oportunidad de estar en el bolsillo del cliente vaya donde vaya.

Los usuarios pueden acceder a nuestro servicio mientras van en el metro o consumen los últimos minutos del día antes de dormir.

Sin embargo, aprovechar esta oportunidad, aumenta el coste del desarrollo y de su posterior mantenimiento ya que supone desarrollar una aplicación para cada uno de los sistemas implantados en los teléfonos disponibles, teniendo en cuenta versiones del sistema y la experiencia de uso.

Por lo tanto, un desarrollador web o un equipo de desarrollo web tiene que tener en cuenta:

Las cosas que no son programación

Aunque un desarrollador delegue la parte de definición del producto o el diseño de la interfaz, es imperativo ser consciente de que una aplicación móvil se utiliza de forma distinta a un sitio web y la arquitectura de información junto a la navegación deben cumplir las expectativas de un usuario.

La idea es que no se trata de que nuestra aplicación se “parezca” a una aplicación móvil sino de que lo sea y se comporte como tal.

Al margen del diseño, importan cosas como la estrategia de notificaciones, la cantidad de información a mostrar o pedir, el comportamiento táctil, las reducción de features a ofrecer en comparación a la plataforma web y sobre todo, las integraciones con el dispositivo móvil y las implicaciones del hacerlo (consumo de batería, tipo de conexiones a hardware externo etc.)

Lo que sí es programación

Y en lo referente a la programación, aquí debemos tomar decisiones importantes:

  • Si nuestra aplicación debe instalarse en el dispositivo o no
  • Si nuestra aplicación debe ser nativa o no
  • En el caso de que optemos por desarrollar en nativo, si utilizamos una solución multiplataforma o no
  • Si requerimos un acceso web
  • Si en la parte web de nuestro servicio tiene sentido ejecutar una aproximación responsive Mobile First o por el contrario ser Tablet First y crear una webapp

Voy a dar mi opinión sobre estos puntos comentando algunas de las herramientas que he probado empezando por el último punto.

Responsive sigue sin ser opcional pero el ‘mobile first’ es muy del 2011

A menos que tu servicio sea extremadamente simple, atacar una estrategia teniendo en cuenta la adaptación del diseño en la resolución móvil bajo mi punto de vista puede aportar mayor coste de desarrollo, diseño y mantenimiento sin llegar a cumplir las expectativas del usuario.

Hay excepciones, como los sitios web de contenido que no vayan a crecer en otros aspectos de negocio. Sin embargo, en una plataforma en la que tenemos mucha problemática de interacción, intentar llegar a la vista móvil a base de adaptar el diseño puede conllevar:

  • Aumentar el peso de la página. Normalmente la técnica principal a la hora de hacer responsive es ocultar o mostrar elementos del HTML en base a la resolución de la pantalla, por lo que si nuestra plataforma crece también crecerá la cantidad de código a servir que tiene implicaciones como el tiempo de carga del sitio web.
  • Aumentar la complejidad en el front. Si para evitar aumentar el peso, decidimos aplicar o crear soluciones de carga bajo demanda, estaremos aumentando la complejidad del código en el frontal que realmente no está aportando valor de negocio y encarece el mantenimiento.
  • Mezclar problemáticas de experiencia de usuario. En ambos casos, estamos mezclando dos experiencias de uso totalmente distintas e intentando resolverlas prácticamente con calzador en el peor de los casos o intentando “parecer una aplicación móvil” en el mejor de ellos.

En mi opinión, si la plataforma es grande y planea crecer en requisitos de interfaz ya no es opcional el crear un acceso móvil separado con su propia experiencia de usuario.

Crear una webapp mobile

Como he comentado anteriormente, cuando atacamos el problema de desarrollar una aplicación móvil, aunque sea basada en web, tenemos que aprender a enfocar el diseño del servicio de una forma totalmente distinta a como lo platearíamos para una solución web en otras resoluciones y sobre todo, si estamos hablando de pantallas no táctiles.

En algunos servicios como Facebook, Badoo o Soundcloud tenemos buenos ejemplos de webapps.

IMG_0645Aunque el desarrollo sea web, no nos libramos de comprender cómo funciona cada plataforma, qué tipo de menús e interacciones el usuario espera encontrar y qué herramientas tiene el navegador para dotar a nuestra aplicación web de navegador de un comportamiento nativo.

Por ejemplo en iOS podemos hacer uso de los Smart Banners, las Safari notifications que permite enviar notificaciones al móvil aunque no este el navegador abierto o mejorar el rendimiento del scroll con un sencillo hack de CSS.

Para afrontar este tipo de desarrollos podemos optar por utilizar algún framework que nos facilite la tarea que ya implementan algunas de estos hacks a nivel de CSS.

Existen buenas opciones, algunas incluso adaptan el diseño dependiendo de la plataforma con la cual se acceda. Entre las más utilizadas están ionic, onsen uichocolat chip ui, ratchet y app.js.

Personalmente echo en falta una opción que no implemente javascript y sea una solución potente a nivel de css y html compatible con navegadores que no tengan que ser los más modernos.

Crear una aplicación instalable híbrida

Si queremos instalar nuestra aplicación en el dispositivo móvil la opción más socorrida por desarrolladores con experiencia web es la utilizar tecnologías como Phonegap/Cordova.

Básicamente estas aplicaciones se desarrollan de forma similar a una aplicación web móvil de navegador pero teniendo acceso a recursos del sistema como los sensores, cámara y almacenamiento.

Aunque parece la solución perfecta ya que el desarrollador puede aprovechar su experiencia en desarrollo web para ser productivo y crear aplicaciones con muy poca curva de aprendizaje inicial, disponemos de limitaciones con respecto a las aplicaciones nativas.

Al ser desarrolladas en HTML/CSS/Javascript es menos costoso también lograr implementar diseños con cierta complejidad o incluso imposibles de realizar en una aplicación nativa.

Simplificando mucho, una aplicación híbrida no es más una web en HTML y programación en javascript que funciona dentro de un navegador que el usuario no ve.

Sin embargo, si queremos realizar operaciones pesadas con el móvil (procesar video, componer música, mover mapas con gran cantidad de información) el rendimiento puede verse comprometido o incluso no poder hacerse con HTML o Javascript, teniendo que crear algún plugin nativo para cada una de las plataformas.

Normalmente, prácticamente el 90% de las aplicaciones que se desarrollan para un servicio online no requieren realizar tareas tan pesadas y una aplicación híbrida puede reducir mucho el coste de desarrollo.

Crear una aplicación instalable nativa

Esta es la opción que nos permite aprovechar todo el potencial del hardware del usuario.

Tenemos dos opciones cuando afrontamos un desarrollo de este tipo: desarrollar una aplicación por cada una de las plataformas (android, iOS, windows phone..) o utilizar una solución que nos quite el mayor trabajo posible de mantenimiento en cada una de ellas.

Hay que tener en cuenta que aunque desarrollemos para una plataforma en concreto podemos tener versiones que no tengan nada que ver. Por ejemplo en Android, una versión 3 difiere en tantas cosas de una versión 4 que podríamos tener que plantearnos tratar esas versiones como dos plataformas distintas y dos apps distintas. Es un problema que no afecta sólo a aplicaciones nativas sino también a webapps híbridas o incluso de navegador.

Si optamos por una solución que nos permita compartir código entre plataformas, las opciones más visibles en la actualidad son Appcelerator Titanium y Xamarin, la opción que más he investigado.

En mi caso descarté Titanium en favor de Xamarin porque todo el conocimiento que adquiría con la herramienta me ataba a ella. La forma de trabajar en Titanium no se parece ni se puede llevar al desarrollo de la plataforma en concreto.

Esto es especialmente importante en la parte de las vistas ya que sin lugar a dudas, la implementación del diseño es la parte más costosa en un desarrollo móvil nativo. En Xamarin puedes copiar y pegar todo el trabajo realizado en las vistas de una aplicación Android a una aplicación Xamarin.Android y funciona sin tocar absolutamente nada. Esto para mí significa no perder ni dinero ni conocimiento en el caso de que la herramienta en un futuro cambie de rumbo o desaparezca.

Otro punto en contra de Titanium es que aunque el código del framework es nativo, el código de tu aplicación en javascript es interpretado, perdiendo rendimiento en comparación al desarrollo nativo de cada plataforma o el desarrollo con Xamarin.

Xamarin tiene muchas más ventajas adicionales, por ejemplo se comprometen a dar soporte en el mismo día de las nuevas funcionalidades que salgan en las actualizaciones de los sistemas operativos soportados. También disponen de un framework (Xamarin.Forms) para construir vistas convencionales con una sola base de código.

Aunque no todo es maravilloso ya que tanto el IDE Xamarin Studio y las extensiones para Visual Studio deben mejorar muchísimo todavía. Tampoco te libra de conocer las particularidades de cada plataforma pero sí que te evita tener que dominar lenguajes específicos permitiendo centrarte en c#

Aunque sea de pago, merece mucho la pena evaluar el desarrollo con esta herramienta, sobre todo si no quieres mantener desarrollos en tecnologías distintas o tener en tu equipo desarrolladores especializados en cada lenguaje concreto de cada plataforma.

Conclusión

El camino para desarrollar aplicaciones móviles viniendo del desarrollo web, que es naturalmente multiplataforma, no es para nada trivial.

No sólo requiere que tomemos decisiones en cuanto a herramientas a utilizar para crearlas sino también pensar en su posterior mantenimiento.

También debemos cambiar la forma en la que diseñamos nuestros servicios para tener en cuenta las expectativas de nuestros usuarios fuera de su portátil o equipo de sobremesa.

7 comentarios en “Desarrollo de aplicaciones móviles multiplataforma”

  1. Muy interesante Asier. Creo que el Appcelerator Titanium tendría ventaja en el caso de desarrolladores que no conozcan C#, ya que usa Javascript y es común que desarrolladores web lo conozcan. En mi caso he usado PhoneGap y Titanium, y sin duda he disfrutado mucho el desarrollo usando Titanium con su MVC Alloy. En cuanto al rendimiento, creo que en la mayoría de las apps no se debe haber gran impacto por el hecho de que el código final no sea 100% nativo… de hecho creo que va a cambiar esto en las próximas versiones con la introducción de Hyperloop. Sin duda el hecho de poder reutilizar las vistas de Xamarin en proyectos nativos puede significar una ventaja, aunque pienso que al final el ‘core’ de la app está en C# y en caso de que la plataforma dejara de existir no habría una gran ventaja en poder reutilizar solo las vistas; en mi caso práctico con el Titanium compartí más del 70% de las vistas para Android / iOS lo que considero una ventaja. Ciertamente te atas a la plataforma, pero creo que de forma general pasa mucho, por ejemplo si desarrollas una aplicación web usando Symfony, también sucede igual.

    Sin duda el Xamarin como IDE se ve mucho mas potente que el Titanium.

    1. Gracias por comentar!

      Titanium es una gran herramienta, pero el motivo de que no optase por ella para aproximaciones nativas es el que comento: el ligarme a su forma de funcionar.
      Bajo mi experiencia, implementar un diseño complejo en un app nativa es de lejos lo más costoso. Si puedo delegar esta parte en profesionales que tengan más soltura que yo, con Xamarin puedo hacerlo sin que esas personas sepan Xamarin.

      Por otro lado el soporte es brutal en Xamarin, lo pagas eso sí, pero es muy bueno desde mi experiencia.

      C# es otra opción para mí genial. Desarrollo en Javascript, pero hay cosas en C# que son muy potentes o elegantes y no las tengo en JS.

      Lo dicho, respeto mucho Titanium, pero prefiero Xamarin.

      Un saludo!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *