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 aplicaciones nativas en las distintas plataformas para dispositivos móviles. Con la amplia gama de plataformas que se deben admitir, 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 muchas". Pero ¿es realmente viable? Aún hay motivos de peso para optar por el desarrollo nativo y, claramente, muchos desarrolladores están eligiendo esa opción. Este artículo es un debate sobre las apps nativas frente a la Web.
Variedad de funciones
Punto: El desarrollo nativo puede hacer más
Podemos dividir la funcionalidad móvil en dos dimensiones: la experiencia de la app en sí y la forma en que se conecta con el ecosistema del dispositivo, p.ej., en Android, esto incluiría funciones como widgets y notificaciones. Los anuncios nativos se destacan en ambas dimensiones.
En términos de experiencia en la app, las aplicaciones nativas pueden hacer más. Pueden captar fácilmente eventos de deslizamiento, incluso de 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. Y, 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 proveedora de un servicio general que otras apps podrían requerir en ocasiones.
Contraargumento: Las funciones nativas se pueden mejorar y, de todos modos, la Web se está poniendo al día
Es cierto que muchas funciones de la app están fuera del alcance de una app HTML5. No importa qué tan buenas sean tus habilidades de desarrollo web, si tu app está atrapada en una zona de pruebas sin una API de cámara, no podrá tomar fotos. Por suerte, no tienes que estar en esa zona 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 las funciones nativas como servicios web, a los que la vista web llama con una API de red estándar. Cuando creas una app híbrida como esta, también puedes conectarte a esas funciones de la plataforma, como widgets, notificaciones e 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 aplicaciones nativas, en lugar de los sitios web tradicionales a los que se accede desde un navegador para dispositivos móviles. Pero es posible que no sea necesario por mucho tiempo. Los estándares web evolucionan con rapidez, 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 video y audio tienen una amplia compatibilidad con los smartphones modernos. Incluso la cámara está empezando a ser compatible: a partir de Android 3.1, es posible capturar fotos y videos con estándares web. Además, el navegador de iOS más reciente 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. Sin embargo, la Web también está evolucionando, y rápido. Solo entre los navegadores para computadoras, hay cinco proveedores principales de navegadores que desarrollan estándares y agregan funciones a un ritmo vertiginoso. Si bien no es un proceso trivial portar estas funciones a dispositivos móviles, muchas de ellas ya se incorporaron a los navegadores para dispositivos móviles.
Las apps nativas son un objetivo que se mueve rápido, pero la Web está cerrando la brecha.
Rendimiento
Punto: El código nativo se ejecuta más rápido
Las aplicaciones nativas no tienen que lidiar con la barrera del entorno de ejecución web. Se ejecutan cerca del metal 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, de todos modos, la mayoría de las apps no necesitan la velocidad
Sería un eufemismo 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 está comenzando a producirse la aceleración de hardware. Observa el aumento de velocidad que proporciona el lienzo con aceleración de hardware:
Además, la nueva API de Web Workers permite el uso de varios subprocesos, y los desarrolladores web modernos también pueden recurrir a una variedad de bibliotecas con rendimiento optimizado y técnicas de optimización del rendimiento bien investigadas. Si bien la mayoría de ellos se crearon para la Web para computadoras, siguen siendo relevantes para los dispositivos móviles, y se presta cada vez más atención a estos dispositivos. Por ejemplo, el gurú del rendimiento Steve Souders tiene una página dedicada a las herramientas de rendimiento para dispositivos móviles.
No todos los avances de las computadoras de escritorio llegaron aún 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 información: noticias, correo, horarios, redes sociales, etc. Visita algunos sitios desde tu dispositivo móvil, p.ej., Gmail, Amazon, Twitter, y podrás confirmar que el rendimiento de la Web en dispositivos móviles es más que adecuado. En cuanto a los juegos, los básicos ya son factibles con el lienzo 2D, y WebGL está empezando a aparecer en los dispositivos móviles (consulta Firefox 4). Hasta que se generalice, hay una familia cada vez mayor de frameworks que compilan apps de WebGL en aplicaciones nativas que pueden aprovechar OpenGL, p.ej., ImpactJS.
Experiencia de los desarrolladores
Punto: El desarrollo nativo es más fácil
Las aplicaciones 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 una trayectoria comprobada. Las APIs se diseñaron desde cero para admitir la plataforma en cuestión. Puedes depurar apps fácilmente 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 gran diversidad de navegadores y entornos de ejecución. Cuando se ejecuta tu app, no se garantiza 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, 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 malas, con patrones que ahora se entienden para el diseño escalable. Además, los estándares no se detienen, y las iniciativas como HTML5, CSS3 y EcmaScript Harmony mejoran la experiencia de los desarrolladores. La preferencia por C++, Java o JavaScript es un tema de debate religioso y también depende de tu base de código heredada. Sin embargo, hoy en día, sin duda podemos incluir a JavaScript como un competidor serio.
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. Si desarrollas una app para Android en Java, deberás realizar una portabilidad completa 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, esa es la teoría. En la práctica, deberás ajustar algunos aspectos para cada plataforma si realmente quieres que la experiencia sea la adecuada. Pero también tendrías que hacerlo en la versión nativa para la mayoría de los sistemas operativos móviles, ya que hay diferentes versiones y dispositivos.
La buena noticia es que la "fragmentación" siempre ha sido 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 apuntar primero a un dispositivo básico y agregar capas de funciones increíbles específicas de la plataforma donde estén disponibles. El mantra de la detección de funciones también ayuda y, en la actualidad, contamos con la asistencia de bibliotecas como Modernizr para admitir el diseño web responsivo. Si usas estas técnicas con prudencia, puedes ampliar tu alcance a la gran mayoría de los dispositivos, incluso a los "teléfonos de gama media" de la vieja escuela, incluso a factores de forma como relojes y TVs, independientemente de la marca y el SO. Mira nuestra demostración de IU múltiple en Google I/O 2011, en la que nos enfocamos en distintos factores de forma (teléfono de gama media, smartphone, tablet, computadora de escritorio y TV) con una base de código común de lógica y lenguaje de marcado.
Apariencia y estilo
Punto: El anuncio nativo se adapta al diseño de la plataforma
Una de las características que definen cualquier plataforma es su aspecto. Los usuarios esperan que los controles se presenten de forma coherente y se manipulen de la misma manera. Hay ciertos idiomas que varían de una plataforma a otra, p.ej., ¿qué sucede cuando el usuario realiza una "presión prolongada" (mantiene presionado un elemento durante varios segundos)? Las plataformas tienen lenguajes estándar para esos elementos, y no puedes satisfacerlos todos con una sola app HTML5.
Además, la biblioteca de software nativa de la plataforma organiza el aspecto 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 interesen.
Como se explicó en la sección anterior, la forma de 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 las plataformas que más te interesan. Este es un tipo de "detección de navegador", que a veces no es bien visto por la comunidad web, principalmente porque hay muchos navegadores posibles. Sin embargo, si consideras que dos o tres plataformas tienen una prioridad muy alta y estás dispuesto a hacer un esfuerzo adicional para competir con las alternativas nativas, esta puede ser la opción ideal.
En cuanto a la versión de referencia, la Web tiene su propio aspecto, y hasta 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. Es posible que el "aspecto web" sea 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 con las de otros dispositivos con los que el usuario podría estar trabajando. Además, hay muchas apps exitosas que no admiten mucho el aspecto nativo de todos modos. Esto es, sin duda, cierto en el caso de los juegos (¿tu juego para dispositivos móviles favorito sigue el aspecto del SO para dispositivos móviles?) y, también, en el caso de las apps más convencionales, p.ej., 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
Punto: Las aplicaciones nativas son más fáciles de descubrir
Los mecanismos de distribución de apps, como Android Market y App Store de Apple, han sido muy populares en los últimos años y son un motor importante para toda la industria de los dispositivos móviles. Cualquier desarrollador puede enviar su aplicación nativa al mercado, donde los usuarios pueden descubrirla a través de una combinación de navegación, búsqueda y obtención de recomendaciones. Además, si hiciste bien tu trabajo, las calificaciones y los comentarios positivos convencerán a los usuarios de que presionen el botón de instalación, que es lo más importante.
Contraargumento: En realidad, las apps web son más fáciles de descubrir
Podría decirse que la Web es el medio más detectable que se haya creado. En la humilde URL, tenemos (al menos, en teoría) un identificador único para todo lo que se publica 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 mercados 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. Los vínculos también se pueden enviar 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 mercados en los que los usuarios pueden calificar y comentar sobre las apps, pero eso también está cambiando. Sigue leyendo…
Monetización
Punto: El contenido nativo se puede monetizar
"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". Ese titular se ve mucho hoy en día, por lo que no es de extrañar que los desarrolladores grandes y pequeños busquen los mercados móviles para la monetización. Las plataformas para dispositivos móviles ofrecen varias formas para que los desarrolladores cobren directamente por sus apps. La más sencilla es el pago único para desbloquear la app para siempre. En algunas plataformas, también se ofrecen mecanismos de pago y suscripción integrados en la aplicación, que se integran de forma estrecha en un mecanismo coherente y seguro. Estas formas de pago más recientes permiten que los desarrolladores conviertan una app exitosa en un flujo de ingresos a largo plazo.
Además de los pagos en la app, puedes monetizar con modelos web tradicionales, como la publicidad y el patrocinio.
Contrapunto: Siempre ha sido 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 amplias oportunidades para ganar dinero. Aunque los mecanismos directos de "pago por uso" aún no han prosperado, existen varios nichos en los que las soluciones de "software como servicio" basadas en suscripciones se han vuelto viables. Algunos ejemplos son las apps de Google, 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 con las apps web. Hay publicidad en línea, vínculos de afiliados, patrocinios, promoción cruzada de otros productos y servicios.
Dicho esto, es perfectamente razonable que un desarrollador web lea los titulares y sienta un poco de envidia por los pagos. No puedes enviar una URL web a los mercados nativos, por lo que un desarrollador web debe hacer lo siguiente: Lo que debes hacer es crear una "aplicación wrapper" nativa: para cada plataforma a la que quieras orientar tus anuncios, crea una aplicación nativa vacía que solo contenga una vista web. La vista web es donde incorporas la app real. Luego, solo envías estas apps a los distintos mercados (y, con suerte, verás cómo entra el dinero). Es probable que, en la actualidad, haya cientos, si no miles, de apps web en los principales mercados, algunas de ellas tan bien asimiladas que ni siquiera sabemos que son apps web.
La desventaja es la carga de compilar de forma cruzada para cada plataforma. Aquí es donde un framework existente como PhoneGap puede ayudar. Mejor aún, hay 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., listas para que las envíes a las tiendas correspondientes. No es necesario instalar SDKs nativos en tu máquina. Todo lo que necesitabas para compilar todas estas aplicaciones nativas era un editor de código y un navegador web.
¿Los mercados admitirán alguna vez las 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 computadoras de escritorio, 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 tienda web se encuentra en su etapa inicial, pero los indicios 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 plataformas nativas y otras, para la Web. Podría decirse 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 están moviendo rápido. Y, a menos que llegue un momento en el que las tecnologías web sean un ciudadano de primera clase en la mayoría de los SO para dispositivos móviles, el desarrollo nativo siempre será 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 donde sea posible y componentes nativos específicos de la plataforma donde 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 orientarse a la gran cantidad de dispositivos y sistemas operativos que existen. Ya sea que elijas llamarlo "fragmentación" o "diversidad", la Web lo adopta, y los desarrolladores pueden beneficiarse de todo el conocimiento anterior que existe.