¿Por qué debería crear una aplicación móvil dirigida a una plataforma específica en lugar de desarrollar un sitio web HTML5 móvil?

3 razones principales para ser nativo:

1) Rendimiento: especialmente para el juego. La memoria y la CPU en los dispositivos móviles deben estar profundamente optimizadas para aplicaciones exigentes, como los juegos, y Native SDK es la mejor herramienta para el trabajo.

2) Acceso al dispositivo: aunque HTML5 tiene más y más acceso al dispositivo, para el acceso completo al dispositivo, nativo es el único camino a seguir.

3) Expectativa del usuario: para bien o para mal, desde la era del iPhone, a los usuarios se les ha enseñado a “descargar” aplicaciones en sus dispositivos móviles. Espero que esta tendencia se desvanezca, pero por ahora, si quieres llegar a dispositivos móviles, tienes que jugar el juego.

Sin embargo, creo que para la mayoría de las aplicaciones HTML5 es suficiente y en realidad ofrece una gran portabilidad entre dispositivos (a pesar de algunas inconsistencias).

Además, es importante tener en cuenta que en los dispositivos Android e iOs, puede usar el componente nativo HTML5 en su aplicación, lo que le permite reducir significativamente el trabajo dependiente de la plataforma. Por lo tanto, puede desarrollar el front-end de su aplicación en HTML5, tenerlo accesible en la web móvil, pero también empaquetarlo como una aplicación nativa y ofrecer funcionalidades híbridas para resolver los requisitos anteriores # 2 y # 3.

Tendría que estar en desacuerdo con los respondedores que sugieren que puede crear una mejor experiencia de usuario con aplicaciones nativas que con el período HTML. Echa un vistazo a la aplicación The Bold Italic para iPad, que nosotros (Pivotal Labs) creamos como una envoltura nativa delgada alrededor de una aplicación HTML. Pregúntese si hubiera sabido que esto no era nativo.

A menos que esté creando juegos OpenGL o aprovechando características nativas que no están expuestas a través de webkit, existen argumentos sólidos a favor de una aplicación HTML.

En mi mente son:

Costo de desarrollo: para las empresas con un biudget limitado, será más rápido / más barato desarrollar una aplicación HTML para todas las plataformas móviles que una aplicación nativa para una plataforma, y ​​mucho menos varias. Además, aprovecha la infraestructura y la tecnología existentes si tiene un producto web.

Costo de cambio: al igual que con el desarrollo, el costo de cambiar una aplicación HTML es mucho menor. Esto es muy importante, particularmente para productos que se ajustan al mercado previo al producto. Necesitará iterar y la velocidad es importante.

Facilidad de adopción: es más fácil dirigir el tráfico de la web a la web móvil y es más barato comprar anuncios / usuarios en la web. Puede probar su caso de uso móvil aquí, crear una audiencia y, cuando presente una aplicación nativa, atraerá a toneladas de usuarios existentes a la vez, impulsando las listas y exponiéndola a nuevos usuarios. Dado que la mayoría de las aplicaciones reciben un montón de nuevos usuarios y se pierden en las tiendas de aplicaciones, esto es enorme.

Time to Market: no hace falta decir que cuando es más barato construir e iterar, puede sacar su producto rápidamente y adelantarse a la competencia.

Mercado direccionable: cuando iOS era más del 90% del mercado direccionable, esta decisión era mucho más fácil. Las proyecciones para 2011 ponen a Android e iOS en el 30% de cada rango, con 30% + más. Esto hace que elegir una plataforma nativa sea doloroso y lo deja muy abierto a los competidores que toman participación en el mercado. HTML está en todas partes.

Control: para la mayoría de los productos esto no es un problema, pero el control sobre el conjunto de funciones y su ciclo de lanzamiento es un beneficio de la web móvil. Carece de este control en la tienda de aplicaciones de Apple, menos aún con Android o webOS, aunque incluso no estar en la tienda de aplicaciones predeterminada es un gran problema.

Los casos en los que es posible que desee considerar una estrategia nativa desde el principio son:

Bienes virtuales / Compras en la aplicación: si depende de las compras de aplicaciones, tendrá un tiempo mucho más fácil con una aplicación nativa, al menos hoy y al menos en iOS (que es la única plataforma viable para bienes virtuales hoy).

Juegos: como se mencionó anteriormente, algunos tipos de juegos deben ser nativos.

Productos centrados en los medios: todavía no he visto una buena aplicación HTML orientada a videos / imágenes tomadas desde el dispositivo. Es posible construir uno bueno, pero es probable que el nativo todavía tenga una ventaja aquí

Productos solo para dispositivos móviles: si el suyo es un negocio móvil puro, es posible que no tenga la infraestructura / habilidades web existentes, o puede que los hombres sientan que son nativos para garantizar un control completo sobre la experiencia del usuario y aprovechar al máximo las características específicas de la plataforma.

Puede que me haya perdido uno o dos, siéntase libre de agregar otros en los comentarios.

Para las aplicaciones que no requieren absolutamente API nativas o gráficos basados ​​en C, la decisión de volverse nativa sin explorar una opción HTML es probablemente mala. Puede ser que necesite ser nativo, pero más personas están siguiendo la ruta HTML hoy y debe estar preparado para articular exactamente por qué descartó esto a favor de una opción de mayor costo. Los inversores, socios, empleados potenciales y clientes preguntarán.

Terminaré sugiriendo que para la mayoría de los productos, normalmente necesita un producto web móvil, incluso si elige ser nativo. Entonces, al menos podría considerar comenzar allí.