Home » Análisis » Swift 4 (I), compatibilidad y otras mejoras
Swift4 (I)

Swift 4 (I), compatibilidad y otras mejoras

Ya hemos hablado de Swift 4 (como en este artículo), lo hemos analizado, hemos visto sus cambios gracias a que es un proyecto de código abierto y podemos estar al día de todo lo va incluyendo, pero cuando llega la WWDC es cuando las puertas se abren y vemos todo el conjunto. Y es cuando nos damos cuenta que estábamos mirando solo por una pequeña mirilla y que lo hay es mucho más de lo que creíamos. Por eso vamos a dedicar una serie de especiales a esta nueva versión del lenguaje, con el objeto de analizar todos sus importantes cambios. Y en este primero vamos a hablar de algunos detalles interesantes y sobre todo del punto que más importa a la gente: su compatibilidad y sostenibilidad de cambios en el tiempo. Si me dieran un euro por cada vez que alguien me ha preguntado por los cambios en Swift 4 y si serán muchos, sería multimillonario, por lo que sé lo importante que es para la gente y sirva este artículo para dar tranquilidad y paz a la gente.

Pero primero vamos a hablar de algunas características de Swift 4 que no es solo el lenguaje. Este también tiene una serie de componentes como el gestor de paquetes (Swift Package Manager), el control de ayuda de código y resaltado (SourceKit), el compilador (LLVM) y multitud de elementos que conforman en conjunto el lenguaje. Y también Xcode, del que hasta ahora no habíamos visto nada de su nueva versión, que es una pieza fundamental que tiene que ver en la evolución del lenguaje y en sus novedades.

Xcode, Refactor y Editor

Sin duda, el punto más importante de Xcode de cara a Swift y de los factores más aplaudidos por todo el mundo, es el soporte de refactorización de código que ahora incluye (una demanda existente desde su salida hace 3 años). La refactorización permite algo tan simple como cambiar de forma automática en nuestro código cualquier referencia a un objeto al que cambiemos el nombre. Si tenemos toda una app y nuestra clase controlEstado cambia su contexto y ahora se llama controlCentral, resulta que tenemos cambiar todas y cada una de las llamadas a esta clase una por una, usando la búsqueda del propio editor y perder mucho tiempo. Ahora, la nueva refactorización, se encarga de buscar todas las referencias a este objeto, reconocer las que lo son y no simples menciones de texto en una cadena o en un comentario que también le aparecerían a la búsqueda, y cambiarlas.

Además, la refactorización, el motor del mismo, va a liberarse junto a Swift y formará parte de Swift más allá de Xcode y de Apple. Una novedad muy importante para que cualquier IDE pueda implementar esta función y para que puedan crearse nuevas funciones y posibilidades de refactorización de código.

Otra gran novedad de Swift 4 en Xcode, aunque sea indirecta, es el editor de código de Xcode 9 que está hecho desde 0 en Swift y que hace que Xcode 8.3.3 parezca una beta y Xcode 9 la versión final. La fluidez, velocidad, respuesta y funcionamiento del nuevo editor es uno de los trabajos más limpios, efectivos y refinados que Apple ha realizado hasta la fecha en cuanto a software para desarrolladores y no he sido capaz de encontrar a ningún desarrollador que no lo alabe y esté satisfecho con él. Si no lo crees, baja la versión beta de Xcode 9 y compruébalo por ti mismo. Puede instalarse junto a la actual versión sin pisarse la una a la otra.

Swift Package Manager

SwiftPM, como se lo conoce, es el gestor de dependencias del lenguaje. Una herramienta que permite cargar e incorporar al mismo librerías de terceros que extiendan las posibilidades del lenguaje. Actualmente existen más de 7.000 paquetes diferentes instalables en Swift Package Manager tanto para Linux como macOS, y la gran ventaja ahora es que ahora los paquetes también pueden instalarse en el propio Xcode 9 y ampliar su funcionalidad, cosa que no podía hacerse hasta ahora. El gestor de paquetes de Swift 4 además ha incorporado una nueva API de creación de archivos manifest que configuran los paquetes, un mejor flujo de desarrollo, diagnósticos o la resolución de dependencias (una de las funciones más demandadas) para poder elegir qué versión de cada paquete es la que queremos instalar y no la última que haya que es lo hacía hasta ahora).

De hecho, SwiftPM es una de las patas importantes de Xcode porque forma parte del nuevo motor de construcción de apps (el nuevo build system) que actualmente se encuentra en beta y no activado por defecto, pero que será el utilizado para la versión final de Xcode 9 en septiembre. Un motor que, además, está desarrollado nativamente en Swift. Este build system es el que se encarga de construir las apps a partir de nuestro código y gestionar cada paso como la compilación, copia de recursos, configuraciones y construcción de los paquetes binarios, entre otras tareas.

Protocolos y tipos unidos en la definición

Hemos hablado en otras ocasiones de los cambios en el lenguaje (lo hicimos aquí), pero esta vez vamos a centrarnos en uno muy importante que nos permite realizar un tipo de funcionalidad que era imposible en el lenguaje hasta ahora, y que lo revitaliza enormemente.

En Swift 3, cuando queríamos clasificar un dato por un protocolo, en ocasiones sucedía que al cambiar el tipo a este perdíamos la posibilidad de acceder a posibles controles comunes. El ejemplo más simple es cuando tenemos dos vistas como UIButton y UILabel y las conformamos a un protocolo que hemos hecho para luego meterlas en un array. Pero al hacer esto, solo podemos acceder a los componentes del protocolo y no, por ejemplo, a aquellas propiedades o métodos que tienen en común por ser ambas clases hijas de UIView.

Pues bien, ahora podemos crear una colección que una protocolos y clases padres, uniendo elementos comunes de clasificación de una clase. Por lo tanto podremos hacer un array de [MiProtocolo & UIView] y como ambos elementos se conforman con ambas clasificaciones, el lenguaje lo aceptará y permitirá acceder a todos los componentes nativos de uno y otro. Sin duda un cambio excelente. De hecho, esta unión de tipos y protocolos puede usarse también para declarar variables o constantes de tipos múltiples, tipo y protocolo, usando var tipo:(MiProtocolo & UIView).

Compatibilidad y versiones

Y llegamos al tema más importante: lo hemos comentado algunas veces, Swift 4 provoca problemas de compilación de código Swift 3 y por lo tanto ha de ser actualizado. Pero la incidencia es mínima ya que la mayoría de cambios en el lenguaje son aditivos: suman funcionalidades pero no cambian lo que ya hay. Por este motivo, la mayoría del código de Swift 3 funcionará sin cambio alguno en Swift 4 y si hubiera algún problema, tenemos un conversor al que acudir dentro de Xcode que nos puede ayudar en esto.

Pero el punto importante, el que mucha gente ve con incredulidad, es el referente a que en Xcode 9 podemos usar Swift 4 o 3 de forma indiferente. Podemos elegir una u otra versión del lenguaje. Pero claro, eso nos trae a la memoria lo que podía hacerse antes de Xcode 8.3, que permitía usar Swift 2 hasta que al llegar la versión 8.3 esta opción se perdió y ya solo podía usarse la versión 3. ¿Pasará esto también Xcode 9? ¿Nos obligará Apple a actualizar? No. ¿Por qué? Porque Xcode incorpora una nueva versión de Swift, la 3.2, que es 100% compatible con la versión 3.1 y 3.0. Pero esta versión tiene una gran diferencia.

Mientras en Xcode 8.0 a 8.2, cuando elegíamos Swift versión legado (Swift 2) el sistema usaba un toolchain de Swift 2 y cuando elegíamos Swift 3 usaba otro, el de Swift 3, en Xcode 9 no pasa eso. Xcode 9 solo tiene una única herramienta toolchain para todo el IDE: la de Swift 4. ¿Cómo funciona entonces con la versión 3? Porque es la librería de la versión 4 la que tiene un proceso que emula Swift 3 permitiendo una vuelta atrás en la sintaxis e interpretación del código hacia la versión anterior. Por lo tanto, este emulador será el encargado de permitirnos trabajar tanto como queramos en Swift 3 (por eso es la versión 3.2, porque es una emulación de lenguaje hecha por la versión 4) y por lo tanto no es como en el caso que ya hemos comentado donde Apple eliminó el toolchain de Swift 2. En este caso, y así será a partir de ahora, tenemos una completa estabilidad y seguridad de compatibilidad.

Swift Language Compatibilidad

Pero es que el cambio no termina ahí, porque al ser una emulación de Swift 3 desde el toolchain de la versión 4, lo que tenemos es que si queremos migrar poco a poco nuestro código hacia la versión 4, podemos hacerlo ¡y funcionará aunque esté configurado como Swift 3!. El propio compilador detectará las nuevas funciones que estamos usando de Swift 4 y las usará directamente sin acudir a la emulación. De esta forma, podemos migrar de forma progresiva el código, sin ningún tipo de limitación. Y una vez ya tengamos el código en Swift 4, podemos cambiar la opción en los Build Settings de Xcode a la nueva versión y, como ayuda, usar el conversor de código integrado para no dejarnos nada sin convertir.

Y también tenemos otra ventaja significativa para nuestros proyectos. Cuando migremos a Swift 4, no tenemos por qué migrar también todas nuestras dependencias. Al depender todo de un único toolchain, si cualquier librería de terceros que usemos no está adaptada, no importa, porque podemos fijar la versión del lenguaje para cada target del proyecto de forma independiente. Por lo tanto, todas las dependencias pueden ser migradas asíncronamente, en el momento en que el desarrollador responsable haga los cambios pero sin pararnos en nuestro desarrollo.

Esta selección de la versión del lenguaje, también está presente en Swift Package Manager, de forma que podemos, al instalar un paquete (una dependencia) decirle en qué versión del lenguaje está y no importa si usamos la versión 4 y esta dependencia está en la 3 o viceversa. Si aun no hemos migrado pero el paquete que queremos instalar está en Swift 4, podemos usarlo sin problema.

Conclusiones

Como podemos ver, Apple ha pensado en los problemas de compatibilidad desde el primer momento y ha creado una escalabilidad en el lenguaje, que llega al punto de usar emulación entre lenguajes a nivel de sintaxis, donde el entorno de Swift 3 nos permite ir incorpora el código en versión 4 progresivamente. Unido a lo comentado de la independencia de versión de Swift en los targets y todo lo demás, estamos ante un lanzamiento muy serio que no quiere dejar a nadie atrás y dar la inequívoca imagen de madurez como lenguaje.

¿Qué os parecen estos cambios? Esperamos vuestros comentarios y nos vemos en el próximo artículo. Un saludo y 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

Diseñando para el iPhone X

iPhone X (léase 10). El nuevo y más deseado dispositivo de Apple, no carente de …

  • Servando Munguía

    Muy buen artículo, me fue de mucha ayuda, pero tengo una duda. Soy desarrollador de aplicaciones desde hace más de 20 años y tengo poco más de un año empapando me de las nuevas tecnologías. Actualmente estoy desarrollando una app para una cadena restaurantera local en Android pero también se va a requerir tenerla para IOS. Tengo muchas dudas, pero en este momento me urge saber que hay con las compatibilidades entre versiones de ios, equipos iPhone y el lenguaje y herramientas de programación (en este caso swift). Por ejemplo, puedo desarrollar mi app con las últimas versiones de xcode y swift y que corran en un iPhone 4 que a lo mucho soporta ios 7.1.2? Pregunto porque no me da el presupuesto para comprar un equipo más actual para hacer pruebas. De antemano muchas gracias y si me pueden recomendar algún articulo o video sobre este tema, mucho más agradecido. Saludos!