Escribir una vez, implementar en todas partes: ¿cuándo volverse nativo?

Write Once, Deploy Everywhere (WODE) ha sido la promesa de muchos marcos de desarrollo durante la última década, cuyo objetivo es aliviar el dolor de escribir múltiples aplicaciones nativas. Determinar qué camino tomar es una de las decisiones más críticas que debe tomar un gerente de proyecto debido a su alto costo inicial, el impacto en el equipo de desarrollo y la posible inviabilidad de revertirlo.

Las soluciones híbridas, como Ionic, aprovechan las tecnologías web para representar aplicaciones en todas las plataformas, pero, a menudo, el producto final no cumple con las expectativas de un usuario de una apariencia nativa .

Sin embargo, incluso el término "nativo" se ha enturbiado recientemente por los marcos que se compilan en código nativo (por ejemplo, React Native, Xamarin, etc.).

Este artículo desglosa los pros y los contras de varias rutas de desarrollo móvil y las compara con la composición del equipo, el costo y la experiencia del usuario en un esfuerzo por empoderar a los gerentes de productos para que tomen una decisión más informada.

Escribir una vez, implementar en todas partes

El concepto de Escribir una vez, implementar en todas partes se refiere a la capacidad de un equipo de desarrollo para escribir una aplicación una vez, utilizando una sola pila de desarrollo, resumen de las plataformas en las que se implementará la aplicación, y aún así mantener la capacidad de implementación. la aplicación a todas las plataformas deseadas, por ejemplo, Android, iOS, Windows, etc. Idealmente, esto se logra sin sacrificar la capacidad de mantenimiento, el rendimiento o la experiencia del usuario (UX).

El método alternativo, e histórico, de desarrollo de aplicaciones móviles implica el proceso directo de simplemente escribir una aplicación separada para cada plataforma, lo que, por supuesto, conlleva su propio alto costo potencial de tiempo y recursos.

En general, los factores a considerar al elegir un camino de desarrollo incluyen:

• Edad del proyecto
• Composición y tamaño del equipo de desarrollo
• Plataforma(s) deseada(s) para la distribución
• Línea de tiempo requerida para el mercado
• Ancho de banda disponible para cambiar a otra ruta si es necesario

Desafortunadamente, aplicar cada uno de estos factores a cada uno de los caminos disponibles, así como leer la gran cantidad de opiniones disponibles sobre el tema, puede ser bastante desalentador. Además, este proceso a menudo deja al director del proyecto con una sensación de incertidumbre sobre cuál es el mejor camino para cumplir con los requisitos de la aplicación.

A un alto nivel, las diferentes rutas de desarrollo móvil se pueden clasificar en dos categorías: nativo o WODE, es decir, nativo o todo lo demás. En pocas palabras, uno escribe una aplicación nativa o no. La categoría WODE se divide en dos grupos:

• Marcos híbridos : aquellos que aprovechan las tecnologías web para representar aplicaciones en múltiples plataformas.
• Marcos no híbridos : aquellos que usan componentes nativos de la interfaz de usuario (p. ej., botones, campos de texto e incluso administradores de diseño) en lugar de representar una vista web dentro de una aplicación como lo hacen los marcos híbridos.

La mayoría de los frameworks WODE son híbridos ; sin embargo, para mejorar tanto el rendimiento como las limitaciones de UX de los marcos híbridos y al mismo tiempo brindar los beneficios de un marco WODE, la tendencia actual es hacia los no híbridos . Debido a esta tendencia, los marcos como React Native, Xamarin y Appcelerator están ganando popularidad.

Cada uno de estos caminos (nativos, híbridos y no híbridos) tiene diferentes puntos fuertes y débiles y, como resultado, cada uno tiene diferentes casos de uso para los que es más adecuado. El resto de este artículo desglosa los pros y los contras de cada ruta de desarrollo móvil al considerar las prioridades en competencia, como la composición del equipo, el costo del proyecto y la UX. Con la excepción de algunos casos de uso especializados, escribir aplicaciones nativas maximiza la experiencia del usuario a un costo ligeramente mayor.

En general, se aplica el adagio " obtienes lo que pagas ", por lo que si el costo es más importante que la experiencia de los clientes, es posible que nativo no sea la opción correcta. Sin embargo, una vez que la UX se vuelve vital, las aplicaciones nativas se convierten en la opción clara ya que, para mejorar la UX, las aplicaciones basadas en WODE incurren en un costo considerable en forma de tiempo o experiencia nativa, lo que anula el propósito de elegir una aplicación no nativa. ruta de desarrollo en primer lugar.

Además, incluso si se paga ese costo, el producto final basado en WODE siempre brindará una UX inferior en comparación con su contraparte nativa. Como resultado, Native casi siempre es la opción correcta para la mayoría de los equipos de desarrollo y para la mayoría de los proyectos.

Aplicaciones nativas

Las aplicaciones nativas están escritas en el lenguaje central de la plataforma dada. Por ejemplo, las aplicaciones de Android están escritas en Java, mientras que las aplicaciones de iOS están escritas en Obj-C o Swift. Requieren que el ingeniero de desarrollo comprenda el lenguaje, así como los matices específicos de la plataforma, que incluyen, por ejemplo, la integración de paquetes de terceros, la gestión del diseño, la interacción del sistema operativo (SO), etc.

ventajas

Altamente personalizable . Dado que cada aplicación está escrita utilizando componentes nativos, la única limitación para la personalización es la interfaz de los marcos subyacentes y, a veces, ni siquiera entonces. Como lo atestiguan la mayoría de los ingenieros de desarrollo nativos, a menudo hay una manera de realizar una tarea determinada a pesar de una interfaz limitada.

Se puede encontrar una prueba simple de esta idea navegando en las comunidades de soporte para una plataforma determinada. Uno encontrará numerosos ejemplos de cómo realizar una tarea que podría estar "fuera de la reserva", a pesar de las limitaciones de los marcos subyacentes.

Un ejemplo concreto de iOS de una tarea aparentemente simple podría ser mostrar una superposición de pantalla completa, sobre todos los elementos externos de la interfaz de usuario, por ejemplo, una barra de pestañas, una barra de navegación, etc. Como se muestra en la Figura 1 , esto normalmente está fuera del alcance de la capa de interfaz de usuario normal que se está presentando actualmente. Como tal, para tener una superposición de pantalla completa, debe agregarse a la capa oculta sobre la barra de pestañas en la pila de vistas. Este tipo de personalización normalmente solo es posible en aplicaciones nativas.

Máximo rendimiento . Como era de esperar, una aplicación nativa establece el punto de referencia para el rendimiento. Dado que la mayoría de los otros tipos de marcos agregan una o más capas intermedias, inherentemente se ejecutan más lentamente que una aplicación nativa.

La más mantenible . Los sistemas operativos cambian constantemente. Período. Cuando lo hacen, dependiendo de si se realizaron cambios importantes, una aplicación debe actualizarse de manera oportuna para no perder la parte de la base de usuarios que se actualiza al sistema operativo más nuevo. Obviamente, cuanto menos tiempo transcurra entre que el cambio se pone a disposición de los usuarios y se actualiza una aplicación, mejor. Este tiempo se minimiza cuando no hay dependencias que deban actualizarse para admitir este nuevo sistema operativo, que es el caso cuando se trabaja en una aplicación nativa.

Contras

Recursos adicionales . Cuando se escriben aplicaciones para múltiples plataformas, un equipo de desarrollo generalmente consta de uno o más ingenieros de software móvil para cada plataforma compatible. Esto, por supuesto, aumenta inherentemente el tamaño y el costo de un equipo de desarrollo. También requiere que el equipo de ingenieros tenga una variedad de habilidades, en lugar de tener una base de habilidades homogénea. Esto tiene el potencial de fragmentar un equipo con respecto al apoyo y la colaboración.

Ciclo de desarrollo más lento . Las aplicaciones nativas tienen el potencial de tener un ciclo de desarrollo más lento simplemente porque se debe escribir una aplicación separada para cada plataforma deseada. El caso extremo es cuando hay un solo ingeniero de desarrollo móvil en el equipo, ya que cada aplicación se escribe esencialmente en serie.

Bajo rendimiento . Puede parecer extraño tener el rendimiento como un pro y un estafador. Por un lado, las aplicaciones nativas dan al desarrollador suficiente espacio para crear una aplicación de alto rendimiento finamente ajustada. Sin embargo, por otro lado, también le dan al desarrollador suficiente cuerda para ahorcarse. Si no saben lo que están haciendo, al final, terminarán con una aplicación mediocre en el mejor de los casos.

Nota: En general, esto se aplica a todas las rutas del marco (nativas, híbridas y no híbridas). Si los ingenieros que desarrollan una aplicación no tienen las habilidades suficientes para lo que intentan, es probable que la aplicación resultante no cumpla con los requisitos de diseño ni sea bien aceptada por los usuarios.

Aplicaciones Híbridas

Las aplicaciones híbridas generalmente se escriben usando HTML/CSS/LESS para diseñar la interfaz de usuario: la "V" en el patrón de diseño MVC. La "C", o el controlador, generalmente se escribe en JavaScript; idealmente, utilizando un marco JavaScript MVC como AngularJS. El uso de un marco como AngularJS permite una mejor separación de clases y responsabilidades de lo que normalmente es posible usando solo jQuery.

Un ejemplo de este tipo de pila de marco híbrido sería una capa de vista Ionic respaldada por AngularJS, que finalmente se convierte y se representa en una vista web en la plataforma deseada usando PhoneGap y Cordova. Obviamente, este tipo de marco WODE tiene el costo de una mayor complejidad.

Además, el uso de JavaScript trae consigo sus propias limitaciones basadas en el diseño y problemas basados ​​en el idioma. El objetivo de este artículo no es debatir los méritos o defectos de ningún idioma; sin embargo, como gerente de proyecto, la elección de usar JavaScript en la pila técnica móvil de uno no debe tomarse a la ligera. Los siguientes son solo algunos ejemplos de artículos bien escritos sobre por qué se debe evitar JavaScript si es posible:

• El problema de JavaScript
  
• Por qué no soy un desarrollador nativo de React

ventajas

Equipo mínimo de desarrollo . Los marcos híbridos permiten que un pequeño equipo de desarrollo, y en particular uno cuya base de conocimiento principal sea el desarrollo web, produzca rápidamente aplicaciones simples en múltiples plataformas. Esto permite que un gerente de proyecto mantenga su equipo pequeño y elimine la necesidad de que su equipo aprenda los lenguajes nativos y los marcos para múltiples plataformas.

Ciclo de desarrollo más rápido . Además de un equipo más pequeño, los marcos híbridos permiten un ciclo de desarrollo más rápido cuando se implementan en múltiples plataformas, ya que solo se necesita diseñar una sola capa de vista utilizando tecnologías web.

Contras

UX potencialmente pobre . La desventaja de tener que escribir una sola capa de vista es que uno se queda con una sola capa de vista. Esto puede dar como resultado una experiencia de usuario deficiente, ya que un enfoque único para el diseño de la interfaz de usuario no logra dar a la aplicación una apariencia que sea cómoda y familiar para los usuarios en todas las plataformas. Además, dado que las aplicaciones híbridas son esencialmente una vista web integrada en la interfaz de usuario, puede dar a los usuarios la impresión de que en realidad están viendo una página web en lugar de interactuar con una aplicación nativa. Esta experiencia casi siempre tiene un impacto negativo en la satisfacción del usuario y, en última instancia, en la retención.

Costoso de personalizar . Mejorar la UX mediante el diseño de UI personalizadas para cada plataforma da como resultado marcos de UI complejos y únicos que pueden ser costosos de crear y difíciles de mantener con el tiempo. Además, para crear elementos de interfaz de usuario que ayuden a que la aplicación se destaque (por ejemplo, animación, vistas personalizadas, etc.), se deben crear componentes de puente personalizados para traducir el diseño de interfaz de usuario de alto nivel en algo que el marco de trabajo de nivel inferior , como Córdoba, lo entenderán. En general, cuanto más se personaliza y mejora la UX de una aplicación híbrida, más disminuye el beneficio de un ciclo de diseño rápido y económico.

Menor rendimiento . Dado que las aplicaciones híbridas representan las vistas de la aplicación dentro de una vista web, existe un gran potencial de cometer errores de implementación cuando se trata de marcos de SO (por ejemplo, redes, Bluetooth, contactos en el dispositivo, etc.), lo que resulta en un rendimiento muy degradado. También vale la pena señalar que, incluso si se cuida mucho el rendimiento, ya que todo se muestra a través de una vista web, el rendimiento máximo de las aplicaciones híbridas siempre será ligeramente inferior al de sus contrapartes nativas.

Gestión de complementos no triviales . ¿Recuerda esas características personalizadas que el equipo de diseño pasó semanas puliendo, seguidas de otras pocas semanas mientras el equipo de desarrollo creaba los componentes de puente necesarios para que Cordova pudiera trabajar con ellos? Bueno, no funcionarán a menos que haya un complemento de Cordova compatible con lo que el equipo está tratando de lograr. Esto significa una de dos cosas: el equipo lo crea por sí mismo o se necesitará encontrar un complemento de terceros adecuado que haga el trabajo. Desafortunadamente, la mayoría de las veces, la opción dos no existe. Como resultado, se requiere tiempo de desarrollo adicional para crear los complementos personalizados, seguido de un esfuerzo de soporte de compilación, con el tiempo, para administrar la creciente biblioteca de complementos de Cordova que requiere la aplicación. Por supuesto, cuando se producen actualizaciones de Cordova, existe una alta probabilidad de que estos complementos también deban actualizarse.

Retraso en el soporte del sistema operativo . El problema del componente de puente en cascada/complemento de Cordova mencionado anteriormente se agrava aún más cuando el sistema operativo cambia la funcionalidad principal. Una vez que Cordova, PhoneGap e Ionic se hayan actualizado para admitir los cambios, es posible que los complementos personalizados y los componentes del puente también deban actualizarse. Independientemente del orden de magnitud que requiera este trabajo, da como resultado un tiempo adicional durante el cual la aplicación no es compatible con los usuarios finales que se han actualizado al nuevo sistema operativo. Esto, por supuesto, es el peor de los casos en el que Apple o Google realizan cambios no compatibles con versiones anteriores, lo que nunca sucede ... ¿verdad? En general, cualquier marco intermedio que esté fuera del control del desarrollador y que deba actualizarse primero solo sirve para retrasar el proceso. Finalmente, depender de un marco intermedio puede ser un dolor de cabeza para los gerentes de proyecto para planificar, ya que el tiempo de estos marcos es muy desconocido.

Aplicaciones no híbridas

Las aplicaciones no híbridas comienzan su vida como sus contrapartes híbridas: una capa de interfaz de usuario diseñada en un lenguaje de plataforma no nativo: React Native usa HTML/CSS respaldado por JavaScript o Xamarin, que se basa en C# debido a sus raíces .NET.

Sin embargo, ahí es donde termina la similitud. Las aplicaciones no híbridas se compilan hasta el código nativo y representan la aplicación utilizando componentes nativos de la plataforma en lugar de hacerlo a través de una vista web. Esto da como resultado un marco WODE que, al menos en la superficie, tiene lo mejor de ambos mundos.

Como se discutió anteriormente, elegir usar JavaScript no debe ser una decisión que se tome a la ligera, y podría ser un factor decisivo para un equipo de desarrollo que no desea aprender o no tiene interés en usar JavaScript.

ventajas

Mayor rendimiento que los híbridos . Como cabría esperar, las aplicaciones no híbridas tienen inherentemente un mayor rendimiento que las aplicaciones híbridas debido a su capacidad para representar la aplicación utilizando componentes nativos de la interfaz de usuario (botones, vistas, administradores de diseño, etc.) en lugar de depender de una vista web integrada. Por supuesto, los desarrolladores aún tienen la libertad de escribir una aplicación que funcione de manera notable o horrible. El beneficio de las aplicaciones no híbridas es simplemente que tienen una línea de base de mayor rendimiento en comparación con aplicaciones híbridas similares.

Equipo mínimo de desarrollo . Al igual que los marcos híbridos, los no híbridos permiten que un pequeño equipo de desarrollo, y en particular uno cuya base de conocimiento principal sea el desarrollo web, produzca rápidamente aplicaciones simples en múltiples plataformas. Esto permite a los gerentes de proyecto mantener su equipo pequeño y evitar que el equipo aprenda los lenguajes nativos y los marcos para múltiples plataformas.

Ciclo de desarrollo más rápido . Además de un equipo más pequeño, los marcos no híbridos permiten un ciclo de desarrollo más rápido cuando se implementan en múltiples plataformas, ya que solo se necesita diseñar una sola capa de vista.

Iteraciones más rápidas (React) . El marco React proporciona una característica poderosa que permite que los cambios en la aplicación se representen en tiempo real: no es necesario volver a compilar, reconstruir, etc. Como resultado, el emulador React es una herramienta de desarrollo increíblemente poderosa que reduce drásticamente la duración de cada implementación. ciclo.

Contras

Costoso de personalizar . Al igual que su contraparte híbrida, cuando las aplicaciones no híbridas requieren que se mejore la UX mediante el diseño de IU personalizadas para cada plataforma, se generan componentes de IU únicos y complejos que pueden ser costosos de crear y difíciles de mantener con el tiempo. Esto también significa escribir componentes de puente personalizados para complementar las brechas en el soporte de elementos nativos del marco. Al igual que los híbridos, este costo disminuye el beneficio de un ciclo de diseño rápido y económico, pero a diferencia de las aplicaciones híbridas, los componentes puente se escriben para cada plataforma deseada en su idioma nativo . Esto significa que, en lugar de que las aplicaciones no híbridas sean una alternativa flexible a un equipo compuesto principalmente por desarrolladores web, los equipos que elijan la ruta no híbrida deben aprender no solo el lenguaje particular del marco (por ejemplo, JSX o C#), sino también también el idioma nativo de cada plataforma (Java, Obj-C o Swift).

Dependencias de terceros . Esta limitación adopta dos formas diferentes. En el caso de React Native, toma la forma de numerosas dependencias, es decir, aproximadamente 650. El resultado es que existe una gran posibilidad en cualquier momento en particular de que una o más de esas dependencias estén desactualizadas. También significa que, en el caso de un gran cambio en el nivel del sistema operativo, existe una alta probabilidad de que la mayoría o todas esas dependencias deban actualizarse. La gracia salvadora potencial es que Facebook usa React, por lo que uno tendrá al gorila de 300 libras en su esquina.

En el caso de Xamarin, el problema de la dependencia de terceros es simplemente que es extremadamente difícil integrarlos en primer lugar. Xamarin es consciente de este problema y proporciona una herramienta de utilidad llamada Sharpie. El propósito de la herramienta es ayudar con parte de la integración, pero desafortunadamente, Sharpie a menudo intenta compilar y vincular recursos incorrectos, lo que obliga al desarrollador a emprender la laboriosa tarea de modificar manualmente los parámetros de compilación de bajo nivel para completar con éxito la integración.

Retraso en el soporte del sistema operativo . Las aplicaciones no híbridas están plagadas de los mismos problemas que las híbridas. Cualquier marco intermedio que esté fuera del control del desarrollador y que deba actualizarse primero solo sirve para retrasar el proceso de actualización de la aplicación para admitir usuarios de vanguardia. Además, como se indicó anteriormente, depender de un marco intermedio puede ser un dolor de cabeza para los gerentes de proyectos, ya que el momento de estos marcos es muy desconocido.

Soporte a largo plazo (React Native) . Este problema es específico de React Native y se relaciona con el hecho extraño de que, hasta la fecha, Facebook no se ha comprometido con un plan de soporte a largo plazo para su marco. Se puede decir que este es un riesgo bajo ya que la empresa utiliza su propio marco para sus aplicaciones móviles, pero vale la pena detenerse para que cualquier gerente de proyecto considere por qué Facebook se ha negado a comentar sobre el tema.

Elegir el enfoque correcto

Cuando el costo no es una consideración principal, la Figura 2 muestra que escribir aplicaciones nativas casi siempre es la mejor opción cuando se aprovecha la composición del equipo de desarrollo frente a los requisitos de la aplicación. Cuando hay menos ingenieros de desarrollo que la cantidad de plataformas deseadas, se vuelve un poco más interesante. En ese caso, usar React es la opción correcta si el equipo tiene un cronograma de lanzamiento muy ajustado; de lo contrario, volverse nativo sigue siendo la mejor opción.

Cuando el equipo es principalmente un equipo de desarrollo web y se requiere una UX personalizada, es mejor que algunos miembros del equipo cambien de dirección o agreguen algunos miembros del equipo para que las aplicaciones de uno sean nativas. Realmente no existe una opción de marco factible y mantenible si una aplicación requiere elementos personalizados, lo que hacen muchas aplicaciones.

Sin embargo, si no se requiere una UX personalizada, entonces, según el cronograma de lanzamiento, podría ser mejor optar por Ionic o React. Si el equipo de uno no tiene tiempo para aprender JSX, entonces Ionic es la opción correcta. De lo contrario, es mejor elegir React, ya que requiere muchas dependencias de terceros y agregar más no afectará el ciclo de desarrollo.

Una vez que el costo del proyecto es una preocupación principal, por lo general, la composición del equipo existente deja de ser una prioridad, ya que el primer paso sería establecer el equipo adecuado para ejecutar el plan del proyecto por el costo proyectado. Como se muestra en la Figura 3 , las aplicaciones nativas tienen un costo inicial más alto que sus contrapartes WODE, pero también una UX potencial más alta. Además, las aplicaciones WODE siempre estarán limitadas en su UX, independientemente de cuánto dinero y recursos se apliquen al proyecto.

Espero que este artículo haya arrojado algo de luz sobre los pros y los contras de varias rutas de desarrollo móvil, además de haber ayudado a sopesar la composición del equipo frente a los requisitos de la aplicación y el costo del proyecto. Su mensaje no era transmitir que los marcos de WODE son inferiores y nunca deben buscarse, sino que, aunque existen casos de uso válidos para no volverse nativo, uno debe comprender completamente las ramificaciones de hacerlo.