Home » Noticias » Swift 2.0, el futuro del lenguaje de Apple en iOS 9 y OS X 10.11
Swift 2.0

Swift 2.0, el futuro del lenguaje de Apple en iOS 9 y OS X 10.11

Nos acercamos a la Conferencia Mundial de Desarrolladores de 2015, el próximo 8 de junio, y comienzan a conocerse algunos rumores cercanos a lo que podremos ver e informaciones que empiezan a ser coherentes con una evolución de los componentes para desarrollo en entornos Apple. Y Mark Gurman, redactor en el medio 9to5mac, se ha convertido en el profeta que tiene las suficientes fuentes dentro de Apple como dar pinceladas a los medios de lo que nos espera para las próximas versiones de iOS y OS X.

Según publica en un artículo en que habla sobre el futuro de iOS 9 y OS X 10.11, los futuros sistemas pondrán el foco en el rendimiento, estabilidad y seguridad de los mismos, creándose además dos sistemas operativos iOS diferentes y compatibles entre sí a nivel de apps pero no de componentes.

Y para ello, el nuevo Swift 2.0 es un pilar básico que garantice la compatibilidad de los sistemas aunque el lenguaje evolucione. Porque poco más de un año después de su presentación y trabajando ahora mismo con una más que estable versión 1.2, Apple presentará el 8 de junio la versión beta de Swift 2.0 que vería la luz en otoño junto a iOS 9 y OS X 10.11.

Swift 2.0, integrando Application Binary Interface (ABI)

Si nosotros ahora mismo publicamos una app en Swift nos encontraremos con que el sistema crea una copia de las librerías del lenguaje dentro de nuestra app (que viene a ocupar unos 8MB) debido a que iOS 7 y 8 no incluyen esta librería (a Swift) como parte del sistema operativo. Es la forma de conseguir que versiones anteriores ya publicadas sean compatibles con especificaciones del lenguaje que se han lanzado posteriormente.

Pero es un problema y una especie de parche, por lo que Apple ahora va a incluir el núcleo de Swift en iOS usando para ello arquitectura ABI, que permite una especificación de menor nivel que una API de interconexión y compatibilidad entre sistemas.

ABI no es un estándar con el que tenga que trabajar un desarrollador, es una forma de interconectar una posible especificación actualizable creando una conexión entre especificaciones a través de una implementación inmutable.

Vamos a ejemplificar el problema actual por el que Swift va dentro de las apps y no instalado en el sistema: si incluimos en iOS la librería de Swift como parte del mismo esta librería sería de la especificación 1.1 o 1.2 (por ejemplo).

De esta forma (siempre como ejemplo) si tenemos un dispositivo con iOS 8.2 este tendría Swift 1.1 y otro que tuviera iOS 8.3 tendría la 1.2. Esto provocaría que si hiciéramos una app en Swift 1.2 un dispositivo anterior a iOS 8.3 no podría ejecutarla porque la versión del lenguaje no es la última y provocaría una fragmentación importante a nivel de compatibilidad de apps. Apple resolvió este problema NO incluyendo Swift en el sistema con lo que consiguió que si tenemos un dispositivo con iOS 8 o incluso 7 pudiéramos correr apps con Swift 1.2 ya que el lenguaje se copia como una librería más en la app y así consigue ser compatible con todas las versiones de iOS 7 y 8.

Ejemplo de la API y de la ABI de Linux

Pero esta solución no es la más óptima por lo comentado del sobrepeso que provoca en las apps y porque, por otro lado, limita a Apple a poder ampliar más las capacidades del lenguaje. Por eso van a adoptar una interfaz binaria de aplicación que es una capa de especificación inalterable. De esta forma, aunque futuras versiones de iOS, OS X o Xcode se actualicen a Swift 2.1, 2.2 o la versión que quieran, siempre habrá una librería del propio sistema operativo al que las llamadas del compilador invocarán, que siempre serán las mismas y podrán entenderse. Una capa entre las APIs y el hardware que se entiendan en un mismo nivel de código máquina.

Esto permitirá evolucionar el lenguaje y cambiar su especificación de uso sin provocar problemas de incompatibilidad con versiones anteriores que no incluyan las nuevas especificaciones. Es un paso muy importante a nivel de arquitectura que permitirá a Swift desligarse más aun de Objective-C y ofrecer sus propias soluciones de implementación en vez de usar aun algunas del antiguo lenguaje, además de pegarse aun más al hardware y mejorar su rendimiento, ya de por sí excelente.

Como referencia, ABI es lo que Apple usó en su día para conseguir compatibilidad entre los antiguos Mac con PowerPC y los nuevos con Intel, así como lo que usa Android para hacer compatible la máquina virtual de sus diferentes versiones con los programas que se realizan en varias especificaciones de la SDK o de Java. También es usado por Microsoft para la nueva arquitectura de Windows Universal y podría ser un primer paso para conseguir apps universales que se ejecutaran por igual en iOS y OS X.

iOS 9 y OS X 10.11

El foco es el rendimiento, la estabilidad y la seguridad. Para ello Apple va a crear distintas versiones de iOS 9: dos en concreto. Hasta ahora el sistema ha sido siempre el mismo con determinadas capacidades habilitadas o no en función del dispositivo, creando diferentes versiones con más o menos librerías para cada uno. Como un mismo proyecto con diferentes targets.

iOS 9

Pero eso ahora va a cambiar y Apple ha creado dos versiones diferentes con histórico de compilación y evolución separadas: una versión stock que incluirá solo lo básico del sistema eliminando todo el código sobrante, comprobaciones y enlaces a librerías que luego no se usaban (reduciendo drásticamente el peso del sistema) y otra (la normal) que se preparará para los dispositivos con procesadores de 64 bits.

En esencia, lo que Apple ha hecho es crear dos versiones de iOS 9: una de 32 bits puro, reducida en peso, preparada para dispositivos con 512MB de RAM y librerías más óptimas para dispositivos antiguos y otra de 64 bits pura (sin compatibilidad de 32 bits) para dispositivos con procesadores A7 o superior y 1GB o más de RAM, que creará mejores y más eficientes implementaciones gracias a la arquitectura de 64 bits.

Si recuerdan nuestros lectores, hace algunos meses vaticinamos esto desde AppleCoding, con la diferencia que en vez de dejar fuera de iOS 9 a los dispositivos que no son de 64 bits, Apple ha tomado la sabia decisión de crear una versión de 32 bits más ligera y compatible en apps para así dar oxígeno a los dispositivos más antiguos.

Ambas serán compatibles con las nuevas apps y librerías para iOS 9 pero tendrán versiones completamente diferentes de cada una. Serán como dos sistemas operativos diferentes pero compatibles a nivel de apps. Aunque, y esto hay que tenerlo cuenta, también implicará que ahora será mucho más fácil para los desarrolladores hacer apps que solo funcionen en dispositivos de 64 bits y no sean compatibles con los sistemas de 32 por lo que se generará un nuevo ecosistema de apps mucho más potentes y con capacidades más cercanas a escritorio. Una diferencia que provocará un motivo claro para actualizar los dispositivos más antiguos.

De esta forma pueden optimizar el rendimiento, estabilidad y evolución de cada uno sacando lo mejor de cada sistema. Y además garantizan la seguridad de dispositivos antiguos sin perder la posibilidad de evolucionar los nuevos y más potentes con más recursos y memoria.

De hecho, este es otro de los motivos por los que Apple incluye ABI dentro de Swift, ya que el foco de un Application Binary Interface es conseguir la compatibilidad del código de un desarrollo entre diferentes sistemas a través de una única interfaz común. Así, al tener ahora dos sistemas operativos en lugar de uno, se garantiza la total compatibilidad con todo lo que se realice. Y es un primer paso para las apps universales de iOS y OS X.

WWDC 2015

Sin duda, se nos antoja una muy interesante Conferencia para el próximo junio, donde se ve que el foco estará en una mejor formación de los desarrolladores, mejores herramientas y optimizar y mejorar cerrando ciclos y puliendo. No esperemos grandes cambios aparte del nuevo TVKit que vería la luz para apps del nuevo Apple TV que parece también casi confirmado. Pero nuestro querido Xcode necesita un buen repaso y yo sigo pensando, como hace tiempo, que Apple creará en un algún momento un Xcode enfocado en juegos y el programa que todos conocemos se dedicaría exclusivamente a apps.

Mientras nos preparamos para la edición de “Programando Swift”, nuestro primer libro que está a punto de colgarse en las estanterías virtuales de la iBook Store y la Amazon Kindle Store, así como para la cobertura que vamos a dar de la WWDC 2015 que como dirían algunos, va a ser legen… ¡daria! 😉 … Good Apple Coding

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

App Store Review Guidelines iOS 11

Cambios en las normas del App Store en iOS 11

Todos sabemos cómo son las normas del App Store (o deberíamos saberlas) y la importancia …

  • ¿Lanzamiento inminente de “Programando Swift”? Shut up and take my money! ;). Tengo muchas ganas de trastear y meterme de lleno.

  • Pingback: Análisis Xcode 7, novedades y App Thinning | Apple Coding()

  • .[Roberto Hevens]

    Buen día Julio:

    Felicitaciones por el podcast 1×3. No tengo cuenta desarrollador de pago. Tu podrías indicarme como instalat en mi Mac Book Air 13′ OS 10.11 beta El Capitan y IOS 9 beta en mi Iohone 6?. Estoy aprendiendo swift 1.2 con xcode 6.3 siguiendo vuestros cursos.

    Muchas gracias.

    • Julio César Fernández

      Hola Roberto,

      Desgraciadamente a día de hoy puedes bajarte Xcode 7 si quieres e instalarlo en Yosemite sin problemas. Pero las versiones beta de iOS 9 y OS X 10.11 aun no están disponibles para el público en general. En julio Apple lanzará la beta pública de ambos sistemas, y desde ya puedes apuntarte en la web oficial (https://beta.apple.com/sp/betaprogram/welcome) para poder recibir las invitaciones de descarga de ambas versiones con el objetivo de probar en el dispositivo directamente (que intuyo es lo que quieres). No obstante, solo indicarte que OS X El Capitán no es estrictamente necesario y se te quedas en Yosemite seguirá sirviendo. iOS 9 sí es necesario, eso sí.

      Un saludo y si tienes cualquier duda, ya sabes dónde estamos. Me alegro mucho que te gustará el nuevo podcast.
      Julio