¿iOS/Android en Windows? La cuadratura del triángulo imperfecto

Generalmente, cuando Microsoft abre la boca sube el pan. Es un hecho constatado desde los tiempos en que Bill Gates presentaba Windows 95 y se le colgaba a media presentación. Es un clásico que nos acompañará toda la vida. Pero eso no quiere decir que sigan haciéndolo por mucho que haya costumbre. Simplemente a veces se dicen majaderías que no se deberían decir. La última viene a colación de la presentación de ayer y del anuncio de que están trabajando nada menos que en ejecutar apps de Android e iOS en su sistema Windows 10. E intentar cuadrar un triángulo nada amoroso como este es cuanto menos un desatino. O directamente una tomadura de pelo. Vamos a ver por qué.

android-ios-windows

En términos generales, una app se ejecuta en un entorno específico. Hay dos tipos de apps fundamentalmente: las denominadas nativas, que han sido escrita contra las librerías del sistema operativo en el lenguaje o lenguajes que permite el desarrollador del sistema y que por lo general (excepción hecha de Android, que requiere optimizaciones extras para ir más o menos decentemente) son rápidas y eficientes en ese sistema. Las aplicaciones no nativas son las desarrolladas en alguna plataforma “solapada” que usa otro lenguaje no permitido inicialmente (al principio Apple no permitía usar otros entornos que no fueran Obj-C, pero hace bastante tiempo que eso es posible) y que generalmente se han visto reducidas al desarrollo tipo “web”, con HTML y Javascript como principales referentes. Parecen una app nativa pero no están desarrolladas de forma nativa. Generalmente eso suele significa apps de peor calidad y con un acceso al sistema muy inferior, lo que permite en la práctica hacer pocas cosas en realidad en comparación con las nativas. Por contra, las apps nativas son más difíciles de implementar por lo general (aunque eso depende de la práctica) y además, no son multiplataforma, es decir, ejecutar la misma app en distintas plataformas con relativamente pocos cambios o ninguno.

Dicho esto, podemos derivar que las apps nativas tienen una fuerte tendencia a no poder ejecutarse en otro entorno que no sea el suyo propio. Y esto es lo que se supone que quieren hacer en Microsoft: “traducir” por medio de un compilador las instrucciones de Java o Obj-C/Swift (entiendo que cubrirán los dos) en algo entendible por el núcleo de Windows, basado en .NET. Hasta aquí pinta bonito, pero no lo es tanto. Como se ha podido entender del párrafo anterior, las apps nativas están fuertemente ligadas, no sólo al sistema operativo, sino a sus librerías y a otras librerías de terceros de ese entorno operativo. ¡Ah! Y eso sin contar con la fragmentación de Android y los frameworks. Eso es una fiesta. Excepto los juegos, que ya se realizan mayormente en sistemas multiplataforma, el resto de apps no tienen mucho futuro en un escenario como este. Convertir eso a algo entendible por el sistema de destino de forma optimizada y con rendimiento es, en realidad, una utopía. Ya se ha intentado varias veces, como el experimento Cider, de la Universidad de Columbia, que había conseguido ejecutar aplicaciones iOS en Android pero que lleva tiempo en stand-by porque realmente la viabilidad de este tipo de proyectos es muy compleja y difícil de implementar de forma eficiente. En su web indican que se está desarrollando pero su demo dice que no puede tener acceso al GPS, servicios de localización y bluetooth (entre probablemente otros). Así mismo, Blackberry lo intentó en su día en la Blackberry 10 con el objetivo de salvarse, con los resultados ya por todos conocidos: empresa en ruina.

sistemas

Y es que aparte de las dificultades técnicas de un proceso semejante, están las comerciales. Hacer que las apps de otros sistemas corran en el tuyo tiene una desventaja: hace que los desarrolladores no estén interesados en desarrollar de forma nativa para tu sistema y tus extensiones. Si todo lo podemos desarrollar en Swift y Java, las extensiones que pueda publicar Microsoft para su sistema y las correspondientes optimizaciones dejarán de tener efecto en esas apps (o tendrían que hacer extensiones compatibles con estos lenguajes, lo que en realidad es una catástrofe de estrategia corporativa). Es más, incluso aunque consiguieran una optimización increíble (NO), al final lo que terminará pasando es que lo usuarios no verán interesante tu sistema porque estás ejecutando software de otras plataformas, con lo que usarán esas otras plataformas, donde con una alta probabilidad funcionarán mejor. En el caso de las apps para Android, se me ocurre que no hay botón de ir hacia atrás en Windows Phone con el mismo estilo funcional… La mayoría de apps para Android no tienen una forma de navegar hacia atrás como en iOS, así que muchas veces las apps pueden ser directamente inútiles en este sistema. Puedo poner más ejemplos, pero creo que con este queda claro que va a ser muy, muy difícil que consigan su objetivo.

Satya Nadella tiene muchos retos, pero no los está afrontando bien (es mi opinión, claro). Ha conseguido solucionar muchas “metidas de pata” de Ballmer (que es un excelente jefe comercial, pero un pésimo estratega), pero no todas. La más gorda de su historia fue el sistema único para todos los dispositivos, Windows 8, y ese es el fallo que no van a conseguir arreglar con esto. Jobs tomó una decisión en su día y es que cada tipo de plataforma tenga su sistema propio. Es laborioso y pesado, pero lo correcto a largo plazo. El problema de estas decisiones es que su único objetivo es tener más apps en su tienda, no comprendiendo lo insidioso que será a largo plazo, y no están haciendo otra cosa que apuntalar su propio árbol del ahorcado. El tiempo lo dirá.

(Eladio nos recordaba hace tiempo como Microsoft vive en la inopia del mundo real… Lamentablemente va a seguir siendo así mucho más tiempo…).

Deja tu comentario

*