El artículo de hoy va sobre todo de temas de desarrollo, que aunque no sean llanos para la mayoría de los usuarios, son interesantes de conocer ya que permiten saber por donde irán los tiros en las próximas versiones de los SO móviles y las estrategias de los fabricantes. Las relaciones entre iOS y Android están en el punto de mira, y en como se acercan y se alejan entre sí a cada paso que dan.
Entre las mejoras «ocultas» de iOS 9 los desarrolladores nos encontramos con algo que a mi al menos me ha pillado por sorpresa: el «App Thinning«, que viene a ser algo así como «adelgazamiento de apps». Básicamente esta es la idea de Apple de como mejorar el rendimiento de las apps en relación al dispositivo en el que se instala. Hace meses Google amenazó con que incorporaría un sistema que «recompilaría» las apps al descargarse de la tienda para que funcionaran mejor y más ágilmente e los dispositivos, aunque a priori se trata de una simple recompilación, ya que no se realizan cambios estructurales en la app, para hacerlo más binario-compatible (cosa imprescindible si quieres que la app vaya mejor en un entorno Java). Pero Apple va más allá.
Las apps en iOS nunca han ido lo que se dice mal, las cosas como son. Suelen ser ágiles, rápidas y el sistema optimizado hace que la experiencia sea buena en la mayoría de las ocasiones. Pero ahora, Apple se enfrenta a un reto que no tenía hace una año: múltiples dispositivos con distintos tamaños de pantalla y rendimientos diferentes. iPhone 5s, 6, 6+, Apple Watch, iPad… Son varios modelos de aparatos distintos con distintos tamaños de pantalla con los que hay que lidiar. Exceptuando el Apple Watch, que se programa de forma independiente, los otros aparatos tienen una forma más o menos estándar de trabajar y aunque hay métodos para unificarlos, a la larga hay conflictos, dependiendo del tipo de aplicaciones. Apple ha decidido crear unos procesos que hagan que la app se gestione adaptada al dispositivo donde se ejecuta y se optimice, no sólo en cuanto a código, sino también estructuralmente. Para ello han incluido el slicing, que permitirá crear distintas versiones de una misma app para que se ejecute de forma diferenciada en cada dispositivo directamente en la propia descarga de la App Store; bitcode, que permitirá generar apps tanto para iOS como para WatchOS 2 (el nuevo sistema para Apple Watch que ya permite aplicaciones nativas) por medio de sistema de código intermedio que se recompilará en la descarga; y Recursos bajo demanda, una novedosa modalidad de desarrollo que permitirá que las apps no tengan que cargar todos sus recursos en la memoria del teléfono como tienen que hacer ahora y permite descargarlos de la App Store «bajo demanda» como su nombre indica, es decir, cuando se necesitan. Estos elementos y sus desarrollos nos va a quitar mucho tiempo a los desarrolladores pero van a permitir realizar aplicaciones mucho más optimizadas y ligeras, algo que los usuarios van a agradecer seguro. Recomiendo la lectura de la página de explicación a los programadores porque les va a gustar (o no, que hay gustos para todo…).
Pero la cosa no termina aquí. Intel ha anunciado una plataforma llamada INDE que permitirá trasladar apps en Java para Android a iOS. Este tema ya lo hemos tratado en el pasado y realizar este tipo de tareas es algo extremadamente complejo, pero al menos no intentan convertir la app tal cual de un sistema a otro: sólo aquel código que es «común» entre las dos plataformas. Las pantallas visuales tendrían que reprogramarse, como siempre, pero según Jeff McVeigh, el encargado de presentar este proyecto, incluso este trabajo se verá altamente reducido. Lo curioso es la dirección del traslado de apps: es desde Android a iOS, y no al revés. Esto es interesante porque aunque la verdad es que iOS no necesita esta realimentación (iOS tiene una cartera de apps de calidad extensísima), la excusa para realizar este proyecto se basa en la facilidad para probar apps en Android en Windows o Linux y luego pasarlas fácilmente a iOS en Mac. Lo que no sé si tienen en cuenta estos señores es que desarrollar en Android con Java es un «dolor de …» (póngase en los puntos suspensivos la palabra más o menos hiriente que uno quiera), y aunque la app se haga sólo una vez (casi), prefiero trabajar en iOS mucho más que en Android sin duda alguna. Ya veremos en que acaba la cosa y si realmente es útil y práctico.
Y para terminar, una nota curiosa. En este artículo de Quartz indican que ahora mismo habría nada menos que hasta 24.000 dispositivos Android diferentes en el mercado. Ahí es nada. Evidentemente, esto es debido a la enorme cantidad de fabricantes en todo el mundo que realizan dispositivos para este mercado, pero esto, desde el punto de vista del desarrollador, es mareante, casi causa estupor. Los programadores tenemos un problema que de hecho se agravó con la programación web, y que decir con los móviles/tablets: tenemos que probar nuestras aplicaciones en entornos diferentes, ya que hay varias versiones de un sistema y de un navegador, pero ya no quiero contar con todos los navegadores distintos que hay, para distintos sistemas, en distintas versiones… Sólo Samsung tiene 20 o más modelos de pantalla distintos. Probar las apps en iOS ya tiene una cierta complejidad pero gracias a los emuladores se mitiga bastante, pero… En Android no sólo tienes distintos tipos de pantallas: también de memorias (velocidades de acceso), conectividad, otras capacidades inherentes al teléfono, la cámara, etc… Probar todo eso en Android (os lo puedo asegurar) es un dolor de cabeza importante. Sinceramente, da un poco de pánico pensar que tu app pueda estar ejecutándose, vete a saber como, en todos esos dispositivos.
