iOS 12 y macOS 10.14: qué supondrá la unificación de ambas plataformas de desarrollo

Concepto de unificación iOS - macOS (por Aurélien Salomon)

Sin lugar a dudas, una de las noticias más interesantes que se han filtrado en los últimos meses sobre el posible futuro de las plataformas de Apple a nivel de desarrollo, es el llamado proyecto Marzipan. Un proyecto que supondría la unificación, a través de las apps, de las plataformas iOS y macOS que será presentado para iOS 12 y macOS 10.14 en la próxima WWDC 2018 que podría celebrarse la primera semana de junio. Pero, ¿qué supone eso exactamente? Vamos a analizarlo y descubrir la historia de cómo hemos llegado a ello para entenderlo más claramente, además de ver las ventajas que esto aportaría a usuarios y desarrolladores.

Un poco de historia

Año 1988. Steve Jobs presenta al mundo su nuevo ordenador tras su salida de Apple cuatro años atrás: el NeXT. Una compañía con un objetivo claro: crear el mejor ordenador para investigación del mundo. Una workstation que cualquier estudiante o académico soñaría con tener. Todo el mundo sabe que la compañía no fue viable económicamente, que el equipo era excesivamente caro y finalmente Apple compró NeXT en 1996 para propiciar la vuelta de Jobs a Cupertino.

NeXT reinventó el desarrollo tal como era y lo definió hasta nuestro días

Pero eso es solo la superficie de la verdad tras NeXT. La realidad es que NeXT reinventó el desarrollo tal como era en aquella época y lo definió hasta nuestro días.

Con la llegada del Macintosh en 1984, las interfaces gráficas habían llegado para quedarse. Pero programar una aplicación para ellas era poco menos que un infierno para cualquier desarrollador. Cada ventana o elemento gráfico debía ser programado desde 0, con mucho esfuerzo y sin ningún tipo de reusabilidad de código. Pero Jobs cogió una de las ideas que descubrió en el Xerox PARC en el año 1979 (donde conoció el Xerox Alto que le "inspiró" para crear el Macintosh) y la aplicó en NeXT: la programación orientada a objetos aplicada a interfaces gráficas.

Un ordenador NeXT

La programación orientada a objetos, como tal, existe desde finales de los años 60. Pero lo que Jobs descubrió en Xerox fue la idea que supuso la base del uso de objetos como elemento reutilizable para crear interfaces. Descubrió las bases de lo que luego se convertiría en el patrón MVC (Modelo-Vista-Controlador) que hoy sigue siendo usado para crear apps nativamente para cualquier sistema Apple. Cogió una super clase del lenguaje C creada en 1980 llamada Objective-C, un motor pionero de compilación incremental orientado a objetos (la primera vez en la historia que un programa solo compilaba las partes que habían cambiado y no todo el código) y el concepto del framework que permitía reutilizar código. Con todos estos ingredientes creó el primer editor comercial de creación de interfaces gráficas de la historia: Interface Builder.

Interface Builder fue el primer entorno de desarrollo con una paleta de componentes (botones, etiquetas, campos...) que podían ser arrastrados a una ventana para crear programas, y usar dichos elementos en el código. Usaba outlets o conexiones que permitían comunicar la interfaz (la vista) con aquello que controlaba qué iba a mostrar (el controlador), mientras los datos para que la aplicación funcionase se guardaban en el modelo. Lo que conocemos como el patrón MVC.

Interface Builder, el primer programa de creación de interfaces de la historia.

Además, con Interface Builder, vieron la luz las primeras librerías o frameworks de la historia: FoundationKit y AppKit. FoundationKit daba soporte a Objective-C para tareas comunes de trabajo con tipos de datos o funciones matemáticas y AppKit permitía crear las propias interfaces. Era la librería donde estaban los objetos que se usaban para crear UIs, es decir, los botones y demás. Esta tecnología fue tan revolucionaria que los NeXT fueron los ordenadores que dieron a luz al lenguaje HTML y los navegadores web, al primer servidor web de la historia (que funcionaba sobre Objective-C), a Virtuoso (padre de Freehand y primer software de dibujo vectorial) o al motor de juego sobre el que se creó el primer FPS de la historia: Wolfestein 3D (los motores de Doom y Quake también fueron gestados en un NeXT).

Hoy día, toda esta tecnología sigue vigente y la librería de construcción de interfaces para macOS sigue llamándose AppKit. Es obvio que ha evolucionado en sus 30 años de historia, pero la base, la esencia, se definió en aquel momento y ha perdurado hasta nuestros días.

Cuando la primera versión del kit de desarrollo de software del iPhone llegó a las manos de los desarrolladores en verano de 2008 (junto al lanzamiento del App Store) supuso un cambio evolutivo muy importante para Apple a nivel de desarrollo. El entonces iPhone OS 2.0 estrenaba la posibilidad que desarrolladores terceros usaran una nueva librería basada en Objective-C que Apple había creado para el primer iPhone durante varios años de trabajo.

Steve Jobs presentando la fundación del iPhone en 2007. La misma de OS X.

Muchos de los frameworks que el entonces OS X usaba estaban presentes tal cual en el nuevo kit de desarrollo del iPhone. De hecho, Apple vendió en su primera keynote de presentación del iPhone que este, por debajo, era OS X. Y así es y sigue siendo. No podemos pensar que iOS y macOS son sistemas operativos diferentes porque no lo son. Comparten el mismo núcleo de sistema, Darwin, y muchas librerías como las de uso de red, seguridad, gráficos, sonido e incluso animaciones de la propia interfaz. El mismo núcleo que Apple creó en el año 2000 para ser el corazón de su sistema OS X.

La diferencia entre iOS, macOS, watchOS y tvOS son las APIs de sistema que hay encima del núcleo Darwin y montadas sobre los componentes que comparten. Por ejemplo, en macOS tenemos a Aqua como API que da servicio a la GUI y AppKit como API de construcción de interfaces. En iOS (he ahí la novedad en 2008) la API de creación de interfaces se llama UIKit. Una API nueva, adaptada al entorno táctil y NO compatible con AppKit. Se parece en algunos aspectos, es indudable, pero no es compatible. Esto es clave para entender el punto donde estamos ahora mismo.

No podemos pensar que iOS y macOS son sistemas operativos diferentes porque no lo son. Comparten el mismo núcleo de sistema, Darwin, y algunos servicios como gráficos, red o sonido.

Por lo tanto hoy día tenemos un mismo núcleo para todos, pero encima de macOS tiene una librería de construcción de apps y sobre watchOS, iOS y tvOS hay otra. La ironía es que con los años UIKit ha evolucionado e incorporado soporte de otras capas de construcción para otros sistemas. Evolucionó con el Apple Watch para permitir crear interfaces para watchOS con los mismos componentes que ya tenía. Y luego volvió a evolucionar para permitir construir apps nativas en tvOS. Los componentes son los mismos en los 3 casos: reloj, TV o dispositivo iOS. Pero UIKit ofrece diferentes adaptaciones de los mismos componentes con el fin de adaptar su apariencia e interacción a aquella que necesita cada nueva plataforma.

Incluir a macOS es el siguiente y lógico paso. Un paso en que UIKit evolucionará y ganará soporte para macOS con el fin de crear apps que funcionen en el sistema de escritorio, heredando el comportamiento y los flujos de uso de este sistema como ya ha hecho con tvOS donde la UI es manejada con un mando táctil y está compuesta por tiles navegables y el uso del concepto del foco por zonas de interfaz.

La unificación ya existe

Apple, hoy día, tiene cuatro grandes librerías de desarrollo para construcción de apps: UIKit (solo para iOS, watchOS y tvOS), AppKit (solo para macOS), SceneKit (para juegos 3D) y SpriteKit (para juegos 2D). Pero, ¿sabían qué? SceneKit y SpriteKit ya están unificadas y permiten crear juegos 2D y 3D que con un solo código y proyecto funcionan en todos los sistemas, incluido macOS.

Por lo tanto el camino ya no es hacer que las apps de iOS se ejecutan en el Mac. Hay que mirar más allá. Porque las apps de iOS no van a ejecutarse en el Mac ya que no tendría sentido. No estamos hablando de lo que Google ha hecho con ChromeOS donde ha puesto Android como un parche donde parte de las apps o juegos no funcionan correctamente porque esperan una interacción táctil. Es decir, no estamos hablando de coger la app de iOS y ejecutarla "en modo emulación", tal cual, en macOS.

Las apps de iOS no se ejecutarán en macOS en un modo emulado, como ha hecho ChromeOS al incorporar compatibilidad con Android.

Lo que Apple está haciendo en el proyecto Marzipan es proporcionar las herramientas necesarias para que UIKit también sirva para crear apps para macOS. No que funcionen en macOS, sino que con las mismas herramientas y componentes que ya usan millones de desarrolladores al programar apps para iOS, tvOS y watchOS, se puedan crear apps que funcionen correctamente en macOS. Así de simple en concepto, aunque obviamente requiere un trabajo importante para que estas herramientas sean adaptadas para que las apps proporcionen una experiencia de usuario fluida y correcta, adaptada a cada sistema y usando las mismas herramientas compatibles.

Una muestra de Xcode con un juego en SceneKit que soporta en un mismo proyecto iOS, tvOS y macOS.

Cualquier desarrollador como yo mismo, que conozca en profundidad los sistemas Apple, sabe que este es el siguiente paso. Algunos desarrolladores conocidos como Steven Troughton-Smith o Guilherme Rambo (ahora editor en 9to5mac), coinciden en esta misma teoría porque, básicamente, es el próximo y lógico paso que Apple ya ha demostrado que puede hacer adaptando UIKit a la usabilidad de un sistema diferente a iOS como tvOS.

Por lo tanto es importante entender que para que las apps creadas para iOS funcionen en macOS requerirán de una adaptación lógica. Habrá que crear una interfaz propia para macOS que luego podrá reutilizar todo el código común de la app, además de incorporar elementos propios como los menús. Incluso la nueva interacción que incorpora iOS 11 para trabajar con la app Archivos a través de permisos temporales a través del sandbox que da seguridad a las apps, también serviría para integrar con Finder y no tener que abrir todo el sistema de archivos a las nuevas apps.

Plantilla para crear un juego SpriteKit Universal que incluye macOS

Cuando hoy creamos un proyecto en Xcode que contiene todos los sistemas, cada uno tiene su target que dará lugar a un ejecutable para cada sistema. Y cada uno de ellos tiene sus carpetas con sus recursos específicos y luego una parte compartida por todos. En los últimos años, las interfaces se construyen con un componente llamado Storyboard que es algo así como el mapa de navegación de la app. Y hay uno diferente para tvOS, otro para watchOS, otro para iOS (iPhone y iPad) y ahora habrá otro nuevo para macOS.

Un primer y muy interesante paso que dará nueva vida a macOS y le permitirá ejecutar apps universales que permitan un flujo de trabajo más unificado.

Desarrolladores, usuarios

Este cambio es algo natural y como hemos visto, parte de una evolución lógica. Y las principales ventajas que se van a obtener de esta evolución son para la propia plataforma macOS. Está claro que el Mac App Store es un desierto y que la plataforma no interesa a los desarrolladores. No solo porque el número de usuarios es mucho menor. También porque desarrollar una app para macOS es más costoso y complejo porque la propia infraestructura de AppKit no ha evolucionado demasiado en todos estos años y eso hace que procesos que UIKit realiza de forma rápida y cómoda en macOS con AppKit sea más engorroso y requiera más trabajo.

A cualquier desarrollador que le preguntes te dirá que hacer apps con macOS le da demasiado respeto e incluso miedo. Es más tedioso y lento.

La llegada de UIKit a macOS supondrá un soplo de aire fresco pues infinidad de apps que funcionan ahora mismo en el ecosistema iOS podrán ofrecer soluciones integradas de uso continuado y por lo tanto el ecosistema macOS se enriquecerá mucho. Si somos solo usuarios iOS no nos aportará nada, pero si tenemos un Mac viviremos una nueva era de prosperidad en el sistema de escritorio. Además las apps de la propia Apple evolucionarán de la mano con un único desarrollo y veremos más novedades de forma frecuente en vez de, como ahora, que da la impresión que el software para macOS está abandonado. Ya sé que el software de Apple para iOS también parece abandonado, pero es lógico pensar que Apple trabaja en nuevas versiones que funcionen ahora también en macOS y por eso no reciben actualizaciones hace tiempo.

Las suscripciones por software que Apple estrenó hace unos años para cualquier tipo de app tendrán también un protagonismo muy importante. Habrá apps que ahora cobran dos veces, una por la versión de iOS y otra por la de macOS, que podrán ofrecer diferentes tipos de suscripción que permitan usar solo la app de iOS a quien interesa o ambas iOS y macOS, creando un flujo de uso muy interesante e integrando por fin el sistema escritorio de forma completa en el ecosistema de uso de las apps y no como un sistema diferente y olvidado.

Hace más de un año, en una entrevista que me hizo nuestro compañero Eduardo Archanco, hablé sobre cómo la unión de los equipos de iOS y de macOS en uno solo no era más que una ventaja para el usuario. Y esta que vemos ahora es la primera consecuencia y gran ventaja para desarrolladores y usuarios.

El futuro

Muchos de los analistas de desarrollo coincidimos en que este será un primer paso: el usar UIKit para hacer apps para macOS.

Concepto de interfaz unificada de iOS y macOS

Un concepto moderno de interfaz unificada entre iOS y macOS, diseñada por Aurélien Salomon.

Pero otra consecuencia de este primer paso son los rumoreados Mac con ARM. Los últimos procesadores de Qualcomm como el anunciado 845 tienen la capacidad de ejecutar software en modo x86. Con algunas limitaciones pero tienen esa capacidad. Si las apps de macOS poco a poco pasan a usar UIKit, estaríamos ante el paradigma que dicha librería puede generar binarios tanto para ARM (dispositivos iOS) como x86 (Mac). Y si usan el núcleo Darwin en su versión ARM en vez de la x86 así como los componentes que ya existen en ambas arquitecturas, podríamos estar a las puertas de una nueva era Rosetta como aquel paso intermedio entre PowerPC e Intel allá por el año 2006. Un paso de transformación que unificaría ambas plataformas a través del desarrollo.

Este último punto hay que verlo, obviamente, como una teoría sobre una base que es técnicamente plausible a nivel de desarrollo y de lo que hoy permite la tecnología. Y habría más pasos aún que podrían darse, pero de eso hablaremos en una próxima ocasión. No obstante, si quieren saber más del tema les invito a oír mi podcast Apple Coding, parte de la comunidad independiente de podcast Cuonda, donde en uno de los últimos episodios hablé de estos temas y algunos más que podrían interesarles si quieren ahondar en él.

Espero que les hayan quedado claras las nuevas posibilidades que se nos ofrecerán a usuarios y desarrolladores, así como que entiendan cómo hemos llegado hasta aquí. Un saludo a todos y gracias.

En Applesfera | "Veremos un sistema operativo universal que unifique el desarrollo, no la experiencia"