Una de las primeras cuestiones a las que nos enfrentamos al momento de comenzar a desarrollar aplicaciones móviles, Apps, es qué modelo, tecnología y lenguaje de programación usar para el desarrollo.
Por supuesto que no existe una respuesta única y unánime al respecto, dependerá de los recursos económicos con que se cuente, los conocimientos previos del equipo, la arquitectura general de la solución, así como elementos exógenos como intereses, pasiones, acuerdos, etc. No obstante en este artículo trataremos de brindar un análisis general y argumentado, que sirva como una guía para la toma de decisiones.
Lo primero que haremos será dividir el universo de las Apps en tres grandes grupo de acuerdo a la técnica con que fueron desarrolladas:
- Nativas
- Nativas Hibridas
- Nativas Generadas
1. Nativas: Significa que para su desarrollo se utilizó el lenguaje de programación nativo del dispositivo, Objetive C o Swift para iOS, Java para Android y .Net para Windows Phone. Es un modelo cien por ciento dependiente de la plataforma y las Apps no son portables, hay que desarrollar una por plataforma.
Los principales paradigmas asociados a las Apps nativas son:
- Se puede lograr el mejor rendimiento posible.
- Se puede lograr un look&feel ópitimo acorde al sistema operativo
- Se puede acceder a todas las capacidades del dispositivo
2. Nativas Hibridas: Son aplicaciones desarrolladas usando HTML5, CSS y JavaScript, desplegadas dentro de un contenedor nativo como Phonegap/Cordova el cual brinda acceso a las capacidades del dispositivo de una forma totalmente neutral respecto al sistema operativo. Es un modelo neutro respecto a a la plataforma y con portabilidad máxima.
3. Generadas: Son aplicaciones desarrolladas usando herramientas como Xamarin o Genexus (entre muchas otras), en donde el desarrollo se realiza usando técnicas y lenguajes específicos de la herramienta y luego se genera la App en el lenguaje de la plataforma destino para ser compilada con las herramientas nativas. Son lo que se denomina falsas nativas, pues si bien sus fabricantes claman generar Apps nativas, éstas no cumplen ni cercanamente con ninguno de los tres paradigmas de las Apps nativas. Por esta razón las denominamos Generadas.
CRITERIO DE EVALUACIÓN
En primer lugar, a los efectos del comparativo, restringiremos el universo de Apps, bajo el entendido que una App que presente un catálogo de productos y un juego interactivo con alto grado de gráficos y animación son cosas demasiado diferentes para comparar. Nos enfocaremos en aplicaciones corporativas y de gobierno electrónico, que abarquen cosas como trámites en línea, retail, logística, shopping, eventos, información, noticias; aplicaciones conectadas a servidores vía webservices, con captura de datos, fotos y videos a través de formularios, GPS y demás posibilidades del dispositivo, presentación de información en listas, gráficas, mapas, puntos geolocalizados, catálogos de productos, registración de usuarios y login, interacción con redes sociales, etc., dejando fuera especialmente a los juegos y aplicaciones con alta carga de animación, renderización y gráficos, así como aplicaciones tipo CAD, que por su característica entendemos que merecen una evaluación particular.
En segundo lugar, haremos una evaluación que no solo considere aspectos puramente técnicos sino también del negocio. A tales efectos el criterio de evaluación será:
- Tiempos/Costo de desarrollo.
- Curva de aprendizaje
- Recursos humanos disponibles en el mercado.
- Calidad de la App
- Experiencia de usuario.
- Rendimiento.
- Posibilidades o capacidades de la App.
En tercer lugar consideraremos Apps con requerimiento de ser multiplataforma, iOS, Android y Windows Phone.
Por último vale aclarar que nuestro equipo tiene experiencia en el desarrollo de Apps nativas, App con Phonegap (especialmente con MobileUI), Xamarin y Genexus, razón por lo cual nos hemos concentrado en esas herramientas y dejando otras fuera.
1. Tiempos/Costos de desarrollo
El hecho de tener que desarrollar una versión de la aplicación para cada plataforma hace que las Apps nativas queden en la peor posición en este punto, triplicando el costo de desarrollo.
Por otro lado la simplicidad del HTML + JavaScript, sumado a la capa de abstracción que brindan los plugins de Phonegap, haciendo incluso más simple el acceso a funciones nativas como la geolocalización, pushnotifications, acelerómetro, etc., que el desarrollo nativo, sumado a los infinitos recursos disponibles en la web para esta tecnología, todo mediante un API cien por ciento neutral respecto al sistema operativo, hace que desarrollar una App con esta tecnología insuma entre un 30% y un 50% del costo en comparación con las nativas (una plataforma) y generadas.
En el caso de herramientas como Xamarin, si bien se desarrolla usando C#, requiere un conocimiento por parte del desarrollador de la API de cada plataforma, así como la consideración de estas excepciones durante el desarrollo. Por otro lado, la generación de una UI para cada plataforma, aún usando Xamarin.Forms, requiere esfuerzo. "Write once run anywhere” en Xamarin se cumple para un 70% de la aplicación.
Otro punto a considerar es el costo de las herramientas de desarrollo. Tanto Xamarin como Genexus tiene altos costos en este sentido, tanto en licencias como en requerimientos de hardware y software para las distintas plataformas. Para el caso de una única App, estos costos pueden ser comparables al costo de desarrollo.
En el caso de MobileUI/Phonegap no hay costos de licencias y mediante el servicio de compilación en la nube de Phonegap Build, tampoco es requerida mayor infraestructura.
2. Curva de aprendizaje
Para las Apps nativas, se requiere aprender sobre las tres plataformas, lenguajes y API’s, etc., por lo que desde este punto de vista nuevamente este desarrollo queda en último lugar.
Ahora bien, herramienta a herramienta, considerando una única plataforma, la peor curva de aprendizaje se las llevan las generadas, como Xamarin o Genexus, que cuentan con curvas de aprendizaje bastante asentuadas.
Nuevamente la simplicidad del HTML, CSS y JavaScript, sumado a la simple API de MobileUI, hace que un recurso esté rápidamente capacitado en esta plataforma. Si a esto le sumamos la simplicidad extrema de Phonegap Build para compilar en la nube, nuevamente la opción híbrida se lleva el primer lugar.
3. Recursos humanos disponibles en el mercado
Con la existencia de la web es indiscutible que la abundancia de recursos en HTML, CSS y JavaScript desborda ampliamente la de las otras plataformas, máxime aún si consideramos la curva de aprendizaje muy baja de esta alternativa, tal como se vio en el punto anterior.
El peor lugar se lo llevan las generadas, conseguir recursos de Xamarin en el mercado es difícil y más aún retenerlos, al igual que con Genexus, por lo que el riesgo de usar este tipo de soluciones es alto desde este punto de vista.
4. Calidad de la App
La calidad de la App la analizaremos desde dos perspectivas:
- Experiencia del usuario (UX)
- Rendimiento.
Experiencia de usuario: Como sabemos, la UX depende de factores de diseño, usabilidad, interacción, accesibilidad y calidad visual así como de factores como las emociones, construcción y trasmisión de marca, confiabilidad, etc. Definitivamente es algo que va mucho más allá de la herramienta de desarrollo, basta con ver las miles de App desarrolladas nativas con una experiencia de usuario desastrosa o web responsive, neutrales al sistema operativo, con experiencias de usuario óptimas.
Hecha la aclaración y a los efectos de este artículo, nos limitaremos únicamente al look&feel específico de la plataforma. Obviamente con el desarrollo nativo la aproximación es inmediata, los controles y transiciones de la plataforma están disponibles en la herramienta de desarrollo por lo que su uso es natural e inmediato. En la soluciones con HTML5, con excepción de los controles que nativamente brinda el WebView, el resto deben ser simulados usando HTML5 y CSS3, algo que se logra rápidamente con buen nivel, inclusos algunos existen a nivel de plugins, resultando en nativo. Las Apps generadas, usan los controles nativos, aunque el look&feel general de la App no siempre es óptimo, sobre todo cuando se sale de lo previsto, ya que el diseño se realiza con las reglas de la herramienta que luego deben ser interpretadas y convertidas a nativo. No obstante, para los casos comunes se logran también resultados aceptables.
Ahora bien, si se desea innovar, es decir, ir más allá de las reglas preestablecidas, como es común en el mundo corporativo, entonces nuevamente las soluciones nativas y las híbridas son las que brindan la máxima flexibilidad y las generadas vuelven a estar relegadas. Esto no es una novedad, siempre las herramientas generadoras de software han sido débiles en las interfaces de usuario. Xamarin.Forms ha hecho un gran esfuerzo para mejorar esto y ha mejorado mucho. No obstante, su estrategia de trabajo es disponer de un conjunto de interfaces preestablecidas y en la práctica siempre terminó resultando una limitación.
Rendimiento: El rendimiento final de la App estará definido principalmente por la arquitectura general de la solución, su ingeniería, la inteligencia y resolución de sus componentes server-side, el uso inteligente de los local storage, cache, la capacidad de los webservices y demás. La lógica de negocio normalmente reside en los servidores y su rendimiento juega un papel medular. También la cantidad de transferencia de datos y su frecuencia, uno de los puntos por ejemplo que debilita a SOAP frente a REST.
De esta forma, cualquiera de las alternativas analizadas se despliegan en forma aceptable. Si se fuese a hacer un CAD o un juego con gran carga gráfica sería otra historia y quizás ahí la alternatvia más adecuada sería las nativas, aunque en general en estos casos se usan otros tipos de frameworks.
Una consulta común acerca de Phonegap es relativo a su velocidad, producto de sus comienzos. Desde la versión 3 y con la evolución de los WebView, sumado a proyectos como crosswalk para Android, el rendimiento de estas aplicaciones se ha transformado en óptimo, sus transiciones suaves y JavaScript es un lenguaje ideal para el tratamiento de servicios REST/JSON. Integrado con MobileUI se logra un rendimiento excelente, similar a las nativas y superior a las generadas.
5. Posibilidades o capacidades de la App
A esta altura, para los tipos de Apps que estamos considerando, no hemos encontrado limitación en ninguna de las herramientas analizadas.
CONCLUSIÓN
Tal como comenzamos el artículo, no existe una posición única respecto a qué alternativa usar. Dependerá del tipo de aplicación y sobre todo los recursos humanos y económicos con que cuente el proyecto.
Pero en virtud de nuestra experiencia que tratamos de trasmitir en este artículo, una primera aproximación razonable es comenzar con los modelos híbridos, ya que brinda un buen nivel de calidad de las Apps a un costo sensiblemente menor que las otras alternativas.
Como adicional, la mayoría de las Apps realizadas con MobileUI pueden ser usadas como WebApp lo cual brinda alternativa para aumentar la cobertura, alcanzando otras plataforamas menores y brindando la posibilidad de usar la App a aquellas personas que no deseen instalar la App o no dispongan espacio en su Smartphone.
