Home » Noticias » Apple publica el proceso de lanzamiento de Swift 3
Swift 3 Calendar

Apple publica el proceso de lanzamiento de Swift 3

Estamos a primeros del mes de mayo, el próximo mes (a mediados) tendremos una nueva e interesante edición de la WWDC de Apple, y mientras vemos como Swift 3 (como proyecto de código abierto) va evolucionando a la vista de todos. Y una de las grandes ventajas que esto tiene (entre otras muchas) es que podemos conocer el calendario de lanzamiento de la nueva versión del lenguaje que Apple ha hecho público, tanto para OS X como Linux, ya que ambas versiones van de la mano.

Todo empieza el próximo 12 de mayo, donde Apple lanzará la primera Developer Preview del lenguaje en su nueva versión. A partir de ese momento, la rama master del Trunk Development que ahora mismo es el hilo de trabajo principal de la evolución del lenguaje, pasará a ser denominado Swift 3 Developer Preview y contará con lanzamientos lo suficientemente convergentes y calificados para ser considerados betas y no versiones de trabajo como hasta ahora. Estas betas tendrán una periodicidad de lanzamiento de entre 4 y 6 semanas, de aquí a otoño de 2016 donde se lanzará la versión final (probablemente coincidiendo con el lanzamiento de iOS X, macOS, watchOS 3, tvOS X y Xcode 8, todo ello en la tercera o cuarta semana de septiembre).

Características de Swift 3

Lo primero que tenemos que entender es que la nueva versión del lenguaje no será compatible en compilación con la versión 2. Esto implica que vamos a tener que modificar y/o adaptar nuestro código, como mínimo, como ya tuvimos que hacerlo en el paso de la versión 1 a la 2. Lo que sí es cierto es que en Apple se han preocupado, dentro del proyecto, de tener muy en cuenta los efectos colaterales de cualquier cambio y que habrá un asistente de migración que nos facilitará gran parte del trabajo.

Pero también tenemos que entender que una de las cosas que están pendientes de aprobación es la eliminación de los prefijos NS de las clases de Cocoa, eso sin contar los cambios intrínsecos que pueda tener la forma de invocar a los diferentes objetos y métodos de la API que nos permiten hacer las apps a día de hoy. Por eso, el cambio puede ser mucho más profundo a todos los niveles. No obstante, insisto, el asistente de migración está siendo desarrollado en paralelo teniendo en cuenta cada una de las transformaciones que necesitará nuestro código.

Swift 3 será, además, la primera versión en incluir de forma oficial el Gestor de Paquetes del lenguaje, por el que pueden incorporarse nuevas funcionalidades al mismo, de forma similar a como ahora incorporamos frameworks a un proyecto en Xcode. Así, podremos extender la funcionalidad de una manera más integrada y contar con versiones personalizadas del lenguaje que funcionarán en cualquier proyecto sin tener que incluir nada más: podremos crear nuestra propio package con nuestras funciones, clases, métodos o ayudas al desarrollo y que se incorporen a cualquier cosa que hagamos automáticamente.

Otros de los cambios más notables que ya se han aprobado para su incorporación en la nueva versión son los siguientes:

  • Eliminación de la currificación de funciones, var en los parámetros de funciones y los operadores ++ y -- (estos cambios ahora son advertencias de deprecación en Swift 2.2).
  • Traducción más adaptada de las llamadas en Swift a las APIs en Objective-C. Esto significa que las llamadas a través de mensajes sintácticos cambiaría a una composición más clara, menos sintáctica y usando (cuando se pueda) enumeraciones que sustituyan a variables estáticas. Por ejemplo, la instrucción que ahora es let content = listItemView.text.stringByTrimmingCharactersInSet(NSCharacterSet.whitespaceAndNewlineCharacterSet()) pasaría a ser en Swift algo parecido a let content = listItemView.text.trimming(.whitespaceAndNewlines). Ya hablamos de este cambio no hace mucho, más en profundidad, en este artículo.
  • Los loops de estilo C/C++ se eliminan del lenguaje.
  • Se modifican algunos comandos de trabajo en colecciones para seguir un estándar declarativo más homologado. Por ejemplo, los métodos de colección reverse() o enumerate() se convertirán en reversed() y enumerated(), además que por ejemplo minValue() o maxValue() se sintetizan como min() y max().
  • El tipo inout que declara un parámetro de entrada y salida, ahora mismo está en la parte de la etiqueta antecediendo al nombre del parámetro: func test (inout parametro:Int). En la nueva versión se va a incorporar en la parte del tipo (a la derecha de los dos puntos) para hacer más claro que forma parte de este y no de las características de la etiqueta, de forma que la declaración quedaría así: func test (parametro:inout Int).
  • Se elimina el ImplicitlyUnwrappedOptional y en su lugar han de usarse los modificadores reales de ! de los tipos opcionales.
  • Se crean nuevos métodos formUnion o formIntersection que permitan hacer operaciones en un conjunto a partir de los datos de otro, sustituyendo (por ejemplo) una instrucción y = y.intersection(z) por y.formIntersection(z).
  • En la fundación de Swift aun hay tipos que se heredan de clases en Objective-C y que son objetos y no datos por valor (structs) que es más eficiente en memoria para determinados tipos. Por lo tanto los siguientes tipos se cambiarían y se crearán nativos en Swift, quedando obsoletos los tipos que son propios de Objective-C:
Tipo por Valor (para Swift)Clases (en Objective-C)
AffineTransformNSAffineTransform
CharacterSetNSCharacterSet, NSMutableCharacterSet
DateNSDate
DateComponentsNSDateComponents
DataNSData, NSMutableData
IndexSetNSIndexSet, NSMutableIndexSet
IndexPathNSIndexPath
NotificationNSNotification
PersonNameComponentsNSPersonNameComponents
URLNSURL
URLComponentsNSURLComponents
URLQueryItemNSURLQueryItem
UUIDNSUUID
  • Las conversiones implícitas entre tipos de Swift y Objective-C desaparecen, de forma que si ahora queremos convertir un tipo cualquiera de Objective-C por su equivalente, tendremos que nombrar el correspondiente as para dejar clara su equivalencia y origen.

Esto es solo una muestra de todos los cambios que podemos ver en la lista de evolución del lenguaje en GitHub.

Organización del proyecto en Git

A nivel de ramas (branches), en cuanto a la organización del proyecto, este tendrá 2 principales de trabajo incorporando una última en la fase final del proyecto.

La rama master será la principal y toda la funcionalidad que se vaya incluyendo en ella será considerada final y aprobada, como parte del propio lenguaje Swift 3. Cualquier desarrollador podrá crear nuevas ramas swift-3.0-preview--branch que se generarán desde el master y de ahí se podrá corregir y/o implementar algún cambio que podrá ser incorporado al master mediante petición de pull que deberá ser aprobada por los responsables de lanzamiento de cada uno de los módulos de Swift 3, a saber: swift, swift-lldb, swift-cmark, swift-llbuild, swift-package-manager, swift-corelibs-libdispatch, swift-corelibs-foundation y swift-corelibs-xctest. Los módulos swift-llvm y swift-clang (el compilador) se consideran cerrados y se les activa directamente el grado de swift-3.0-branch calificándolos como versión previa final.

Cualquier petición de cambio en el lenguaje, a partir de pull request, tendrá que ir convenientemente documentada con una explicación razonada de la propuesta y/o cambio, el ámbito al que afecta (por ejemplo, si el cambio romperá el código anterior), número de SR (caso de bug) que pretende resolver (si aplica), el riesgo que supone tomar ese cambio en el hilo principal y las pruebas específicas que validen esta petición.

El final de la cuenta atrás

Entramos en un proceso que dará como fruto una nueva, renovada, más coherente y potente versión del lenguaje, que sentará las bases de futuro y que persigue el objetivo de generar una especificación del lenguaje lo suficientemente asentada como para que la arquitectura ABI (de la que ya hablamos en su día) nos permita que cualquier futuro cambio en el lenguaje (incluso aquellos que rompan el código) no afecten a nuestro código en Swift 3 y que la adaptación o no del mismo sea una opción y no una obligación para nuestros desarrollos.

Seguiremos informando de cómo sigue el proyecto de Swift y hasta entonces, 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

Files Banner

¡BOOM! Se filtra el gestor oficial de archivos de Apple: Files

A solo una horas de comenzar la WWDC, se filtra en el App Store durante unos minutos la app Files, gestor oficial de archivos para iOS 11. Analizamos cómo podría iOS 11 incorporar la gestión de archivos, que el hecho de cómo y dónde está publicada nos da mucha información de lo que Apple piensa hacer con este demandado servicio para sus dispositivos iOS.