El debate sobre las apps para dispositivos móviles
Introducción
Las apps para dispositivos móviles y HTML5 son dos de las tecnologías más populares en este momento, y hay mucha superposición. Las apps web se ejecutan en navegadores para dispositivos móviles y también se pueden volver a empaquetar como apps nativas en las diversas plataformas para dispositivos móviles. Con la amplia variedad de plataformas compatibles, combinada con la gran potencia de los navegadores para dispositivos móviles, los desarrolladores recurren a HTML5 como una solución de "escribir una vez, ejecutar en muchos lugares". ¿Pero es realmente viable? Aún existen motivos convincentes para usar apps nativas y, claramente, muchos desarrolladores están tomando ese camino. Este artículo es un debate sobre las apps nativas en comparación con la Web.
Riqueza de funciones
Argumento: Las apps nativas 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. Por ejemplo, en Android, serían funciones como widgets y notificaciones. Las apps nativas se destacan en ambas dimensiones.
En cuanto a la experiencia de la app, las apps nativas pueden hacer más. Pueden obtener fácilmente eventos de deslizamiento, incluso multitáctiles, para las plataformas que lo admiten. Por lo general, pueden actuar cuando se presionan teclas físicas, 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. Con el permiso del usuario, algunas plataformas proporcionan acceso sin restricciones al sistema operativo. Intenta 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 formas 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. Y tienes intents, que permiten que tu app se anuncie como un servicio general que otras apps podrían requerir en ocasiones.
Contraargumento: Las funciones nativas se pueden aumentar, y la Web se está poniendo al día
Es cierto que muchas funciones integradas en la app están fuera del alcance de una app HTML5. No importa qué tan buenas sean tus habilidades de web-fu, si tu app está atascada en un entorno de pruebas sin una API de cámara, no tomará fotos pronto. Afortunadamente, no tienes que estar en ese entorno de pruebas. Si realmente necesitas que tu app web tome una foto, puedes crear una aplicación 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 mediante una API de redes estándar. Cuando compilas una app híbrida como esta, también puedes conectarte a esas funciones de la plataforma, como widgets, notificaciones y intents.
Crear una app híbrida (nativa y web) no es una solución ideal. Agrega complejidad y solo se aplica a las apps web empaquetadas como apps nativas, en lugar de 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 modernos para dispositivos móviles siguen el ritmo. Por ejemplo, el almacenamiento sin conexión, la geolocalización, los gráficos de lienzo y la reproducción de video o audio disfrutan de una amplia compatibilidad entre los smartphones modernos. Incluso la cámara comienza a ser compatible. A partir de Android 3.1, es posible capturar fotos y videos con estándares web. Además, el navegador más reciente de iOS admite WebSocket para la transmisión bidireccional, así como 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 rápido. Solo entre los navegadores para computadoras, hay cinco proveedores principales de navegadores que evolucionan los estándares y agregan funciones a la velocidad de la luz. Si bien no es un proceso trivial para transferir estas funciones a dispositivos móviles, muchas de ellas ya llegaron a los navegadores para dispositivos móviles.
Las apps nativas son un objetivo en movimiento rápido, pero la Web está cerrando la brecha.
Rendimiento
Argumento: Las apps nativas se ejecutan más rápido
Las apps nativas no tienen la barrera del entorno de ejecución web. Se ejecutan cerca del hardware y pueden aprovechar los potenciadores de rendimiento, como la aceleración de GPU y el subprocesamiento múltiple.
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 la velocidad de todos modos
Sería una subestimación decir que la Web se volvió más rápida en los últimos años. V8, el motor de JavaScript que se incluye con Chrome, fue un desarrollo importante en el rendimiento web cuando se lanzó y, desde entonces, solo se volvió más rápido:
Los motores de renderización de gráficos también aceleraron la Web, y ahora comienza a producirse la aceleración de hardware. Echa un vistazo al aumento de velocidad que proporciona el lienzo acelerado por hardware:
Además, la nueva API de Web Workers hace posible el subprocesamiento múltiple, y los desarrolladores web modernos también pueden recurrir a una variedad de bibliotecas optimizadas para el rendimiento y técnicas de optimización de rendimiento bien investigadas. Si bien la mayoría de ellas comenzaron en la Web para computadoras, siguen siendo relevantes para dispositivos móviles, y se presta más atención a los dispositivos móviles. Por ejemplo, el gurú de rendimiento Steve Souders tiene una página dedicada a las herramientas de rendimiento para dispositivos móviles.
Aún no todos los avances para computadoras llegaron a todas las plataformas para dispositivos 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 3D de vanguardia, sino que se basan fundamentalmente en la información: noticias, correo, horarios, redes sociales, etcétera. Visita algunos sitios desde tu dispositivo móvil, por ejemplo, Gmail, Amazon, Twitter, y podrás confirmar que el rendimiento de la Web móvil es más que adecuado. En cuanto a los juegos, los básicos ya son factibles con el lienzo 2D, y WebGL comienza a aparecer en dispositivos móviles. Consulta Firefox 4. Hasta que se generalice, existe una familia creciente de frameworks que compilan apps WebGL en apps nativas que pueden aprovechar OpenGL, por ejemplo, ImpactJS.
Experiencia de los desarrolladores
Argumento: Las apps nativas son más fáciles de desarrollar
Las apps nativas usan lenguajes de programación sólidos (p.ej., Java, Objective C, C++) que se diseñaron para el desarrollo de aplicaciones complejas y tienen un historial comprobado. Las APIs se diseñaron desde cero para admitir la plataforma en cuestión. Puedes depurar apps fácilmente en emuladores de computadoras que proporcionan una representación cercana del dispositivo de destino.
Lo que hace que el desarrollo web sea particularmente problemático es la gran diversidad de navegadores y entornos de ejecución. Cuando se ejecuta tu app, no se garantiza que la función X esté disponible. Incluso si lo está, ¿cómo la implementará el navegador? Los estándares están abiertos a la interpretación.
Contraargumento: La Web suele ser más fácil de desarrollar, en especial si se orienta a varios dispositivos
Primero, abordemos la tecnología principal. Es cierto que los estándares web se concibieron originalmente en una época en la que la Web se trataba fundamentalmente de documentos, no de apps, con JavaScript compilado e implementado en solo 10 días. Sin embargo, resultaron ser mucho más capaces de lo que se imaginaba. Los desarrolladores web aprendieron a aprovechar las partes buenas y a domar las partes malas, con patrones que ahora se comprenden para el diseño escalable. Además, los estándares no se detienen, y los esfuerzos como HTML5, CSS3 y EcmaScript Harmony mejoran la experiencia de los desarrolladores. Si prefieres C++, Java o JavaScript es una cuestión de debate religioso y también depende de tu base de código heredada. Sin embargo, sin duda podemos incluir JavaScript como un competidor serio en la actualidad.
La otra cara de la fragmentación del navegador o del entorno de ejecución es el hecho de que todos estos entornos existen en primer lugar. Desarrolla una app para Android en Java y te enfrentarás a una transferencia completa a Objective C para admitir iOS. Desarrolla una app web una vez y se ejecutará en Android y iOS, sin mencionar WebOS, BlackBerry, Windows Mobile y… bueno, esa es la teoría de todos modos. En la práctica, deberás ajustar las cosas para cada plataforma si realmente quieres obtener la experiencia correcta. Sin embargo, también tendrías que hacerlo en forma nativa para la mayoría de los sistemas operativos para dispositivos móviles, ya que hay diferentes versiones y dispositivos.
La buena noticia es que la "fragmentación" siempre fue así en la Web, y existen técnicas conocidas para abordarla. Lo más importante es que el principio de mejora progresiva insta a los desarrolladores a orientar primero a un dispositivo básico y agregar capas de excelencia específicas de la plataforma cuando estén disponibles. El mantra de la detección de funciones también ayuda y, en la actualidad, tenemos compatibilidad con bibliotecas de Modernizr para admitir el diseño web responsivo. Con un uso juicioso de estas técnicas, puedes expandir tu alcance a la gran mayoría de los dispositivos, incluso los "teléfonos con funciones" de la vieja escuela, incluso factores de forma como relojes y TVs, independientemente de la marca y el SO. Observa nuestra demostración de IU múltiple en Google I/O 2011, en la que segmentamos factores de forma distintos (teléfono con funciones, smartphone, tablet, computadora, TV) con una base de código común de lógica y lenguaje de marcado.
Aspecto
Argumento: Las apps nativas se ajustan al aspecto de la plataforma
Una de las características definitorias de cualquier plataforma es su aspecto. Los usuarios esperan que los controles se presenten de manera coherente y se manipulen de la misma manera. Existen ciertos modismos que varían de una plataforma a otra, por ejemplo, ¿qué sucede cuando el usuario realiza una "presión prolongada" (mantener presionado un elemento durante varios segundos)? Las plataformas tienen modismos estándar para este tipo de cosas, y no puedes satisfacerlas todas con una sola app HTML5.
Además, el aspecto de la plataforma está orquestado por la biblioteca de software nativa de la plataforma, cuyos widgets encapsulan el tipo de aspecto que esperan los usuarios. Obtienes gran parte del aspecto esperado "de forma gratuita" con solo usar el kit de herramientas nativo.
Contraargumento: La Web tiene su propio aspecto, 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 de desarrollo web es escribir una versión básica "de talla única" y, luego, mejorarla de forma progresiva. Si bien la mejora suele basarse en funciones, también puedes mejorarla segmentando las plataformas que más te interesan. Este es un tipo de "detección de navegador", que a veces la comunidad web desaprueba, principalmente porque hay muchos navegadores posibles. Sin embargo, si ves dos o tres plataformas con una prioridad muy alta y estás dispuesto a hacer un esfuerzo adicional para competir con las alternativas nativas, este puede ser el camino a seguir.
En cuanto a la versión de referencia, la Web tiene su propio aspecto, y podemos decir que cada plataforma para dispositivos móviles tiene su propio "aspecto web" establecido por el navegador predeterminado y el entorno de ejecución web. El "aspecto web" puede ser adecuado para tus usuarios y, de hecho, te permite lograr un mayor grado de coherencia con la experiencia de navegación en computadoras, así como en otros dispositivos con los que el usuario podría estar trabajando. Además, hay muchas apps exitosas que no admiten el aspecto nativo de todos modos. Esto es cierto en el caso de los juegos (¿tu juego favorito para dispositivos móviles sigue el aspecto de tu SO para dispositivos móviles?) e incluso en el caso de las apps más convencionales. Por ejemplo, consulta los clientes nativos de Twitter más populares en la plataforma que elijas y verás una amplia variedad de mecanismos de interfaz de usuario en funcionamiento.
Visibilidad
Argumento: Las apps nativas son más fáciles de descubrir
Los mecanismos de distribución de apps, como Market de Android y App Store de Apple, fueron muy populares en los últimos años y son una fuerza impulsora importante para toda la industria de dispositivos móviles. Cualquier desarrollador puede enviar su app nativa al marketplace, donde los usuarios pueden descubrirla a través de una combinación de navegación, búsqueda y recomendaciones. Además, si hiciste bien tu trabajo, las calificaciones y los comentarios brillantes convencerán a los usuarios de presionar el botón de instalación, que es muy importante.
Contraargumento: En realidad, las apps web son más fáciles de descubrir
Se podría decir que la Web es el medio más visible que se haya creado. En la humilde URL, tenemos (al menos en teoría) un identificador único para todo lo que se publicó en la Web, lo que incluye cualquier app publicada en sitios web estándar. Los motores de búsqueda facilitan el descubrimiento de ese contenido, y otros sitios web pueden vincularse a él, incluidos los catálogos de apps web similares a los marketplaces para 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. También se pueden enviar vínculos por SMS, donde los usuarios de dispositivos móviles podrán hacer clic en el vínculo y abrir la app en el navegador de su dispositivo.
Aún no tenemos los mismos marketplaces en los que los usuarios pueden calificar y comentar las apps, pero eso también está cambiando. Sigue leyendo…
Monetización
Argumento: Las apps nativas se pueden monetizar
"Un niño de 6 años crea una app durante la hora del almuerzo y vende un millón de copias a USD 3 cada una". Ves mucho ese titular en estos días, por lo que no es de extrañar que los desarrolladores grandes y pequeños busquen los marketplaces para dispositivos móviles para la monetización. Las plataformas para dispositivos móviles ofrecen varias vías para que los desarrolladores cobren directamente por sus apps. La más simple es el pago único para desbloquear la app para siempre. También se ofrecen mecanismos de pago y suscripción integrados en la app en algunas plataformas, y están integrados de forma segura y coherente. Estas formas de pago más recientes permiten a los desarrolladores convertir una app exitosa en una fuente de ingresos a largo plazo.
Además de los pagos de apps, puedes monetizar con modelos web tradicionales, como la publicidad y el patrocinio.
Contraargumento: Siempre fue posible monetizar en la Web, y las oportunidades están creciendo
La Web no sería el motor de la industria moderna si no hubiera muchas oportunidades para obtener ganancias. Aunque los mecanismos directos de "pago por uso" aún no florecieron, existen varios nichos en los que las soluciones de "software como servicio" basadas en suscripciones se volvieron viables. Entre los ejemplos, se incluyen Google Apps, la gama de productos de 37Signals y las 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. Existen la publicidad en línea, los vínculos de afiliados, los patrocinios y la promoción cruzada a otros productos y servicios.
Dicho esto, es perfectamente razonable que un desarrollador web lea los titulares y experimente un poco de envidia por los pagos. No puedes enviar una URL web a los marketplaces nativos, así que ¿qué debe hacer un desarrollador web? Lo que haces es crear una "aplicación contenedora" nativa. Para cada plataforma a la que quieras orientarte, crea una aplicación nativa vacía que solo contenga una vista web. La vista web es donde incorporas la app real. Luego, solo debes enviar estas apps a los distintos marketplaces (y, con suerte, ver cómo ingresa el dinero). Probablemente haya cientos, si no miles, de apps con tecnología web en los marketplaces principales en la actualidad, algunas de ellas tan astutamente asimiladas que ni siquiera conocemos sus apps web.
La desventaja es la obligación de realizar una compilación cruzada para cada plataforma. Aquí es donde puede ayudar un framework existente como PhoneGap. Aún mejor, existen servicios web como PhoneGap Build y Apparatio en desarrollo. Dirige estos sitios web a tu repositorio de código y aparecerá una app para Android, una app para iOS, etcétera, lista para que la envíes a las tiendas correspondientes. No es necesario instalar SDKs nativos en tu máquina. Todo lo que necesitas para compilar todas estas apps nativas es un editor de código y un navegador web.
¿Alguna vez los marketplaces admitirán apps web directamente, sin toda la sobrecarga de empaquetarlas de forma nativa? Aún no está claro. Sabemos que Google presentó Chrome Web Store el año pasado y, aunque solo se aplica a las computadoras, la tienda despertó el interés de otros proveedores de navegadores y, en general, forma parte de una tendencia hacia los catálogos de apps web, incluidos algunos intentos específicos para dispositivos móviles. El concepto de una tienda web se encuentra en sus primeras etapas, pero los signos 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 las 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 llegue un momento en que las tecnologías web sean un ciudadano de primera clase en la mayoría de los SO para dispositivos móviles, las apps nativas siempre serán una consideración importante.
Una técnica que se menciona en este artículo son las apps híbridas, y esta puede ser la mejor solución para algunos desarrolladores: vista web cuando sea posible y componentes nativos específicos de la plataforma cuando no lo sea.
Si eliges la ruta web, ten en cuenta los estándares web y el principio de mejora progresiva. La Web es una tecnología que sabe cómo segmentar las multitudes de dispositivos y sistemas operativos que existen. Ya sea que elijas llamarla "fragmentación" o "diversidad", la Web la adopta y los desarrolladores pueden beneficiarse de todo el arte anterior que existe.