El debate sobre las aplicaciones para dispositivos móviles
Introducción
Las aplicaciones para dispositivos móviles y HTML5 son dos de las tecnologías más populares en este momento, y hay muchas superposiciones. Las apps web se ejecutan en navegadores para dispositivos móviles y también se pueden volver a empaquetar como apps nativas en varias plataformas móviles. Gracias a la amplia gama de plataformas que admiten, junto con la gran potencia de los navegadores para dispositivos móviles, los desarrolladores están recurriendo a HTML5 como una solución de "escribir una, ejecutar muchas". Pero, ¿es realmente viable? Todavía existen razones convincentes para adoptar la nativa y, sin dudas, muchos desarrolladores siguen ese camino. Este artículo es un debate sobre páginas nativas versus la Web.
Cantidad de atributos
Punto: Los nativos pueden hacer más
Podemos dividir la funcionalidad para dispositivos móviles en dos dimensiones: la experiencia de la app en sí y la forma en que se conecta al ecosistema del dispositivo; p.ej., para Android, serían funciones como widgets y notificaciones. Los anuncios nativos se destacan en ambas dimensiones.
En términos de experiencia con las apps, las apps nativas pueden hacer mucho más. Pueden obtener con facilidad eventos de deslizamiento, incluso mutlitouch, para las plataformas que lo admiten. Por lo general, funcionan cuando se presionan teclas rígidas, como el botón de búsqueda y los controles de volumen de Android. También pueden acceder al hardware, como el GPS y la cámara. Además, con el permiso del usuario, algunas plataformas proporcionan acceso ilimitado al sistema operativo. Solo tienes que intentar detectar cuánta batería queda con HTML5.
Sin embargo, es más que la experiencia en la app. Un sistema operativo como Android proporciona diferentes maneras para que las apps interactúen con los usuarios y, de hecho, con otras apps. Tienes widgets activos en la página principal. Tienes notificaciones que aparecen en la barra de estado del dispositivo. Además, tienes intents que permiten que tu app se anuncie como que proporciona un servicio general que otras apps podrían requerir en ocasiones.
Contraargumento: Las funciones nativas pueden aumentarse y la Web se está poniendo al día de todos modos.
Es cierto que muchas funciones de la app están fuera de su alcance en una app HTML5. No importa qué tan importantes sean tus habilidades para trabajar con la Web, si tu app está atrapada en una zona de pruebas sin una API de cámara, no tomará instantáneas en ningún momento. Afortunadamente, no tienes que estar en ese espacio aislado. Si realmente necesitas que tu app web tome una foto, puedes crear una app nativa, una con una vista web incorporada que proporcione la mayor parte de la interfaz de usuario. Así es como funciona el framework de código abierto PhoneGap: llena el vacío exponiendo funciones nativas como servicios web, a los que la vista web llama con una API de herramientas de redes estándar. Cuando compilas una app híbrida como esta, también puedes conectarte a esas funciones de la plataforma, como widgets, intents y notificaciones.
Crear una app híbrida (nativa, web) no es la solución ideal. Esto agrega complejidad y solo se aplica a las aplicaciones web unidas como aplicaciones nativas, en lugar de a los sitios web tradicionales a los que se accede desde un navegador para dispositivos móviles. Sin embargo, es posible que no sea necesario por mucho tiempo. Los estándares web evolucionan rápidamente, y los navegadores para dispositivos móviles modernos siguen el ritmo. Por ejemplo, el almacenamiento sin conexión, la ubicación geográfica, los gráficos de lienzo y la reproducción de audio y video gozan de una compatibilidad generalizada entre los smarpthones modernos. Incluso la cámara está empezando a ser compatible. A partir de Android 3.1, es posible capturar fotos y videos usando estándares web. Además, el navegador más reciente de iOS es compatible con WebSocket para la transmisión bidireccional y con la detección de la orientación del dispositivo.
En general, los dispositivos móviles están evolucionando. Pero la Web también está evolucionando y agilizando. Solo entre los navegadores de escritorio, hay cinco principales proveedores de navegadores que están desarrollando estándares y agregando funciones a un ritmo vertiginoso. Si bien la portabilidad de estas funciones a los dispositivos móviles no es un proceso sencillo, muchas de ellas ya se adaptaron a estos navegadores.
Los anuncios nativos son un objetivo dinámico, pero la Web está cerrando la brecha.
Rendimiento
Punto: Los anuncios nativos se ejecutan más rápido
Las apps nativas no deben lidiar con la barrera del tiempo de ejecución web. Se ejecutan muy cerca y pueden aprovechar los potenciadores de rendimiento, como la aceleración de GPU y los subprocesos múltiples.
Contraargumento: Los entornos de ejecución web son mucho más rápidos hoy en día, y la mayoría de las apps no necesitan esa velocidad.
Sería subestimar decir que la Web se ha vuelto más rápida en los últimos años. V8, el motor de JavaScript que se incluye en Chrome, fue un desarrollo importante del rendimiento web cuando se lanzó y, desde entonces, se volvió más rápido:
Los motores de renderización gráfica también aceleraron la Web, y ahora está comenzando a acelerarse el hardware. Observa el cambio de velocidad que proporciona el lienzo acelerado por hardware:
Además, la nueva API de Web Workers hace posible el multiprocesamiento, y los desarrolladores web modernos también pueden recurrir a una variedad de bibliotecas optimizadas para el rendimiento y a técnicas bien investigadas de optimización del rendimiento. Si bien la mayoría de ellos comenzaron a funcionar en la Web para computadoras de escritorio, siguen siendo relevantes para los dispositivos móviles, y se presta una mayor atención a los dispositivos móviles, p.ej., el gurú del rendimiento Steve Souders tiene una página dedicada a las herramientas de rendimiento para dispositivos móviles.
Aún no todos los avances en computadoras de escritorio llegaron a todas las plataformas móviles, pero las tendencias indican que están en camino. También es importante tener en cuenta que la mayoría de las apps para dispositivos móviles no son juegos en 3D de vanguardia, sino que se basan fundamentalmente en la información: noticias, correos electrónicos, horarios, redes sociales, etc. Visita algunos sitios desde tu dispositivo móvil, como Gmail, Amazon, Twitter y confirmas que el rendimiento de la Web móvil es más que adecuado. En cuanto a los juegos, los básicos ya son posibles con el lienzo 2D, y WebGL está comenzando a aparecer en los dispositivos móviles; consulta Firefox 4. Hasta que se generalice, existe una familia cada vez mayor de frameworks que compilan apps de WebGL en apps nativas que pueden aprovechar OpenGL, p.ej., ImpactJS.
Experiencia del desarrollador
Punto: Los anuncios nativos son más fáciles de desarrollar
Las apps nativas usan lenguajes de programación sólidos (p.ej., Java, Objective C y C++), que se diseñaron para el desarrollo de aplicaciones complejas y tienen una trayectoria comprobada. Las APIs se diseñaron desde cero para admitir la plataforma en cuestión. Puedes depurar fácilmente apps en emuladores de escritorio, que proporcionan una representación cercana del dispositivo de destino.
Lo que hace que el desarrollo web sea particularmente problemático es la enorme diversidad de navegadores y entornos de ejecución. Cuando se ejecuta la app, no hay garantía de que la función X esté disponible. Y aunque lo sea, ¿cómo lo implementará el navegador? Los estándares están abiertos a interpretación.
Contraargumento: La Web suele ser más fácil de desarrollar, especialmente si se orienta a varios dispositivos.
Abordemos primero la tecnología principal. Es cierto que los estándares web se concebieron originalmente en una era en la que la Web se basaba, en esencia, en documentos, no en apps, con JavaScript compilado e implementado en solo 10 días. Sin embargo, demostraron ser mucho más capaces de lo imaginable: los desarrolladores web aprendieron a aprovechar las partes buenas y a controlar las partes malas, con patrones que ahora se entienden para el diseño escalable. Además, los estándares no se mantienen, y todos los esfuerzos como HTML5, CSS3 y EcmaScript Harmony están mejorando la experiencia de los desarrolladores. Ya sea que prefieras C++, Java o JavaScript es una cuestión de debate religioso y también depende de tu base de código heredado. Pero, sin duda, podemos incluir JavaScript como un verdadero competidor en la actualidad.
La desventaja de la fragmentación del navegador y el entorno de ejecución es el hecho de que todos estos entornos existen en primer lugar. Si desarrollas una app para Android en Java, tendrás un puerto completo a Objective C para admitir iOS. Desarrolla una app web una vez y se ejecutará en Android y en iOS, sin mencionar WebOS, BlackBerry, Windows Mobile y... bueno, de todos modos, esa es la teoría. En la práctica, deberás hacer ajustes para cada plataforma si realmente quieres que la experiencia sea correcta. Sin embargo, también tendrías que hacerlo en formatos nativos, ya que existen diferentes versiones y dispositivos para la mayoría de los sistemas operativos móviles.
La buena noticia es que la "fragmentación" siempre ha sido así en la Web, y existen técnicas muy conocidas para lidiar con ella. Lo más importante es que el principio de mejora progresiva insta a los desarrolladores a que primero se orienten a un dispositivo básico y a que agreguen capas de genialidad específica de la plataforma donde esté disponible. El mantra de la detección de funciones también es útil y, en la actualidad, contamos con bibliotecas compatibles con bibliotecas como Modernizr para brindar compatibilidad con el diseño web responsivo. Con un uso sensato de estas técnicas, puedes expandir tu alcance a la gran mayoría de los dispositivos, incluso los "teléfonos de gama media" más antiguos, incluso a factores de forma, como relojes y TVs, independientemente de la marca y el SO. Mira nuestra demostración de varias IU en Google IO 2011, donde nos enfocamos en distintos factores de forma (teléfono de gama media, smartphone, tablet, computadora de escritorio, TV) con una base de código común de lógica y lenguaje de marcado.
Apariencia y estilo
Punto: Los anuncios nativos se adaptan al estilo de la plataforma.
Una de las características que definen a cualquier plataforma es su apariencia. Los usuarios esperan que los controles se presenten de manera coherente y se manejen de la misma manera. Hay ciertas expresiones idiomáticas que varían de una plataforma a otra, p.ej., ¿qué sucede cuando el usuario mantiene presionado un elemento durante varios segundos? Los formularios tienen expresiones idiomáticas estándar para esas cosas y no puedes satisfacerlas a todas con una sola app de HTML5.
Además, la biblioteca de software nativa de la plataforma organiza el aspecto de la plataforma, cuyos widgets encapsulan el tipo de apariencia que esperan los usuarios. Obtienes gran parte del aspecto esperado "sin costo" con solo usar el kit de herramientas nativo.
Contraargumento: La Web tiene su propio estilo, y también puedes personalizar la interfaz web para las plataformas que más te interesan.
Como se explicó en la sección anterior, la forma del desarrollo web es escribir una versión básica "universal" y, luego, mejorarla de forma progresiva. Si bien la mejora suele basarse en las funciones, también puedes mejorarla segmentando tus anuncios a las plataformas que más te interesen. Este es un tipo de "detección de navegadores", que a veces la comunidad web desaprueba, principalmente porque hay tantos navegadores posibles en el mercado. Sin embargo, si ves dos o tres plataformas con una prioridad muy alta y estás dispuesto a hacer el esfuerzo adicional para compararlas con las alternativas nativas, esta puede ser la mejor manera de hacerlo.
En lo que respecta a la versión de referencia, la Web tiene su propio aspecto, y hasta podemos decir que cada plataforma móvil tiene su propio "aspecto web" establecido por el navegador y el tiempo de ejecución web predeterminados. El "estilo web" puede ser adecuado para los usuarios y, de hecho, te permite lograr un mayor grado de coherencia con la experiencia de navegación en computadoras de escritorio, así como con la de otros dispositivos con los que el usuario podría estar trabajando. Además, hay muchas apps exitosas que, de todos modos, no admiten mucho la apariencia nativa. Esto es cierto en el caso de los juegos (¿tu juego para dispositivos móviles favorito sigue la apariencia de tu SO para dispositivos móviles?), y hasta de las apps más convencionales, p.ej., echa un vistazo a los clientes nativos de Twitter más populares de la plataforma que elijas y verás una amplia variedad de mecanismos de interfaz de usuario en funcionamiento.
Visibilidad
Punto: Las apps nativas son más fáciles de descubrir
Los mecanismos de distribución de apps, como Android Market y App Store de Apple, fueron abrumadoramente populares en los últimos años y son una gran fuerza impulsora para toda la industria móvil. Cualquier desarrollador puede enviar su app nativa al mercado, donde los usuarios pueden descubrirla mediante una combinación de navegación, búsqueda y obtención de recomendaciones. Además de eso, si hiciste bien tu trabajo, las calificaciones y los comentarios brillantes convencerán a los usuarios de presionar el botón de instalación tan importante.
Contraargumento: En realidad, las aplicaciones web son más fáciles de descubrir.
Se podría decir que la Web es el medio más visible que jamás se haya creado. En la URL modesta, tenemos (en teoría, al menos) un identificador único para todo lo que se publica en la Web, que incluye las apps publicadas en sitios web estándar. Los motores de búsqueda permiten descubrir fácilmente que el contenido y otros sitios web pueden vincularse a él, incluidos catálogos de aplicaciones web similares a los mercados de dispositivos móviles. De hecho, cualquier persona puede compartir apps web con sus amigos con solo vincularlas en correos electrónicos y mensajes de redes sociales. Los vínculos también se pueden enviar por SMS. Los usuarios de dispositivos móviles podrán hacer clic en el vínculo y, luego, iniciar la app en el navegador de su dispositivo.
Aún no tenemos los mismos mercados en los que los usuarios pueden calificar las apps y comentarlas, pero eso también está cambiando. Más información
Monetización
Punto: Los anuncios nativos pueden monetizarse.
"Un niño de 6 años crea una app durante la hora del almuerzo y vende millones de copias a USD 3 cada una". Hoy en día, ves ese título con frecuencia, por lo que no es de extrañar que los desarrolladores grandes y pequeños busquen la monetización en los mercados de dispositivos móviles. Las plataformas móviles ofrecen varias vías para que los desarrolladores cobren directamente por sus apps. El más simple es el pago único que desbloquea la app por toda la eternidad. También se ofrecen mecanismos de suscripción y pago integrado en la app en algunas plataformas, que están estrechamente integrados en un mecanismo coherente y seguro. Estas nuevas formas de pago permiten a los desarrolladores convertir una app exitosa en un flujo de ingresos a largo plazo.
Además de los pagos de apps, puedes monetizar con modelos web tradicionales, como publicidad y patrocinio.
Contraargumento: Siempre fue posible monetizar en la Web, y las oportunidades crecen.
La Web no sería el motor de la industria moderna si no hubiera muchas oportunidades para sacar provecho. Aunque los mecanismos directos de pago por uso aún no han florecido, existen varios nichos en los que las soluciones de "software como servicio" basadas en suscripciones se han vuelto viables. Algunos ejemplos incluyen Google Apps, la gama de productos de 37Signals y versiones premium de varios servicios de correo electrónico. Además, los pagos directos no son la única forma de obtener ganancias de las apps web. Puedes incluir publicidad en línea, vínculos de afiliados, patrocinios y promociones cruzadas a otros productos y servicios.
Dicho esto, es perfectamente razonable que un desarrollador web lea los títulos y experimente una pizca de envidia de pago. No puedes enviar una URL web a los mercados nativos. ¿Qué debe hacer un desarrollador web? Lo que debes hacer es crear una "app de wrapper" nativa: para cada plataforma a la que quieras orientar la campaña, crea una app nativa vacía que simplemente contenga una vista web. La vista web es el lugar donde incorporas la app real. Luego, solo debes enviarlas a varios mercados (y ver cómo se deposita el dinero). Es probable que haya cientos, si no miles, de apps web en los mercados principales de hoy en día. Algunas de ellas se asimilaron con tanta astucia que ni siquiera conocemos sus aplicaciones web.
La desventaja es la carga de realizar compilaciones cruzadas para cada plataforma. Aquí es donde un framework existente como PhoneGap puede ayudar. Y lo que es mejor, hay servicios web en desarrollo, como PhoneGap Build y Apparatio. Dirige estos sitios web a tu repositorio de código y muestra una app para Android, una app para iOS, etc., lista para que envíes a las tiendas correspondientes. No necesitas instalar SDK nativos en tu máquina; todo lo que necesitas para compilar todas estas apps nativas era un editor de código y un navegador web.
¿Los mercados admitirán alguna vez las apps web de forma directa, sin la sobrecarga de unirlas de forma nativa? Todavía no está del todo claro. Sabemos que Google presentó Chrome Web Store el año pasado y, aunque solo se aplica a las computadoras de escritorio, la tienda ha generado el interés de otros proveedores de navegadores y es, en general, parte de una tendencia hacia los catálogos de aplicaciones web, incluidos algunos intentos específicos para dispositivos móviles. Avanzamos en el concepto de tienda web, pero los letreros son prometedores.
Conclusiones
Sería bueno declarar un ganador aquí, pero en este momento no hay un ganador claro. Algunas apps son más adecuadas para apps nativas y otras para la Web. Se podría decir que la pila web tiene más impulso, pero en términos de capacidades y cualidades de ejecución, las apps nativas también se mueven rápido. A menos que en algún momento las tecnologías web sean una prioridad en la mayoría de los SO móviles, el uso nativo siempre será una consideración importante.
Una técnica que se menciona en este artículo es la de las apps híbridas, que podría ser la mejor opción para algunos desarrolladores: la vista web, donde es posible, y los componentes nativos específicos de la plataforma, cuando no lo son.
Si eliges la ruta web, ten en cuenta los estándares web y el principio de la mejora progresiva. La Web es una tecnología que sabe cómo orientarse a las multitudes de dispositivos y sistemas operativos. Ya sea que elijas llamarla "fragmentación" o "diversidad", la Web la acepta y los desarrolladores pueden beneficiarse de todo el arte anterior disponible.