VERSUS: Apps híbridas VS Apps Nativas

Desarrollos nativos o híbridos: ¿se acabarán comiendo los nativos a los invasores de tecnología híbrida? ¿O serán los nativos los que acaben en una reserva, como pasó en los EE.UU.?

Este choque de civilizaciones, que se desarrolla de forma inmisericorde en nuestros bolsillos y en nuestros corazones, está muy lejos de llegar a su fin.

Para tratar de resolverlo tenemos, en la esquina derecha, con 75kg de peso y múltiples aplicaciones híbridas a sus espaldas a Arturo Batanero, arquitecto front-end y siempre a punto de salirse de la autovía al ver el cartel de “Córdoba”, preguntándose si está bien escrito.

Y en la esquina izquierda, con 77 Kg de peso  y un montón de aplicaciones nativas desplegadas, tenemos a Miguel Sesma, desarrollador Android e iOS, artesano del software y siempre probando lo nuevo.

Ahora el árbitro sobre el ring eres tú. ¿Se ganará el combate por puntos? ¿O será por KO? ¡Vota!

Apps Híbridas

Arturo Batanero

Entendiendo por aplicación nativa la desarrollada con el SDK de cada plataforma, una aplicación híbrida añade, por definición, un cierto nivel de indirección entre su código fuente y el ejecutable con el que interactúa el usuario, que no existe o es más ligero en la nativa.

Miguel, estarás de acuerdo conmigo en que, desde el punto de vista de rendimiento, la aplicación nativa siempre tendrá un extra de ventaja, el cual puede ser clave para la percepción de calidad de la experiencia de usuario, dado que conseguir rapidez de respuesta y mover el UI a 60fps es una condición necesaria.

Y, sin embargo, es indudable la tendencia que venimos viendo en los últimos años y que seguirá así en los próximos: los desarrollos híbridos multiplataforma irán comiéndole cada vez más cuota de mercado a los nativos, al punto de convertirlos en minoritarios.

¿Por qué va a ser así?

Bueno, todos sabemos que ya ha pasado anteriormente: en el entorno de escritorio, gracias a que el incremento progresivo de la potencia del hardware permitió la existencia de Java, vimos cómo era posible realizar de forma efectiva aplicaciones que ya no eran “nativas”, sino compiladas a un código intermedio y ejecutadas por una máquina virtual, mandando en consecuencia a los programadores de C, C++ y ensamblador nativos, sino a una reserva, si reduciendo bastante su cuota de mercado (un nicho privilegiado, por cierto).

Tú, al igual que yo, sabes que en la actualidad ya hay aplicaciones híbridas (en el sentido del artículo, de utilizar tecnología Web) para escritorio que sustituyen de forma efectiva a aplicaciones hechas en Java o C++, incluyendo tipos de aplicaciones exigentes, como clientes de redes sociales o entornos de desarrollo (¿cuántos saben que el cliente Slack o Visual Studio Code son en realidad aplicaciones híbridas?).

Mi apuesta es que en el entorno móvil previsiblemente acabará sucediendo lo mismo: se seguirá reduciendo la diferencia de rendimiento entre híbridas y nativas, según continúe aumentando la potencia del hardware y mejoren las implementaciones de las máquinas virtuales JS y del DOM local.

Siempre existirá esa diferencia de rendimiento, pero se irá volviendo cada vez más irrelevante a la hora de escoger tecnología, como llevamos observando los que estamos en esto ya unos años.

De dónde venimos

Las aplicaciones híbridas de primera generación hacían uso de un navegador (WebView) local o importado, que era presentado al usuario a toda pantalla y que, mediante HTML+CSS+JS, simulaba el UI nativo de cada plataforma.

Es el enfoque de Phonegap/Cordova en plataformas móviles o de Electron o NW.js en desktop (estos añaden un Node.js al navegador, para construir el ejecutable integrando ambos).

Obviamente, este planteamiento está limitado por la calidad de la implementación del navegador, que si bien en desktop es rápido (el ejemplo de antes, Visual Studio Code, está hecha en Electron y es indistinguible de una aplicación nativa) en el entorno móvil aún exige ser estratégico con lo que implementas, requiriendo siempre de un esfuerzo extra de optimización para acercarte a los 60fps.

Hacia dónde vamos

La nueva tendencia en aplicaciones híbridas es saltarse el DOM del navegador y utilizar directamente componentes nativos, orquestados desde una máquina virtual JavaScript, que es quien ejecuta el programa JS.

Ya no se trata de un WebView a toda pantalla. Ahora tenemos un UI formado por controles nativos de Android o iOS, configurados y posicionados mediante CSS y un SGML que recuerda a HTML, y que son controlados desde una máquina virtual JS (V8 en Android y el motor nativo en iOS) que es quien corre el programa, interactúa con el OS subyacente y abstrae las diferencias entre las diferentes plataformas, entre otras cosas.

Es el enfoque de NativeScript o React Native, todavía en sus inicios, como bien dices Miguel, pero en proceso rápido de maduración.

Con ellas se pueden montar aplicaciones (ver en Android o iOS) que, por poner un ejemplo, muevan una lista de cientos/miles de fotos a 60pfs como una nativa… porque son nativas en ese sentido.

Ofrecen lo mejor de ambos mundos: unir la experiencia de usuario nativa con la experiencia de desarrollo Web.

Si además la aplicación {NS} está desarrollada en Angular, se pueden incorporar todas sus ventajas: gracias a su separación radical de vistas y modelos te permite correr la misma aplicación en nativo y en web (has sido un chico malo aquí, Miguel) sólo ajustando las vistas, así como correr el framework y la app en uno o múltiples hilos de ejecución, dejando el hilo principal sólo para manejar el UI y tratar con el OS subyacente.

Y a la hora de hacer esto último, las cosas también mejoran mucho: en NativeScript, por ejemplo, ya no estamos limitados, como en Cordova, a plugins que deben ser programados para cada plataforma y así poder hacer uso de APIs nativas.

Ahora puedes llamar directamente a cualquier función del OS, gracias a un proxy de conversión de tipos que, si bien añade un nivel de indirección, te permite acceder a la totalidad de la funcionalidad de cada plataforma.

Ya no necesitas que un programador nativo te haga un plugin para conseguirlo. Los plugins sólo serían necesarios ya para integrar, por ejemplo, librerías de código nativo preexistentes, no para hacer uso del OS.

Aparte, el equipo de NativeScript ha desarrollado una capa de abstracción de las diferentes plataformas. Te permite, por ejemplo, acceder a un fichero local del mismo modo en todos los OS, pero que si quieres abrirlo con el API nativo, lo puedes hacer.

¿Código nativo? ¿seguro?

En Android, el código ‘nativo’ tampoco es que lo sea tanto. En sus primeras versiones, el código Java se compilaba ‘Just in Time’ en bytecodes sobre la máquina virtual Dalvik, no siendo tan diferente de la compilación JIT del código JS sobre una máquina virtual como V8.

Desde luego no conceptualmente y, eliminando el obstáculo del DOM, cada vez menos en rendimiento. Y si no te lo crees, mira las prestaciones de Node en el servidor, donde no existe el DOM.

Ahora con ART, en lugar de Dalvik, el código se compila en tiempo de desarrollo, que, a costa de un mayor tamaño, gana en velocidad, pero vamos, nativo, nativo, tampoco es.

iOS, en cambio, sí que hace una compilación de bajo nivel, motivo por el que se permiten usar procesadores menos potentes y con menores requerimientos de memoria, en parte gracias a que controlan el hardware sobre el que corre todo.

Por ello, una aplicación Objective-C o Swift sí que me parece verdaderamente “nativa” en comparación a una aplicación Android en Java o en Kotlin (que, por cierto, Miguel, me alegro de que sigan el modelo de TypeScript).

Clash of Clans

La evolución del hardware y de las tecnologías Web (WebGL será el siguiente salto en móvil, accediendo directamente a la GPU como ya hacemos en desktop) seguirán reduciendo la ventaja de rendimiento de las nativas.

Por el contrario, las ventajas de las híbridas se mantendrán igual que ahora:

  • Coste de desarrollo: tratándose de desarrollos híbridos multiplataforma, el coste siempre será inferior y, según las circunstancias, muy inferior, según aumentemos el número de plataformas de distribución y/o el tamaño del proyecto.

    Una aplicación híbrida podría distribuirse potencialmente en iOS, Android, Windows Phone, MacOS, Windows y Linux con esencialmente la misma base de código, el mismo equipo de desarrolladores y con una menor necesidad de coordinación, al ser un solo equipo.
  • Tiempo de desarrollo: el “time to market” para las aplicaciones híbridas es inherentemente más reducido que el de las nativas.

    Puestos a resolver la misma funcionalidad (porque esquivando fácilmente el gancho que me lanzas, Miguel, se pueden realizar el mismo tipo de aplicaciones si están basadas en controles estándar, que son la mayoría) con tecnologías Web el tiempo de desarrollo resulta ser casi siempre menor.
  • Coherencia y cohesión de funcionamiento: podrá y deberá haber diferencias de adaptación entre plataformas a nivel de vistas, en términos MVC, pero a nivel de modelo la aplicación será sólo una, lo que significará una velocidad de avance similar por plataformas y una resolución de bugs integrada, porque habrá una sola base de código y un único equipo trabajando, no varios.
  • Actualizaciones indoloras: una aplicación híbrida puede, si así se desea, ser actualizada sin tener que pasar de nuevo por la tienda de aplicaciones. Con una nativa no te libras de pasar por un nuevo proceso de aprobación que, especialmente con Apple (aunque vaya mejorando con el tiempo), nunca se podrá comparar en tiempos y costes a tener tú mismo el control de lo que llega a los usuarios.

En definitiva, si se trata de afrontar un desarrollo que:

  • Sea multiplataforma.
  • Que se pueda construir con controles nativos estándar.
  • Donde el coste sea un factor clave.
  • Donde el tiempo de desarrollo también sea fundamental.

Entonces, si no ya en el presente, en el futuro próximo la elección tecnológica será mayoritariamente híbrida.

El desarrollo nativo seguirá siendo necesario donde se necesite ese punto extra de rendimiento y de cercanía al hardware, pero si las aplicaciones deben cumplir los requerimientos anteriores, serán mayoritariamente híbridas.

Mucho me temo que los nativos aquí también acabarán en la reserva… aunque siempre podrán abrir un casino y vivir como reyes.

Apps Nativas

Miguel Sesma

Arturo, actualmente más de la mitad de la interacción digital del usuario con la empresa se genera desde dispositivos móviles. Es por ello que la imagen de empresa y la fidelización de los clientes depende de la calidad de las apps.

Las aplicaciones nativas se desarrollan en Objective C o Swift en iOS y Java o Kotlin en Android. Disponer de Swift y Kotlin nos permite una programación utilizando paradigmas de última generación, como la programación funcional o la garantía y robustez que proporciona el que sean lenguajes fuertemente tipados con null-safety. Arturo, Typescript se pensó para que Javascript pudiera tener tipos estáticos :)

Acceso a la plataforma

Las apps nativas permiten el uso de las funciones avanzadas de cada plataforma, sacan provecho de los procesadores gráficos y exprimen cada funcionalidad a un nivel al que un plugin de una app híbrida no puede acercarse.

Ejemplo: el plugin de cámara de React Native soporta 12 propiedades y unos ocho métodos mientras la cámara de Android son decenas de clases con centenares de métodos y propiedades.

Las apps nativas, al no necesitar plugins que tardan tiempo en ser desarrollados, pueden usar las últimas características de la plataforma tan pronto como estén disponibles. Recordemos que Apple actualiza iOS en dispositivos antiguos y Android utiliza librerías de compatibilidad para que versiones anteriores soporten las nuevas funciones.

Aun existiendo plugins para plataformas híbridas que cubren la mayoría de las funcionalidades del dispositivo, las funciones más evolucionadas, técnicas o modernas quedarán fuera de nuestro alcance y la flexibilidad de uso siempre será inferior al API nativa.

Por supuesto podremos escribir nuestros propios plugins, pero se precisarán programadores nativos para ello. El acceso a código nativo tampoco es posible más que a través de un plugin que ralentiza cada llamada, el proxy que comentas, Arturo.

Rendimiento

La calidad percibida comienza con el  rendimiento, Swift compila a código máquina a través de LLVM y Kotlin lo hace a través de JVM y ART además de poder utilizar C / C++ cuando sea necesario. Ambas plataformas aprovechan las funciones de los componentes de la UI: así UITableView o RecyclerView pueden mostrar listas con transiciones complejas, animaciones avanzadas y gran suavidad de desplazamiento consumiendo mucha menos memoria.

Esto es precisamente el mayor problema de las apps híbridas: en el caso de las que se  ejecutan en una Webview (Phonegap, Ionic, etc.) el rendimiento depende mucho de la calidad de ésta, rendimiento que es muy variable dependiendo no solo de la plataforma, sino del dispositivo y la versión del sistema operativo. En las que se ejecutan en su propia máquina virtual Javascript (React Native, Nativescript…), el enorme peso de esta máquina hace que el consumo de memoria y recursos las desaconsejan en dispositivos de gama baja o media.

Ya sabemos que Javascript no es especialmente eficaz manejando la UX: como ejemplo, uno de los usos habituales de una app es mostrar listas. Una lista nativa renderiza solo lo que sale por pantalla, una lista web renderiza todos los elementos lo que puede ser lento si son muchos.  Pare evitarlo se puede utilizar Lazy Load, pero seguirá lejos del rendimiento nativo.

Arturo, tú mismo comentas cómo se solucionan los problemas de las aplicaciones híbridas: haciéndolas más nativas. React Native y Nativescript utilizan componentes de UX nativos para intentar mejorar el rendimiento. Y aunque es cierto que solucionan problemas como el de las listas que comentaba, introducen otros nuevos: no podemos hacer la aplicación web con ellas.

Podremos generar apps para las plataformas que dispongan de sus propios entornos gráficos (iOS, Android, Windows Phone), pero al no estar basadas en HTML, sino como bien dices, Arturo, en un SGML que recuerda a HTML  no generan código para el browser.

Existen algunas librerías que intentan solventar esto, pero su funcionamiento es limitado y problemático. El uso de componentes UX creados con un lenguaje propio nos ata a un framework concreto, ¡lo contrario de la universalidad multiplataforma que buscábamos!

En las apps nativas podremos crear tantos hilos de ejecución como deseemos, se soportan las coroutines y por supuesto podemos utilizar servicios para realizar trabajo en background: programar tareas  a determinadas horas, terminar el trabajo en curso aunque el usuario apague la pantalla, ejecutar música en background…

En las híbridas no se soportan servicios de sistema y las tareas en segundo plano están limitadas al acceso a la red, ¡y eso en el mejor de los casos! Nativescript ejecuta todo el código en el hilo de la UI aunque permite usar una worker thread de manera muy limitada. React Native soporta HeadLessJs , un equivalente a servicios con menos funcionalidad, y solo se permite en Android. Está lejos de ser equivalente, y lo sabes.

Conseguir que estas aplicaciones se comporten como realmente nativas supone bastante trabajo de desarrolladores nativos, optimizando código y plugins, reduciendo la ventaja económica de programar una vez para ambas plataformas.

Otros aspectos que tener en cuenta

Por resumir otras ventajas de las apps nativas:

  • Trabajar en nativo permite el desarrollo para todo tipo de dispositivos como Wearables (Apple Watch, Android Wear), TV o, Coches (Android Auto, Apple Car).
  • Proporcionan una mayor seguridad. El uso de plugins y Javascript en las aplicaciones híbridas introduce nuevas capas de complejidad susceptibles de ser atacadas.
  • Mejoran la duración de la batería. El código está optimizado para la arquitectura, hace un uso más adecuado de los distintos núcleos de CPU/GPU y necesita menos capas de software para ejecutarse.
  • Permiten utilizar las funciones de accesibilidad nativas, especialmente buenas en iOS. Nos abre a todos nuestros clientes y mejora nuestra imagen corporativa.

En cuanto al entorno de desarrollo, los IDE para apps nativas son muy avanzados, especialmente el caso de Android Studio, basado en IntelliJ Idea. XCode también es un IDE potente. Ambos permiten el diseño de la UI mediante herramientas de arrastrar y soltar.

A la hora de realizar debugging facilitan mucho la tarea al desarrollador. Se puede debugear el código desde el IDE línea por línea o con breakpoints condicionales. Disponen de herramientas avanzadas de profiling que muestran en tiempo real los consumos de CPU, memoria y red y ambas plataformas facilitan la ejecución de test unitarios y funcionales.

Para desarrollar apps híbridas tenemos IDEs como WebStorm (de pago) o Visual Studio (según versiones) y otros con menos prestaciones tipo Visual Studio code, Atom, etc. que están bien, y utilidades y plugins para generar UI o profiles. Pero ninguna de estas herramientas alcanza la especialización y el “Integrated development environment” de los nativos.

Las librerías de analíticas, acceso a mBaaS (Firebase, AWS, Azure…), Marketing y Crash reporting disponen de SDKs optimizados para Android e iOS que se encargan de automatizar la toma de datos como las navegaciones entre pantallas, ejecuciones o logs de crash y mandarlos a la nube en background ocultando las complejidades al programador.  

La actualización de una app nativa en los Stores no es el dolor que pretendes dibujarnos, Arturo: en Android son unos minutos y Apple ha mejorado mucho y ha prometido bajar de días a horas en los próximos meses.

La publicación en un entorno profesional incluye la revisión por parte de Apple o Google (que ha mejorado mucho en esto) de las aplicaciones, garantizando su compatibilidad y seguridad. Saltarse esto inyectando nuevo Javascript en las apps de los usuarios no parece muy buena idea.

La sincronización en la implementación de características entre los diferentes equipos de apps nativas suele ser una de las causas esgrimidas a favor de la unificación híbrida. Es importante que sea el scrum y no cada tecnología quien marque el ritmo de implementación. En un entorno de apps híbridas también tendremos que sincronizar las apps con la web, diseñadores, etc.

¿Vale la pena ahorrar un pequeño porcentaje en el software?

Un proyecto de una app tipo incluye muchos perfiles: Product Owner, Scrum Master, diseñadores de UX, arquitectos, desarrolladores backend, devops… Utilizar aplicaciones Javascript para unificar el Browser, Android e iOS supone un ahorro porcentual pequeño, mucho menor aún si usamos React Native o NativeScript que no nos servirán para el Browser.

Abaratar en la calidad de la app a cambio de dar una peor imagen al cliente y perder su fidelidad no es rentable a medio plazo. En el largo probablemente tengamos que gastar más dinero.

Hay un lugar para las tecnologías híbridas. Algunas partes de la app pueden requerir cambios muy frecuentes o mostrar contenido desarrollado para la web. En estos casos añadir algo de código React o una WebView a nuestra aplicación puede optimizar los recursos sin reducir la calidad general.

En apps muy pequeñas puede tener sentido hacer una versión híbrida de una web existente y si nuestra inversión en código Javascript para las reglas de negocio es muy grande podemos plantearnos una app parcialmente React Native, Facebook lo hace, Arturo, y ya sabemos cómo gasta batería. Pero si partimos de cero para hacer la app de la empresa y queremos que tenga futuro, desde mi punto de vista, el camino a seguir es nativo.

Tú, ¿con cuál te quedas?

  • Apps híbridas

    43.9% 95 votos

    Apps híbridas

  • Apps nativas

    56% 121 votos

    Apps nativas

¡Gracias por tu voto!

Error!

Ver resultados Votar Cambiar mi voto

Con 14 años descubrí que, tecleando ciertas cosas, podías hacer aparecer en la pantalla lo que quisieras y desde entonces no he parado. Tras estudiar informática en la Universidad Pontificia de Salamanca me especialicé en el diseño y desarrollo de sistemas multimedia, tanto dentro como fuera de la pantalla, siempre interesado en la experiencia de usuario final. Actualmente soy uno de los arquitectos del departamento Front-end de Paradigma Digital.

Ver toda la actividad de Arturo Batanero

Miguel Sesma es principalmente desarrollador y formador Android desde 2010, apasionado de la calidad del software y comprometido con las arquitecturas clean y la introducción de buenas prácticas en el desarrollo de movilidad. Sus intereses van desde los lenguajes modernos como Kotlin y Swift aplicados al desarrollo móvil, programación funcional, reactiva, hasta investigación de nuevas tecnologías como los ordenadores cuánticos. Anteriormente ha trabajado Network and Database administrator, desarrollador C++ y desarrollo de IoT.

Ver toda la actividad de Miguel Sesma

14 comentarios

  1. Michel dice:

    Con desarrollo híbrido siempre estarás por detras en avances. Por ejemplo ARKit, CoreML en iOS, ninguna app puntera que se precie debería tomar el camino de las híbridas y perderse este tren. Y el ejemplo de slack no ayuda mucho, va malisimo y consume recursos tutiplén.

    • Arturo Batanero dice:

      Si te fijas, no hay ninguna contradicción entre lo que dices y la tesis a favor de las híbridas.

      Con las premisas expuestas, que son las de la mayoría de aplicaciones y no las que tu mencionas, el futuro, si no el presente, será para las híbridas de última generación, donde prácticamente lo único que cambia es el entorno de desarrollo, porque en lo demás son nativas.

      • Michel dice:

        Ejemplo de Apps en España que se pueden beneficiar de estos últimos avances como ARKit o CoreML. Carrefour, Leroy Merlin, Mapfre, Ikea. Todos clientes o clientes potenciales. Para apps sencillas coincido, el desarrollo híbrido es una opción más que razonable, pero aunque pueda llegar a ser mayor en número, van a ser muy inferiores en relevancia con respecto a las desarrolladas nativamente y más en un mundo tan cambiante donde ser el primero en beneficiarse de las novedades puede ser un factor clave para fracasar o tener éxito.

        • Arturo Batanero dice:

          Con los requerimientos que pones, lo que dices es indiscutible: para hacer que incluya machine learning y/o realidad aumentada específicos para iOS (Android se queda fuera) y hacerlo en fase Beta, para que cuando se actualice iOS de forma general, tengas ya tu aplicación… por supuesto, ve a nativo. Estoy de acuerdo.

          En cambio, lo de pretender identificar aplicaciones híbridas con ‘aplicaciones sencillas’ sencillamente no está basado en la realidad. Cualquier aplicación basada en controles estándar, modularizada mediante lazy loading + unloading no tiene límite de tamaño o complejidad… requerimientos que si son los de la mayoría de aplicaciones.

          • Michel dice:

            Como bien dice Miguel desarrollos como ReactNative añaden una complejidad mayor que disminuye mucho la ventaja de ahorrarse un desarrollo específico, En vez de 3 (web, android, iOS) frente a 2 (Web, y nativos), y aun así sigues teniendo la limitación de estar al día. Cuando hablo de desarrollos sencillos me refiero a los híbridos tipo phonegap o ionic. Antes preferiría echarle un ojo a Kotlin Native para tener código comun en las 2 plataformas(iOS, Android) pero esto de momento está por verse.

  2. Yanko Valera dice:

    También existe http://www.appcelerator.com/ Titanium, es similar a NativeScript o React Native, pero lleva mucho más tiempo en el mercado y a mi modo de ver es más maduro e incluye Windows Phone, aunque por alguna razón en España no es muy conocido. En Titanium, usando Hyperloop http://www.appcelerator.com/mobile-app-development-products/hyperloop/ o los módulos nativos podemos acceder a todas las características nativas de las plataformas, incluyendo ARKit o CoreML etc.

    • Miguel Sesma dice:

      Titanium es comercial, es decir, de pago. Esto ha hecho que fuera perdiendo cuota de mercado con respecto a React Native o Nativescript.

      • Arturo Batanero dice:

        Y como se pasen de listos, a los de NativeScript (antes Telerik, ahora absorbida por Progress) les puede pasar lo mismo.

        El framework en sí es Open Source, pero, por ejemplo, un kit de controles UI bastante potente que han sacado es de pago y me temo que hagan lo mismo con algunas herramientas de desarrollo que están por sacar.

  3. Manuel Franco Giraldez dice:

    Buenos dias.

    ¿Y que me podéis decir de Xamarin? abarca lo mejor de ambos mundos desarrollo nativo en ambas plataformas sobre un unico lenguaje, permite la re utilización de código, rendimiento nativo.

    Podemos abstraernos aun mas con Xamarin.Forms. Lo mire por donde lo mire solo veo ventajas!

    Saludos.

    • Miguel Sesma dice:

      Es cierto que el rendimiento de Xamarin es muy bueno, especialmente en iOS. En Android la sobrecarga de mono quita algunas ventajas. También es cierto que la ux es 100% nativa si no usamos forms y qué forms es una maravilla para hacer aplicaciones de tipo toma de datos
      .
      Sin embargo tiene sus contras. Para mí las principales son:
      – La escasez de librerías de terceros: Tanto en iOS como en Android o Javascript dipones de miles de librerías para no reinventar la rueda a cada paso. En Xamarín la oferta es infinítamente menor. Solo esto hace que la ventaja de un único código disminuya bastante.
      – Escasez de profesionales, especialmente en España. Encontrar gente preparada en C# y con conocimientos de Android y/o iOS (Que son necesarios para la parte gráfica) no es fácil.
      – Si las aplicaciones tienen mucha parte gráfica y poca lógica de negocio, las clásicas app pinta-API, la parte que podemos compartir entre plataformas no compensa las desventajas anteriores.

      Sin embargo, como decía, me parece que tiene un hueco importante para apps de uso interno corporativo, especialmente gracias a forms.

  4. Arturo Batanero dice:

    Escogiendo la tecnología adecuada, la complejidad y las horas/hombre se reducen enormente. Por ejemplo, con NativeScript + Angular, el código de la aplicación sería el mismo en todas las plataformas a excepción de las vistas (los templates o descriptores del UI), que serían diferentes entre Web y Mobile y que requerirían ajustes entre iOS y Android.

    En una aplicación Web + iOS + Android, siendo pesimistas, hablaríamos de 1,25 desarrollos NativeScript contra 3 desarrollos “nativos” iOS+Android+Web, por seguir la misma analogía.

    Y si seguimos aumentando plataformas y la aplicación fuera Web + iOS + Android + Desktop (Win + MacOS + Linux), estaríamos hablando de 1,75 desarrollos contra 6.

    Siempre que la aplicación, por supuesto, cumpla los requerimientos de la tesis del artículo, que son una mayoría.

  5. David Biencinto dice:

    Un buen artículo. Se agradece que se expongan estas preguntas para conocer diferentes puntos de vista. Yo me quedo con las aplicaciones nativas, de siempre, tanto en escritorio como en móvil o tablet. Me valen los argumentos de este artículo, pero por no repetirlos, lo dejaré en que es una simple cuestión de preferencia.

    Por si sirve mi aporte, echo de menos (y mucho) en este post, Xamarin. En sus dos sabores, Xamarin.Forms y Xamarin for iOS/Android. Creo que es una tecnología nativa muy a tener en cuenta, que no debería faltar en este tipo de comparativas.

    • Miguel Sesma dice:

      Por no repetirme: He contestado a Manuel un par de comentarios más arriba sobre Xamarin. Buena opción para un tipo muy concreto de apps.

Escribe un comentario