Aplicación Hybrid vs Native Mobile

He hecho principalmente el desarrollo nativo de Android, pero también he ayudado a depurar algunas aplicaciones que se crearon utilizando las plataformas de "compilación cruzada" como PhoneGap y las aplicaciones cruzadas tienen algunas peculiaridades que es bueno dejar que Plataforma para usted si usted construye una aplicación nativa.

Por ejemplo, uno de los que he depurado últimamente no implementó manejadores para eventos de botón de nuevo, lo cual fue una experiencia de usuario realmente incómoda. En una aplicación nativa de Android, y asumo que es la misma para iOS, aunque nunca he intentado construir iOs, el sistema maneja las pulsaciones de botón de nuevo para usted, porque sabe qué actividad se estaba ejecutando antes de la actual y puede reconstruir su interfaz de usuario . En PhoneGap, es esencialmente un navegador webkit envuelto en una aplicación de Android, por lo que no tiene acceso a cosas como el backstack.

Si usted tiene en cuenta que el sistema no va a manejar esos tipos de eventos para usted, y usted no necesita tener acceso a todos los sensores en el teléfono, entonces probablemente podría salir con el uso de uno de estos marcos

Su gracioso con qué frecuencia me preguntó o hablar sobre esta cuestión específica. Aquí está mi sentimiento básico sobre el asunto:

HTML 5, HTML híbrido 5 / Nativo y las aplicaciones nativas son todas las opciones buenas, casi comparables, lo que elegir es una historia diferente.

Aquí hay algunas razones por las que podría elegir uno de ellos, y ya que ustedes me están ayudando a entender el mundo de la programación, voy a tirar en el producto forma (lo que principalmente hacer) piensa en el posicionamiento de mercado y el lado de las cosas.

HTML 5 razonamiento técnico : Necesito esta aplicación para ejecutar en casi cualquier dispositivo de un usuario podría tener, esta aplicación no toque en las funciones propietarias o complejas del dispositivo (subir fotos, activar notificaciones push).

HTML 5 Razonamiento del producto : HTML 5 puede reducir drásticamente el costo del desarrollo de dos maneras. (1) Hay un grupo de talento más grande (por lo tanto de menor costo) compitiendo por los proyectos de ingeniería estándar front end como desarrolladores de HTML 5, mientras que los desarrolladores de iOS y Android reciben una prima seria y son difíciles de conseguir y (2) solo tienes que construirla Una vez y su mucho más fácil de mantener, qa y configurar copias de puesta en escena.

Además, no tienes que lidiar con las tiendas de aplicaciones que participan en tus ingresos. El ejemplo clásico de esto es lo que hizo recientemente el Financial Times (FT). El FT hace su dinero de suscripciones costosas que la mayoría de los banqueros son comprados por sus respectivos bancos. Como tal, tienen un público leal, cautivo y poco sensible a los precios, y su flujo principal de ingresos es casi totalmente de suscripciones. Cuando tenían su aplicación en la App Store de Apple, no podían justificar que regalaran el 30% de cualquier suscriptor nuevo a Apple. Dejaron la tienda de aplicaciones y construyeron una de las aplicaciones web más completas e impresionantes que se parecen mucho a una aplicación, funciona a través de casi cualquier teléfono habilitado para java y les permite mantener el dinero de los suscriptores. En la comunidad de desarrollo que han recibido un montón de elogios para este sitio (se puede comprobar en su teléfono, creo que su http://www.ft.com) y han aumentado su conocimiento de la marca por ser innovadores. Juego, conjunto, partido.

El gran beneficio final para HTML 5 es que no es necesario tratar con las tiendas de aplicaciones. Eso significa que sus manos no están atadas y también puede cambiar las cosas sobre la marcha, lo que permite una mayor iteración y un mejor producto de formación mucho más rápido que tener que presentar a Apple y esperar dos semanas para cada mejora que desea hacer (esto es algo Mitigado en el enfoque híbrido también). Habiendo manejado el sitio de la tableta HTML 5 en ABC News, era vital que pudiéramos arreglar las cosas MUY rápido en la industria de noticias, haciendo este enfoque perfecto para ese tipo de aplicación.

Híbrido HTML 5 / Native razonamiento técnico: Quiero que esta aplicación se ejecute en tantas plataformas como sea posible, pero voy a comercio algunos de ellos con el fin de acceder a funciones de dispositivo propietario y complejo en algunos populares. También estoy cómodo con el hecho de que el diseño no siempre puede ser perfecto de píxeles y hay el potencial de lentitud ocasional.

Razonamiento del producto híbrido HTML 5 / Native: Si tengo una aplicación que necesita estar al menos en iOS / Android, no es una experiencia que deba ser completamente personalizada y debe ser una aplicación en la tienda de aplicaciones porque, francamente, los anunciantes Se entusiasman con la compra de aplicaciones, mientras que la web móvil apenas está en su radar, el enfoque híbrido probablemente sería mi mejor candidato. Al igual que HTML 5, sólo es mucho más barato para construir un sitio web móvil, y luego contratar a un desarrollador nativo para construir un envoltorio de aplicación rápida para usted en iOS / Android / Windows lo que sea. Además de esto, todo lo que necesita hacer es ajustar la parte HTML, crear una nueva instancia, y usted tiene un sitio web para móviles como un bono!

Uno de los peligros aquí es si el HTML 5 no es algo sensible o está bloqueado en 320×480 y 1028×768, como tablillas de diferentes tamaños salen tendrá que hacer un montón de instancias del sitio y detectar el useragent, que es mucho tiempo Y una pesadilla de mantenimiento. Cuando esto sucede por lo general sólo se reconstruye como un sitio sensible, que debería haber sido en el primer lugar.

Razonamiento técnico nativo: Quiero que esta aplicación se ejecute en una plataforma de la forma que yo quiera, necesito tener acceso a funciones propietarias y complejas del dispositivo. Esta aplicación necesita realizar operaciones muy complejas, utiliza mucha memoria y es una aplicación muy personalizada con muchos controladores de interfaz de usuario personalizados. (Algunas categorías incluyen: juegos en 3D, pesadas aplicaciones UGC como CNN iReport y muchas utilidades)

Razonamiento del producto nativo: Tenga en cuenta, como una persona del producto que se ocupan de los presupuestos y los recursos son casi siempre limitados en el mejor de los casos. Cuando digo por encima de que Native sólo es bueno para los juegos en 3D, entiendo que también se puede utilizar para aplicaciones más simples, pero es mucho más caro, menos escalable y cuando se trata de pequeños presupuestos en una empresa que a menudo no hace sentido. Si eres grande en aplicaciones de codificación, entonces por todos los medios ir nativo en lo que usted elija, que es su derecho, porque todo lo que cuesta es su tiempo. Dicho esto, aquí están mis principales razones para usar una aplicación nativa:

Las aplicaciones nativas ganan más dinero. Mucho más dinero. Si usted es un editor grande o un pequeño dev dedican las compras en la aplicación, el ecosistema de Apple funciona para usted de muchas maneras. Como editor grande, un anunciante saltará a la oportunidad de crear la app Coca Cola VH1 Music Awards y pagar por el desarrollo de la misma para usted en la mayoría de los casos! Si trató de ofrecer sólo unos pocos millones de impresiones en un sitio web móvil personalizado, es probable que ni siquiera responder (el enfoque híbrido es a menudo un puente inteligente para este problema). Como un pequeño dev, Apple maneja los pagos para usted, enseña a todos sus usuarios lo fácil que es para ellos comprar cosas en las aplicaciones (esto es donde usted entra y vende a los usuarios 10.000 puntos de valor por $ 9.99) y sí, toma un corte por Su problema, pero usted tiene la distribución y se establecen para comenzar a obtener cheques con muy poco esfuerzo después de lanzar su producto.

La aplicación debe ser la perfección de píxeles y animar como un sueño. Tal vez esta es una aplicación para una revista y no tolerará ninguna página de retraso porque piensan que la aplicación está roto, y sus diseñadores le perseguirán a la muerte sobre los píxeles que están fuera de lugar. Esto puede aplicarse a la mayoría de los proyectos que son para las marcas premium que quieren controlar todos los aspectos de la experiencia de los usuarios. Esto no es una mala cosa, pero rara vez se ve bien.

La aplicación necesita procesar mucho contenido del usuario y hacer frente a muchos sistemas propietarios de CMS o la aplicación es esencialmente algún tipo de plataforma.

La aplicación es una experiencia personalizada que requiere una gran cantidad de procesador del teléfono y necesita ser enganchado en el ecosistema del sistema operativo para hacer sus funciones básicas, por ejemplo, muchas utilidades (piense appkillers en android).

Usted no se preocupa por la web móvil u otras plataformas que las que están desarrollando para. Es posible que un porcentaje de tus usuarios no pueda acceder a tu aplicación y te sientas cómodo con eso.

TL: DR Los tres son muy útiles y cuando se desea utilizarlos debe ser cuidadosamente pensado desde una perspectiva técnica, de producto, de negocio y de diseño.

PhoneGap es muy maduro y bien apoyado. Usted terminará desarrollando su aplicación en jQuery móvil y usará CSS para el diseño. Echa un vistazo a esta galería de jQuery Mobile . Todos estos "sitios web" se pueden convertir en "aplicaciones" usando PhoneGap.

Sin embargo, necesitará una cuenta de desarrollador de Apple para compilar e implementar la aplicación para iPhone y la AppStore.

Puede utilizar un marco multiplataforma. Si desea nativo entonces usted puede ir para el marco de titanio . O si desea webapp para móviles, entonces usted puede ir para el marco de PhoneGap que están proporcionando marco de crossplatform. Esto será una aplicación híbrida.