Desarrollo de aplicaciones móviles multiplataforma parte 1/3: web vs nativas vs multiplataforma

Escribiendo un post en el que pretendía analizar en profundidad las alternativas y herramientas al desarrollo de aplicaciones multiplataforma para móviles, me di cuenta de que estaba quedando demasiado largo y que nadie en su sano juicio lo leería. Así que he decidido dividirlo en tres partes con el fin de que se digerible. Esta es la primera, las otras mañana y pasado. Post relacionados:

Introducción

Hace ya algún tiempo que llevo queriendo meterme en profundidad en el desarrollo móvil. Pero hacer esto no significa tirar por la borda todos los años o experiencia que tengo en desarrollar aplicaciones web, sino ampliar el alcance de los nuevos proyectos haciendo que funcionen también en dispositivos móviles. Al fin y al cabo, muchas de estas aplicaciones usan servicios web y/o tienen un site en internet donde continuar usando la aplicación o servicio, así que programar para móviles no es dejar la programación web, ni mucho menos, sino hacer que ésta sea accesible por más usuarios. Puede incluso ser visto al revés: el desarrollo web complementa al desarrollo móvil, permitiendo que el usuario continúe usando su aplicación también en internet y no solo en su dispositivo.

Aplicaciones web vs aplicaciones nativas

Una de las principales ventajas de los smartphone es que todos tienen un navegador HTML5, por lo que podemos, simplemente, crear una aplicación web y usarla desde el navegador de uno de estos móviles. Esto tiene sus pros y sus contras:

Ventajas:

  • Fácil diseño: no hay que pensar en desarrollar una aplicación para móviles si no queremos. Basta con hacer un diseño adaptado a una pantalla y resolución más pequeñas -que puede ser simplemente adaptando un CSS por cada dispositivo- o podemos rediseñar la navegación al completo. Además, las aplicaciones web se pueden “tunear” para que parezcan aplicaciones nativas: icono de aplicación, pantalla completa, splash screen, barra de estado, etc. más info en este tutorial.
  • Fácil implementación: las aplicaciones web pueden ser desarrolladas en cualquier tecnología de servidor, así que podemos usar nuestro lenguaje favorito (Java, Grails, Php, Ruby, Python,…) con la seguridad de que la aplicación se verá igual en todos los terminales.
  • Seguridad: tu controlas el acceso a la aplicación y la puedes actualizar sin tener que pedir permiso. Nadie te va a “piratear” la versión premium de tu site, ni nadie ta va a vetar la entrada al App Store porque no cumple los requisitos.

Desventajas:

  • Apis nativas: no hay acceso completo a todas las Apis nativas del móvil. Aunque la cámara y el micro son accesibles con Flash, todos sabemos que esa tecnología está vetada en IOS. Desde HTML5 y Javascript, es posible acceder a las coordenadas del GPS, pero no en tiempo real ni de la misma manera que si pudiéramos acceder a la Api del móvil directamente. Y olvídate de usar el acelerómetro, la agenda, la brújula, etc.
  • Difícil de usar, fácil de olvidar: para usar una aplicación web en un móvil, es necesario que el usuario abra el navegador y teclee la dirección, ya sea porque la sepa, la haya encontrado en Google o la haya recibido por correo o chat. Una vez abierta la aplicación, debe añadirla a favoritos o, mejor todavía, crear un icono de acceso directo en el móvil para acceder a ella más tarde. Confiar en que nuestros posibles usuarios acaben haciendo todo esto para poder acceder cómodamente a nuestra aplicación en futuras ocasiones es pecar de ingenuo. Es mucho más fácil descargar una aplicación y que aparezca directamente como un icono en nuestro móvil.
  • Lenta: sin contar que renderizar HTML e interpretar Javascript es sin duda más costoso que ejecutar una aplicación nativa, cada petición que hagamos en nuestra aplicación implicará una recarga de la página o un acceso, en mayor o menor medida, contra nuestro servidor. Cualquier espera por pequeña que sea impacta en la experiencia de usuario. Una aplicación nativa tiene todos los recursos y procesos guardados en local, y solo accede al servidor para obtener o enviar datos si es que los necesita. Por tanto, una aplicación web no tiene la fluidez y velocidad de manejo que una aplicación nativa, ni nunca la tendrá.
  • Peor monetización: es más fácil que un usuario pague por nuestros servicios si simplemente cobramos X por nuestra aplicación al descargarla del App Store, que no hacer que el usuario se tenga que registrar y efectuar el pago en nuestra web, introduciendo manualmente todos sus datos como el número tarjeta, dirección, etc. Si el usuario ya tiene sus datos guardados en el App Store, para comprarla solo tiene que poner su password y confirmar la compra. Más fácil imposible.

Y no soy el único que piensa así, tenemos que ser conscientes de que los mercados de aplicaciones son una realidad: Apple tiene su App Store para IOS y MacOS, Google su Chrome Web StoreGoogle Apps Marketplace y el Android Market, Amazon su Amazon Appstore, incluso hay markets alternativos como OpenAppMkt. Cada vez más empresas invierten en crear un entorno fácil y cómodo para que el usuario pueda descargar, probar y comprar aplicaciones, repartiéndose los beneficios. Pensar que podemos competir con todo esto con una aplicación web para móviles, que simplemente se puede acceder desde una dirección en un navegador, es una ilusión.

Desarrollando aplicaciones móviles

Cada plataforma tiene su propio lenguaje, herramientas de desarrollo y Apis con los que crear aplicaciones. Para el post, vamos a comentar solo las más importantes: IOS y Android. Demos un breve repaso a cada uno de ellas.

IOS

El lenguaje oficial para IOS es Objective-C, y con este lenguaje podemos crear aplicaciones para Iphone, Ipad y Ipod touch. Hay distintas versiones de IOS pero todas ellas se programan usando el mismo lenguaje, Objective-C, y la misma herramienta, Xcode.

Xcode es el entorno de desarrollo oficial de Apple. Con él, podemos crear aplicaciones de escritorio para Mac y para IOS. Aunque podemos compilar las aplicaciones “a mano”, es una tarea casi imposible y siempre se recomienda Xcode para, por lo menos, empaquetar y subir la aplicación al App Store. La mayoría de alternativas para crear aplicaciones en Iphone (Appcelerator, Phonegap, Corona) se apoyan siempre en esta herramienta para hacer el build final, aunque no todas (Flex no lo necesita).

El único “problema” que tiene es que solo existe para Mac, por lo que para crear aplicaciones IOS te hace falta un ordenador marca Apple. Y esto no siempre es posible, claro (aunque se puede remediar con virtualización). Sobre el precio, ahora es gratis pero hasta hace poco costaba 5€ en la App Store. No es caro y tampoco es un drama tener que comprarlo.

Requisito importante: para distribuir aplicaciones en el App Store y para poder probar las aplicaciones desarrolladas en nuestro propio Iphone/Ipad, es necesario adquirir una licencia de desarrollador que cuesta 79€ al año.

Android

Para Android todo es mucho más fácil. Primero tenemos el lenguaje Java para programar aplicaciones y un SDK multiplataforma que funciona en Windows, Linux y Mac. Que Java es más fácil de aprender y programar que Objective-C -y que C en general- debido a su simplicidad es un hecho (sobre si es mejor o peor, ahí no voy a entrar a discutir, cada uno tendrá su propia opinión). Si queremos un entorno de desarrollo, podemos usar un plugin ADT para Eclipse que incluye un simulador, que también es multiplataforma, libre y gratuito, aunque me consta que hay más. Y no tenemos que pagar ninguna licencia anual.

Desarrollo móvil multiplataforma

En resumen: para hacer aplicaciones IOS nos hace falta un Mac con Xcode, una licencia de desarrollador y hay un lenguaje Objective-C con una sintaxis un tanto complicada de escribir y de leer. Y para hacer aplicaciones Android, no nos hace falta ningún sistema operativo en particular: usamos Java con Eclipse+plugin ADT o el propio SDK de Android que son multiplataforma y no hay licencias que pagar.

Sobre el hecho de que hay más aplicaciones de pago en el App Store que en el Android Market, o si es mejor publicar tu aplicación en un sitio o en otro, etc, no diré nada. Ya hay unos cuantos artículos interesantes sobre ello. Yo lo que ahora me planteo es:

  • ¿Qué pasa si no tenemos un Mac y queremos desarrollar aplicaciones para IOS?
  • ¿Qué sucede si Objective-C nos parece complicado y no queremos aprenderlo?
  • O lo contrario ¿que sucede si sabemos Objective-C y no nos gusta Java?
  • Y la más importante ¿qué ocurre si queremos hacer una aplicación para los dos dispositivos y no queremos programarla dos veces?

Personalmente, creo que todas las preguntas tienen fácil respuesta: “te compras un Mac o virtualizas un Mac OS con VirtualBox” o “te aguantas y aprendes Java/Objective-C”. Pero a la última pregunta no hay respuesta válida posible: si quieres una aplicación para IOS y Android, tienes que programarla dos veces. Oh, espera un momento, quizá haya una alternativa a todas estas preguntas…

La solución es conseguir una herramienta “write once, run everywhere”. Un software con el que sea posible programar con un lenguaje determinado y que, además, permita que tu aplicación funcione en varios dispositivos. Tras una inspección exhaustiva en internet, esto es lo que he encontrado:

  • Flex 4 y Adobe Air Mobile, la única herramienta que permite construir aplicaciones Android y IOS sin tener un Mac ni Xcode. Y se programa en ActionScript.
  • PhoneGap, Titanium Appcelerator y Anscana Corona, que nos permiten construir aplicaciones usando otros lenguajes como Javascript y Lua, aunque requieren Mac y Xcode.

Y me he decidido a probarlas. Las he descargado todas, me he hecho una aplicación de ejemplo con cada uno de ellas y la he intentado instalar el Ipad y el Iphone que tengo en casa (no tengo móvil Android). Y estas han sido mis conclusiones…

Fin de la parte 1/3. Continúa en Desarrollo de aplicaciones móviles multiplataforma: PhoneGap y Titanium Appcelerator.

18 thoughts on “Desarrollo de aplicaciones móviles multiplataforma parte 1/3: web vs nativas vs multiplataforma

  1. Sinceramente creo que no te has tomado el tiempo suficiente de análisis para realizar afirmaciones como:
    – cada petición que hagamos en nuestra aplicación implicará una recarga de la página o un acceso ¿conoces AJAX?
    – para usar una aplicación web en un móvil, es necesario que el usuario abra el navegador y teclee la dirección ¿sabes lo que es instalar una web-app en el movil? ¿sabes que tienes METAs para ello?
    – Peor monetización ¿sabes que se puede meter una web-app en cualquier store?
    – Por no decir que la especificación W3C va a llevar todo eso que dices que no tienen las web-apps: acceso a camara, contactos, osciloscopio… etc

    Este mensaje es constructivo y nunca destructivo, pero sinceramente creo que no te has metido a “pilon” con el desarrollo de WebApps.

  2. Hola Javi, gracias por el comentario.
    Conozco Ajax, y sigue es una petición al servidor que pasa por internet y así que sigue teniendo un coste.
    Sobre la instalación de webapps, si te lees bien esa parte del post, veras que solo digo que el usuario tiene que acceder usando la dirección *la primera vez* y luego tenemos que confiar en el usuario para que la instale como acceso directo o la añada a favoritos. Incluso pongo un enlace a un sitio donde explica como hacerlo con un video. Solo digo que, para el usuario, ese sistema es mas enfarragoso que descargar la aplicación desde el App Store.
    No se como se puede subir una web-app al App Store, de hecho, no entiendo muy bien como es posible ¿subes un enlace y te lo descargas? ¿o subes una aplicación con PhoneGap?
    Supongo que la especificación de W3C traerá muchas cosas en el futuro, pero estoy hablando de alternativas y soluciones reales que se pueden hacer hoy en día, ahora mismo.

    Bueno, cada uno ve las ventajas e inconvenientes según sus propios criterios, y en este artículo yo he puesto mi opinión. Gracias por la tuya, aunque sería más interesante si la acompañaras con enlaces e información adicional, podría añadidos al post. Un saludo!

  3. Javi, supongo que te refieres a esto: http://www.apple.com/webapps/whatarewebapps.html
    La verdad es que no lo conocía y me parece una idea muy interesante, aunque no veo como aprovechar el App Store para monetizar las aplicaciones. ¿Se pueden comprar o hay que usar un formulario de registro dentro de cada web-app para introducir los datos de la tarjeta?
    He modificado el post y añadido como ventaja en la parte facil diseño, el tuneado de webapps para que parezcan aplicaciones nativas con los meta.

  4. Un post muy interesante, hacía falta que alguien se metiera este trabajo y nos lo contase a los demás, creo que es una duda que tenemos muchos ;)

    Un saludo

  5. iOS también admite C y C++ pero el interfaz está hecho en Objective-C (UIKit framework). Las aplicaciones con gráficos OpenGL y motores en C, C++ se portan rapidamente, pero aprender UIKit no es tarea trivial.

    iOS 5 tiene ARC (http://clang.llvm.org/docs/AutomaticReferenceCounting.html) y no es necesario gestionar la memoria manualmente. Supongo que pensabas en eso al comparar la dificultad de Java y Objective-C.

    Al usar estos frameworks multiplataforma hay que tener en cuenta que tu inversión en aprendizaje depende de la suerte de sus respectivos fabricantes, es toda una apuesta.

  6. La dificultad de Objective-C frente a Java es la sintaxis principalmente (llamadas de métodos, punteros) y la cantidad de código que hay que escribir para hacer casi cualquier cosa. Pero es la opinión de alguien que lleva con Java mucho tiempo (yo). Para alguien que llevo mucho con C, C++ u Objective-C, será Java lo que le parezca raro y con una sintaxis caprichosa.

    Lo de la suerte de los respectivos fabricantes tienes muchísima razón, y es una de los factores que hay que tener en cuenta a la hora de decantarse por una herramienta u otra. Al fin y al cabo, es el precio que hay que pagar por no usar las herramientas “oficiales”, pero pasa lo mismo en cualquier tecnología (fíjate en Flash por ejemplo: de ser el rey de la web a estar en vías de extinción, aunque sobre esto, tengo mis dudas y opinión personal tambien, confío en Adobe… :)

  7. Mmmmm,

    Interesante artículo pero me faltan muchas cosas. Y me da que la primera es la experiencia. Lo cual no hace de menos el valor de tus opiniones.

    1. Te has dejado fuera los RIM (Blackberry) y los Windows Phone (en España casi no existe pero se están vendiendo como churros).

    2. Son mercados diferentes las WebApp y las nativas. Es como comparar una aplicación Web con una aplicación de escritorio. Tienen objetivos y mercados diferentes.

    3. Acabo de terminar una WebApp, que ya es impresionante cómo va en los smartphone y las Blackberry, y ahora estamos migrando a jQuery Mobile… pruebalo.

    En mi opinión personal y basada en mi última experiencia, las WebApp serán para los móviles lo que la Web ha sido para el escritorio.

  8. Un detalle es que para hacer una aplicación Android competitiva, es bastante complicada hacer la en Java, salvo tema de determinados programas de gestión. Cada vez más la punta de velocidad del código nativo C, algo C++ es casi indispensable…

    Saludos

  9. Alberto, los verdaderos machos desarrollan para Android en Scala :) Por lo visto es posible y lo soporta maven-android-plugin.

  10. Nosotros en Android el tema de las webapp lo hemos metido dentro de un webcontainer como wrapper y capandolo, para no poder acceder a otra ruta pej, lo hemos subido como aplicación al Android Market

  11. Hi, I am discovering those articles thanks to the mistake you did with the RSS feeds … and I’m glad you did ! Nice articles !

    Actually, there is another alternative if you come from the .NET/Mono world. You can use “MonoTouch” and “Mono for Android” to develop applications for iDevices and Android devices in C#. (it is not free, though, and I haven’t tried it…). They claim you can reuse most fo your code between the platforms. See http://xamarin.com/

Comments are closed.