Home » Noticias » Swift 3 cambia de rumbo y Apple modifica su lanzamiento y prioridades
Swift

Swift 3 cambia de rumbo y Apple modifica su lanzamiento y prioridades

Los grandes proyectos son muy complejos de gestionar. Y muchas veces, cuando se hace un repaso en un momento concreto de la situación, se caen en cosas que tal vez tendrían que haberse visto antes y no se vieron. Y Apple no se libra, obviamente, de esta casuística. Cualquiera que haya trabajado en proyectos con mucha gente involucrada y de gran ámbito, ha vivido una experiencia similar.

El pasado 6 de mayo, Apple publicaba en el blog oficial de Swift el proceso del lanzamiento de la versión 3, del que hablamos en su día, pero solo unos pocos días después han tenido que echar para atrás y replantearse todo el proyecto en cuanto al alcance, principalmente con el objetivo de llegar al objetivo de otoño y la versión 3 con garantías de éxito.

Este es el email que Chris Lattner, responsable y jefe de proyecto, envío en la lista de distribución de evolución del lenguaje.

Hola a todos
Cuanto más profundizamos en el ciclo de lanzamiento de Swift 3, comenzamos a tener un entendimiento más preciso de la forma que está tomando el lanzamiento. Ted (Kremenek) escribió un post la semana pasada sobre el proceso de lanzamiento de Swift 3 https://swift.org/blog/swift-3-0-release-process/ y yo he actualizado el fichero principal README.md del proyecto swift-evolution https://github.com/apple/swift-evolution con algunos detalles actualizados sobre los objetivos de Swift 3.
Es lanzamiento está tomando la forma necesaria para ser realmente fenomenal y que redefina las sensaciones con Swift, creando un gran salto adelante de madurez en el lenguaje y su experiencia cuando se desarrolla. Nos hemos enfocado en conseguir la estabilidad de los fuentes, con la mirada puesta en hacer Swift 4 tan compatible en código con Swift 3 como razonablemente podamos conseguir. Se ha abordado el cambio de nombres en la API (que es uno de los problemas más complejos en las ciencias de la computación), realizado grandes mejoras a la consistencia y sensaciones del lenguaje, además de añadir varias mejoras propuestas.
Dicho esto, queda claro que algunas de las metas que nos propusimos conseguir no van a poder alcanzarse en esta versión, incluyendo algunas de las funciones genéricas más importantes que se necesitan para conseguir cerrar ABI en la librería estándar. Como tal, las metas de la estabilidad de genéricos y ABI pasarán a una futura versión de Swift, donde espero se conviertan en la máxima prioridad a conseguir.
Espero que el debate y planificación para Swift 3.x y Swift 4 comience en algún momento alrededor de agosto de este año. Hasta entonces, es muy importante que nosotros como comunidad, nos enfoquemos en las metas de Swift 3: preferiría que todos nosotros resistiéramos el impulso de discutir funciones principales de cualquier tipo para futuras versiones. También queremos poner una significativa cantidad de esfuerzo en corregir errores y en refinar la calidad al mismo tiempo, lo que significa que el equipo principal se encargará proactivamente de diferir propuestas de evolución a posteriores versiones, para así no interferir en los objetivos de Swift 3, especialmente aquellos que aumentarían mucho los tiempos.
Gracias a toda la fantástica comunidad que desarrolla en esta lista, es un placer trabajar con todos vosotros. Hacednos saber si tenéis cualquier duda.
-Chris (Lattner)

Como puede verse, se han dado cuenta a tiempo que se pretendía abarcar demasiado con Swift 3 y se han dejado algunas de las grandes cosas, como la arquitectura ABI, fuera de este lanzamiento. Recordamos, que ABI es una arquitectura de desarrollo (de la que también hablamos en su día), que permitiría que pudiéramos desarrollar en diferentes versiones del lenguaje aunque este evolucionara (teniendo compatibilidad de código). Además, permitiría modularizar los compilados de forma que si realizamos un cambio en el código de un fichero o actualizamos la versión de un framework, solo se sustituye esa pieza y el proyecto seguiría siendo estable y funcionando (sin tener que volver a generarlo por completo).

El ámbito que abarcará Swift 3

Swift 3, que actualmente no ha sido publicado (la última versión en el blog sigue siendo del 9 de mayo), actualmente no tiene una fecha clara de publicación y puede que a estas alturas se vea retrasado al próximo 13 de junio con la keynote inaugural de la WWDC donde la primera beta de Xcode 8 sería aquella que llevaría el primer lanzamiento de Swift 3.

¿Pero cuál es el alcance que Apple pretende? El primer objetivo a cumplir es a nivel de documentación creando una correcta guía de diseño de APIs. ¿Por qué? Pues porque una de las principales características que tendrá Swift 3, como lenguaje, incluso con Xcode y OS X, es la inclusión del Swift Package Manager. De esta forma, podremos crear APIs a nivel de lenguaje (no de proyecto, como se hace ahora mismo) que nos permitan crear nuestras propias soluciones o usar otras de terceros directamente integradas en el mismo lenguaje e incorporadas en según qué queramos conseguir.

El primer e importante paso es crear una guía adecuada para el diseño de dichas APIs que permita a los desarrolladores seguir unas nomenclaturas que faciliten la creación de estas y a aquellos que las usan, conocer la forma correcta de manejarlo.

En cuanto a nombres, también una parte importante es la equivalencia entre nombres de APIs de Objective-C y su equivalente nomenclado en Swift. Hasta ahora, como ya vimos, todos los métodos y clases de APIs de Objective-C se usaban tal cual en Swift, pero al cambiar las convenciones de nombres, hay que tener una equivalencia de especificación porque ahora los nombres que se usaban no valen y hay que adaptarse al lenguaje menos gramatical y más práctico que va a imponerse en Swift 3. Y esto no solo incluye este ámbito, si no la propia librería estándar del lenguaje.

Por otro lado, a nivel de importación, las APIs en Objective-C podrán hacer uso genérico de clases y tener un equivalente automático entre nomenclaturas, así como las propias APIs nativas en C se migrarán a un entorno orientado a objetos de forma automática (aunque C no soporte este, obviamente). Esto implica cosas como el reciente cambio que obliga a usar selectores como invocaciones de especificación y no como cadenas. En términos generales es lo que Apple conoce como Swiftificación de las importaciones de otros lenguajes compatibles.

Swift 3, como ya se ha dicho, no será compatible en compilación con versiones anteriores. Su cambio de sintaxis será muy importante en muchísimos aspectos. Pero este cambio será el último de este tipo. Una vez nos adaptemos a Swift 3, los cambios futuros serán de mucho menor impacto y más sutiles (como lo han sido hasta ahora las versiones de Swift 1 y 2). Sí es cierto que el cambio a la versión 3 será duro (tendremos asistentes de migración que nos ayuden a nuestros actuales proyectos, no obstante), pero una vez en esta versión la estabilidad irá mucho más allá.

Lenguaje multi-plataforma, el objetivo final

Según palabras de Chris Lattner en el documento de evolución oficial del lenguaje, el objetivo más claro para todos estgos cambios de nomenclaturas y diferencias con Swift 3 es claro: un lenguaje multi-plataforma.

Una de las razones por las que la estabilidad es importante es debido a que la portabilidad a sistemas no-Apple es uno de los objetivos más importantes de Swift 3. Este lanzamiento activa una adopción de gran escala a través de múltiples plataformas, incluyendo mucha funcionalidad de las librerías del núcleo de Swift (Foundation, libdispatch, XCTest, etc). Ya está disponible un port estable para Linux/x86 (permitiendo interesantes escenarios de servidor –server-side-), y estamos trabajando con la comunidad para llevar Swift a FreeBSD, Raspberry Pi, Android, Windows y otros. Mientras no sepamos qué plataformas conseguirán un estado estable en el lanzamiento de Swift 3, cualquier esfuerzo continuará enfocado en hacer el compilador y el runtime lo más portable posible de manera práctica.

Por lo tanto, como podemos leer, Apple tiene las cosas claras y ambiciona llegar a sistemas como Windows o Android, así como otros interesantes como la Raspberry Pi, que le permitiría llegar a gran parte del desarrollo iOT (internet de las cosas) que hoy día se desarrolla con esta plataforma.

Os seguiremos informando sobre el progreso del lanzamiento, mientras se acerca la fecha de la WWDC. 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

Portada Vídeo News

Apple Coding News llega a YouTube

Los boletines de noticias de Apple Coding llegan a YouTube. Descúbrelos y disfruta la mejor forma de seguirnos y estar al día. La más completa. Una forma única de no solo oír las noticias del mundo del desarrollo como nadie más te las cuenta, también podrás descubrir todos los detalles detrás con el apoyo visual del formato que solo YouTube permite. Una nueva experiencia Apple Coding.

  • Eduardo González Joyanes

    Buen artículo, madre mía, estás al día, día…. Felicidades!!!

  • Pablo Villar Vega

    Vaya, parece que he elegido bien estudiando este lenguaje 🙂

  • Enrique Condo

    Cada día Applecoding está mejor, seguid así que os estáis convirtiendo en una referencia en castellano en programación para dispositivos Apple, felicidades!!