En iOS:
- Swift Playgrounds (todos Swift excepto los componentes del compilador)
- Calculadora (principalmente Swift)
- Mira (algunos Swift)
- Música (algo de Swift)
- Aplicación WWDC de la App Store (algunas Swift)
En macOS:
- Dock (la mayoría de las funciones nuevas, más muchas funciones reescritas)
- Consola (algo de Swift)
- Demonios no especificados para soporte Picture-in-Picture (todos Swift)
- Xcode (algunas características nuevas)
El muelle necesita una pequeña explicación. Es responsable de mucho más que solo la fila de íconos en la parte inferior de la pantalla; en realidad, es responsable de la mayoría de las elegantes funciones de administración de aplicaciones y ventanas de macOS. Espacios es una característica de Dock. El control de la misión es una característica del muelle. El conmutador Cmd-Tab es una función Dock. Launchpad es una función Dock. Y Dock realmente usó un poco de Swift 2, por lo que tienen cierta experiencia en la transferencia de Swift 2 a Swift 3. Su uso de Swift se ha expandido este año, con Mission Control ahora completamente reescrito en Swift.
- Cómo construir una aplicación de chat en tiempo real que sea nativa para Andriod, iOS, Windows y Mac
- ¿Objective-C es un desorden desactualizado de un lenguaje?
- ¿Cuál es la mejor ruta para que alguien aprenda codificación, sin experiencia en codificación, si finalmente desea desarrollar aplicaciones de iOS?
- Cómo hacer que un control segmentado muestre diferentes tablas en Swift
- ¿Swift ayudará a más programadores a entrar en el desarrollo de iOS?
El uso de Swift por parte de Apple está necesariamente limitado en este momento. Swift todavía no tiene un ABI estable (conjunto de reglas sobre cómo se representa el código compilado en el disco), por lo que todo el código Swift en una aplicación determinada debe compilarse con la misma versión del compilador. Eso significa que Apple no puede enviar marcos con código Swift público en ellos, porque la versión utilizada para compilar el sistema operativo en algún dispositivo en particular podría no coincidir con la versión utilizada para compilar la aplicación que desea ejecutar en él. (Las características de Swift en marcos como Foundation están en realidad contenidas en bibliotecas de “superposición” que se incluyen en su aplicación).
El equipo de Swift esperaba proporcionar un ABI estable en Swift 3, pero había demasiados requisitos previos para terminar todo a tiempo:
- Agregue nuevas características genéricas que se necesitan con urgencia, en particular las condicionalidades condicionales (la capacidad de decir cosas como “La matriz es equitativa si su tipo de elemento es equitativa”), lo que afectará a la ABI.
- Gran cantidad de limpieza de biblioteca estándar, ya que no tiene sentido tener un ABI estable si los dos lados del ABI ni siquiera pueden ponerse de acuerdo sobre cómo se ve una matriz:
- Cambie el nombre de todo para que se ajuste a las nuevas Directrices API
- Rediseñar el protocolo de la Colección para corregir fallas de diseño graves.
- Rediseñe protocolos centrales como FloatingPoint e Integer para que sean abstracciones útiles
- Adopte nuevas características genéricas a medida que se agregan, eliminando muchos trucos horribles de la biblioteca estándar
- Cree un mejor diseño para los operadores, porque el actual obstruye el compilador con sobrecargas y lo hace muy lento.
- Invente nuevas funciones de lenguaje para describir cambios entre versiones (como “este parámetro se volvió opcional en la versión de biblioteca 1.3”) y bloquee las reglas sobre lo que puede y no puede cambiar de manera segura.
- Agregue nuevas características de lenguaje para seguridad, como clases “selladas” que no pueden subclasificarse desde fuera de la biblioteca que las proporciona, y para la extensibilidad, como enumeraciones “abiertas” que pueden tener nuevos casos agregados por la biblioteca que los posee.
- Escriba herramientas para asegurarse de que las diferentes versiones de la biblioteca sean compatibles con ABI.
- Verifique tres veces que todo esté libre de errores y funcione bien, ya que no podemos cambiarlo más tarde.
Solo después de todo lo que hayamos hecho podemos congelar el ABI y comenzar a enviar los marcos Swift. Ese es también el punto en el que las aplicaciones Swift se volverán mucho más pequeñas, porque cada aplicación no tendrá que llevar su propia copia de la biblioteca estándar y las superposiciones de marco. Obviamente, Apple quiere llegar lo antes posible, pero es mucho trabajo por hacer.
