Novedades de Swift (2026): la actualización de la WWDC26

Apple lanzó dos versiones de Swift en un mismo ciclo de la WWDC: 6.3 y 6.4 llegaron juntas, y la sesión “What’s new in Swift” cubrió ambas como un único arco de trabajo¹. El enfoque importa porque los cambios se dividen limpiamente en dos públicos. La mayoría de los desarrolladores reciben mejoras ergonómicas más pequeñas y de uso diario (quitar los paréntesis alrededor de los opcionales any, condensar una docena de nombres de plataforma @available en un solo anyAppleOS, silenciar una advertencia de obsolescencia en exactamente una declaración). Un grupo más reducido que escribe código sensible al rendimiento recibe una recompensa que llevaba años gestándose: el sistema de propiedad (ownership) ahora alcanza los bucles for, las propiedades calculadas y la propia biblioteca estándar.

Swift en 2026 es también, de forma visible, un proyecto multiplataforma y multilenguaje. Apple anunció un SDK oficial de Swift para Android, distribuido a través de swift.org⁶, un puente de JavaScript más rápido mediante WebAssembly, la capacidad de exportar funciones de Swift de vuelta a C con un nuevo atributo @C, y un backend de Swift Build que ahora impulsa Swift Package Manager de forma predeterminada¹. Esta publicación recorre las cuatro sesiones que definen la historia de Swift en 2026: las actualizaciones del lenguaje y la biblioteca (262), la ruta de migración a Swift Testing (267), los servicios en tiempo real con gRPC (265) y la computación numérica con MLX Swift (328).

TL;DR

• Swift 6.3 y 6.4 se lanzaron juntas en la WWDC26. Ergonomía diaria: any/some opcionales sin paréntesis, disponibilidad anyAppleOS, el atributo @diagnose para el control de advertencias por declaración y selectores de módulo (::) para colisiones de nombres¹.
• El sistema de propiedad alcanzó el código ordinario: un nuevo protocolo Iterable permite que los bucles for tomen prestados (borrow) los elementos en lugar de copiarlos, y los accesores borrow/mutate reemplazan a get/set para evitar copiar valores grandes en las propiedades calculadas¹.
• Los nuevos tipos de la biblioteca estándar entregan las versiones seguras de viejos patrones inseguros: UniqueArray, UniqueBox, una Continuation de reanudación única, y Ref/MutableRef para mantener un préstamo o una mutación en una variable¹.
• Swift Testing ahora interopera con XCTest en ambas direcciones, con cuatro modos (limited, complete, strict, none); Xcode 27 habilita la interoperabilidad de forma predeterminada². La superficie de @Test, @Suite, #expect y #require está documentada en la referencia de Swift Testing de Apple⁵.
• gRPC Swift llegó al punto en que generas un cliente tipado a partir de un archivo .proto y obtienes RPC unarios además de streaming bidireccional, desplegables en contenedores de Linux en la nube³.
• MLX Swift trae la computación de arrays al estilo de NumPy a Swift, con ejecución automática en GPU y diferenciación automática mediante grad, compartiendo un único motor entre los front-ends de Swift, Python, C++ y C⁴.

Ergonomía del lenguaje: las molestias desaparecen

La sesión arranca con cambios que “quizá apenas notes, salvo como pequeñas molestias que desaparecen”¹. Vale la pena nombrarlos porque eliminan una fricción que se acumuló a lo largo de una década del lenguaje.

Becca y Evan, del equipo de Swift, recorren Swift 6.3 y 6.4. La sección del lenguaje comienza alrededor del minuto 0:45.

Ahora puedes escribir any P? sin envolverlo entre paréntesis. Recibes una advertencia cuando una tarea de Swift Concurrency descarta silenciosamente un error lanzado, lo que te invita a manejarlo dentro de la tarea o a guardar la tarea para comprobarlo más tarde. Desapareció la antigua restricción de llamar a funciones async desde un bloque defer, de modo que la limpieza asíncrona se ejecuta igual que siempre lo ha hecho la limpieza síncrona diferida (SE-0493, Swift 6.4)⁷. Una clase que solo necesitaba @unchecked Sendable por una propiedad weak var puede cambiar esa propiedad a weak let y calificar para la verificación adecuada de Sendable. Un tipo que no debería ser Sendable puede declararlo explícitamente con la nueva sintaxis ~Sendable, que no impide que las subclases sean Sendable¹.

Dos cambios que sin duda notarás. El primero es la disponibilidad: Apple alineó los números de versión de sus sistemas operativos el año pasado, y Swift lo lleva más lejos al permitirte condensar el nombre de cada plataforma en uno solo, anyAppleOS. Cuando la disponibilidad coincide entre las plataformas que te importan, las especificas todas a la vez; cuando hay excepciones, fijas anyAppleOS como valor predeterminado y agregas atributos específicos de plataforma para los casos especiales. El mismo nombre funciona en las condiciones #if os(...)¹.

El segundo es el atributo @diagnose, que cambia el comportamiento de advertencias específicas dentro de una sola declaración. Puedes indicarle a Swift que ignore el grupo de advertencias deprecated declaration en una función mientras migras a una nueva API, sin silenciarlo en todo el proyecto. También puedes hacerlo en la dirección contraria: activar la seguridad de memoria estricta dentro de una función crítica para la seguridad, o ascender una advertencia de error futuro a error en el momento¹. Holly Borla, gerente de ingeniería del equipo de Swift, lo señaló como su favorito al cerrar la WWDC26: “Una de mis nuevas funciones favoritas es el atributo @Diagnose, que te permite controlar el comportamiento de las advertencias en tu código; esto te permite hacer cosas como suprimir obsolescencias, pero también te permite optar por la seguridad de memoria estricta o los diagnósticos de concurrencia estricta de forma más granular, lo cual ayuda, por ejemplo, con la migración al modo de lenguaje de Swift 6.”⁸ Enmarcó toda la versión 6.4 de la misma manera: las actualizaciones consisten en “eliminar cosas que son puntos de fricción” para que los desarrolladores puedan concentrarse en expresar sus ideas en código claro y hermoso⁸.

Luego están los selectores de módulo. Cuando dos módulos importados declaran ambos un tipo llamado View, la antigua solución era la sintaxis de punto (Rocket.SaturnV), que se rompe cuando un módulo llamado Rocket también contiene un tipo llamado Rocket, porque Swift prefiere el tipo y luego no encuentra el miembro. Swift 6.3 introduce ::, donde el nombre a la izquierda es siempre un nombre de módulo, así que Rocket::SaturnV va directo al módulo. El selector también funciona con nombres de métodos y propiedades. La recomendación de Apple es directa: úsalo para conflictos entre módulos que no controlas, y de forma defensiva en código generado por macros, pero no diseñes API que colisionen intencionalmente y luego te apoyes en los selectores para desambiguar¹.

Biblioteca estándar y Foundation

La biblioteca estándar incorporó adiciones puntuales. Un escudo de cancelación de tarea (withTaskCancellationShield, SE-0504, Swift 6.4) ejecuta una región breve donde las comprobaciones de cancelación siempre devuelven false, de modo que la limpieza asíncrona, como terminar de escribir en disco, aún se ejecuta después de que se canceló la tarea circundante⁷. mapKeyedValues pasa tanto la clave como el valor antiguo al closure de mapeo, reemplazando la reconstrucción manual del diccionario que mapValues obligaba a hacer cuando necesitabas la clave. Un nuevo tipo de ruta de archivo, basado en el de Swift System, maneja las diferencias de plataforma en la representación de rutas¹.

Foundation continuó su migración de varios años para dejar atrás Objective-C y pasarse a Swift. Apple modernizó más de Data (accesos a spans, comprobaciones de igualdad, iteración y mutación más rápidos) y unificó NSURL y CFURL en una única implementación de Swift que se ejecuta más rápido y usa menos memoria. ProgressManager es un nuevo tipo de reporte de progreso diseñado para async/await, y el paquete Subprocess llegó a la 1.0 con un tipo de ejecución simplificado, salida transmitida como AsyncBufferSequence y un método strings() que lee la salida línea por línea respetando los límites de los grupos de grafemas¹.

La propiedad (ownership) alcanza el código ordinario

La historia del rendimiento es la que conviene leer con atención, porque representa el momento en que un proyecto de compilador de varios años se convierte en algo que puedes usar en tipos cotidianos. El problema central es la copia: tienes datos en un lugar, los necesitas en otro, así que el programa los copia. Cuando el almacenamiento permanece asignado y ambos lados siguen las reglas de exclusividad de Swift, la copia es innecesaria. Un borrow concede acceso de lectura al almacenamiento existente sin copiarlo; un mutate concede acceso de escritura exclusivo. El compilador verifica ambos en tiempo de compilación, que es lo que hace que la técnica sea segura allí donde el UnsafePointer crudo no lo era¹.

La sección de propiedad y ajuste de rendimiento comienza alrededor del minuto 19:55, y cubre el control de inlining, la especialización y los nuevos accesores.

Varios protocolos ahora funcionan sin copiar. Equatable, Comparable y Hashable pueden usarse en tipos no copiables (noncopyable), y Equatable y Comparable se extienden a los tipos no escapables (non-escapable). Los tipos asociados ahora pueden ser no copiables o no escapables, que es lo que hace posible la función estrella: un nuevo protocolo Iterable que los bucles for admiten directamente¹.

El protocolo Sequence que todos conocen copia los elementos hacia afuera a medida que itera. Iterable permite que el bucle los tome prestados en su lugar, lo que significa que funciona con elementos no copiables y omite el conteo de referencias en objetos y tipos de copia al escribir (copy-on-write). Puede lanzar errores durante la iteración como puede hacerlo un AsyncSequence. Como tomar prestado prohíbe la mutación, la comprobación de exclusividad te impide mutar la colección mientras la recorres en un bucle (una trampa de rendimiento frecuente con Sequence). Un bucle for prefiere Sequence cuando está disponible y recurre a Iterable, y el iterador de Iterable devuelve los elementos en lotes de spans en lugar de uno a la vez, lo que hace que el bucle sea mensurablemente más eficiente para los tipos que pueden devolver todo en un solo span¹.

Los accesores recibieron el mismo tratamiento. El ejemplo de Apple es un UniqueBox que contiene un InlineArray de 256 Int, una estructura de dos kilobytes en un dispositivo de 64 bits. Con get/set, cambiar un elemento copia todo el array hacia afuera y de vuelta. Cambiar la propiedad calculada a un accesor borrow (acceso de solo lectura sin copiar) y un accesor mutate (modificación exclusiva en el sitio) permite que Swift cambie un elemento en su lugar, y permite que el tipo contenga valores no copiables¹.

Varios nuevos tipos de la biblioteca estándar entregan los reemplazos seguros de patrones que antes requerían código inseguro:

• UniqueArray se comporta como Array pero es no copiable, así que almacena elementos no copiables y evita la sobrecarga del conteo de referencias sin comprometerse a un tamaño fijo.
• UniqueBox es un tipo real de la biblioteca estándar que usa los nuevos accesores.
• Continuation comprueba en tiempo de compilación que la reanudes exactamente una vez, lo que la hace más segura que CheckedContinuation y tan eficiente como UnsafeContinuation.
• Ref y MutableRef actúan como un Span para un solo valor: un contenedor para un préstamo o una mutación que puedes almacenar en una variable, pasar, devolver y usar en tipos genéricos. Construyes un MutableRef a partir de un acceso de escritura con un prefijo &, y como las refs son no escapables, Swift sabe que el acceso termina cuando la variable sale del ámbito¹.

UniqueArray y el RigidArray de capacidad fija viven en un nuevo módulo Containers (SE-0527, aceptado en principio), y puedes usar ambos hoy mediante swift-collections 1.3 antes de que se asienten en la biblioteca estándar⁷.

Para el control del optimizador, Swift 6.4 agrega @inline(always) para complementar el longevo @inline(never) (combínalo con final en los métodos de clase, ya que un método sobrescribible aún podría no incorporarse en línea), y Swift 6.3 agrega @specialized, donde una cláusula where le indica al compilador que pregenere una versión especializada de una función genérica para los tipos concretos que más uses¹. Rara vez los necesitarás. Cuando lo hagas, como dice la sesión, “te alegrará tenerlos”¹.

Swift Testing: la migración ahora es bidireccional

Swift Testing se lanzó en Xcode 16 como la biblioteca de pruebas moderna, basada en macros y paralela de forma predeterminada². La historia de 2026 es la migración, y la adición clave es la interoperabilidad de frameworks de pruebas: la capacidad de llamar a la API de un framework dentro del cuerpo de una prueba del otro, en ambas direcciones².

Jerry, del equipo de Swift Testing, demuestra cómo llamar a helpers de XCTest desde pruebas de Swift Testing. El recorrido por la interoperabilidad comienza alrededor del minuto 5:48.

La estrategia de migración que Apple recomienda no ha cambiado: deja la mayoría de los XCTests en su lugar, escribe las pruebas nuevas en Swift Testing y migra las que tocas con más frecuencia. Ambos frameworks ya coexisten en un mismo target. Lo nuevo es que puedes reutilizar el código de los helpers que construiste sobre XCTest. Cuando una prueba de Swift Testing llama a un helper assertUnique que envuelve a XCTFail, eso produce un problema entre frameworks (cross-framework issue), y Xcode ahora lo maneja con cuatro modos²:

• Limited: los problemas entre frameworks provenientes de XCTest son advertencias. Los planes de prueba creados antes de Xcode 27 heredan este modo, y los paquetes de Swift con swift-tools-version: 6.3 lo usan de forma predeterminada.
• Complete: esos mismos problemas se mantienen como errores. Xcode 27 usa el modo complete para los proyectos nuevos; los paquetes de Swift optan por él al subir a swift-tools-version: 6.4 o más reciente.
• Strict: los problemas entre frameworks provenientes de XCTest detienen la prueba con un error fatal, señalándote cada punto donde debes reemplazar la API de XCTest.
• None: te excluyes por completo (úsalo solo de forma temporal, ya que esos problemas pueden marcar errores reales).

Los problemas entre frameworks provenientes de Swift Testing se mantienen como errores en todos los modos, así que puedes llamar con seguridad a #expect y #require desde dentro de un XCTestCase. Anulas el valor predeterminado en un paquete con la variable de entorno SWIFT_TESTING_XCTEST_INTEROP_MODE (el nombre del modo en minúsculas)². La sesión 262 de XCTest confirma el lado correspondiente de la biblioteca estándar: las fallas de aserción de XCTest ahora aparecen como problemas de prueba cuando se invocan desde Swift Testing, de modo que migras sin perder cobertura silenciosamente¹.

El recetario de migración cubre los patrones comunes. XCTSkip se convierte en Test.cancel (o, mejor aún, un trait .enabled/.disabled que saca la lógica de habilitación fuera del cuerpo de la prueba). continueAfterFailure = false se convierte en #require, que lanza un error al fallar y detiene la prueba, lo que te permite elegir por cada expectativa qué fallas detienen la ejecución². La interoperabilidad admite un conjunto de API limitado pero práctico: todas las aserciones de XCTest, ambas macros de expectativa (#expect y #require), la API de problemas conocidos para marcar las fallas de XCTest como conocidas, y Test.cancel para omitir casos de XCTest².

Para la superficie de la API en sí (las macros, el vocabulario de traits, lo que permanece en XCTest), la publicación complementaria sobre Swift Testing vs. XCTest cubre el modelo mental. Dos notas se trasladan desde allí: la automatización de la interfaz de usuario y las pruebas de rendimiento siguen siendo exclusivas de XCTest, y el código que lanza excepciones de Objective-C debe permanecer en XCTests escritos en Objective-C, porque el código de Swift no puede manejar esas excepciones de forma segura². Una vez migrado, obtienes pruebas parametrizadas (cada argumento es un caso separado, todos ejecutándose en paralelo) y pruebas de salida (exit tests) que ejecutan código que se espera que falle en un proceso hijo para verificar la terminación, disponibles en macOS, Linux, FreeBSD y Windows².

gRPC Swift: servicios tipados en tiempo real

La historia del servidor es la demostración más clara de que Swift ahora abarca cliente y backend con un solo lenguaje. La sesión de gRPC construye una app de iOS que se comunica con un servidor de Swift, generada por completo a partir de una especificación .proto³.

George, del equipo de Swift Server, explica los cuatro tipos de RPC. La sección de streaming, incluido el streaming bidireccional, comienza alrededor del minuto 11:06.

gRPC es un proyecto de la Cloud Native Computing Foundation en el que defines las API como funciones con entradas y salidas tipadas en lugar de endpoints HTTP, y generas el código del cliente a partir de la especificación³. El flujo de trabajo: define el servicio en un archivo .proto, agrega grpc-swift-nio-transport (la red sobre SwiftNIO) y grpc-swift-protobuf (el plugin de compilación) como dependencias del paquete, adjunta el plugin run-build-tool GRPCProtobufGenerator, y recompila para generar el cliente tipado.

Un RPC unario como ListRaces envía una solicitud y obtiene una respuesta. La demo de go-karts de la sesión lo conecta a una vista de SwiftUI con withGRPCClient, luego refactoriza para compartir un único cliente a través del entorno de SwiftUI de modo que las vistas reutilicen las conexiones, y se desconecta cuando la escena pasa a segundo plano³. Protobuf serializa los mensajes a binario indexados por número de campo en lugar de por nombre de campo, lo que hace que un mensaje sea “aproximadamente la mitad del tamaño del mensaje JSON equivalente”³, una ventaja real en redes móviles deficientes. Apple señala que la misma eficiencia impulsa su propia infraestructura: gRPC Swift impulsa la comunicación entre procesos en el framework de código abierto Containerization y sustenta Private Cloud Compute, iCloud Keychain y Photos, y el uso compartido de archivos de SharePlay³.

El soporte de streaming es lo que habilita el tiempo real. Más allá de los RPC unarios, existen el streaming de cliente (muchas solicitudes, una respuesta), el streaming de servidor (una solicitud, muchas respuestas, como un canal de comentarios en vivo) y el streaming bidireccional. La demo usa streaming bidireccional para las actualizaciones de carrera en vivo: el cliente transmite qué tipos de evento quiere mientras el servidor transmite los eventos coincidentes. En el lado del servidor eso se convierte en una función async cuyo parámetro de solicitud es un AsyncSequence de mensajes y cuyo parámetro de respuesta es un escritor, manejado con un task group y un conjunto, protegido por un mutex, de los tipos de evento suscritos³. El despliegue es un Containerfile de varias etapas (compilar con swift:latest, copiar el binario de release en swift:slim), ejecutado en Google Cloud Run con HTTP/2, y luego el cliente cambia la seguridad de su transporte de texto plano a TLS³.

MLX Swift: computación numérica que se lee como matemática

La sesión de MLX apunta a un desarrollador completamente distinto: cualquiera que escriba simulaciones, procesamiento de señales, renderizado o entrenamiento de modelos. MLX Swift usa arrays n-dimensionales como su abstracción central, igual que lo hace NumPy, de modo que “la mayoría del código de NumPy puede traducirse a MLX Swift con cambios mínimos”⁴.

David Koski recorre el ejemplo de Mandelbrot. La comparación de computación de arrays frente a Swift puro comienza alrededor del minuto 4:28.

MLX se sitúa junto a la pila numérica de Apple existente en lugar de reemplazarla: Accelerate para las primitivas vectoriales de CPU ajustadas a mano, BNNS para los bloques de construcción de redes neuronales, Metal Performance Shaders para los kernels de GPU directos, y Swift Numerics para el tipo Complex. Recurres a MLX Swift cuando el objetivo es “escribir código matemático con un ojo puesto en el rendimiento” y quieres que el código se parezca a la matemática⁴.

Dos funciones lo hacen posible. La evaluación perezosa (lazy evaluation) construye un grafo de cómputo a medida que escribes operaciones de arrays y no ejecuta nada hasta que llamas a eval o lees un valor, razón por la cual un bucle llama a eval en cada paso para mantener el grafo pequeño. La evaluación perezosa también impulsa la ejecución automática en GPU y la diferenciación automática mediante la transformación de función grad⁴. El ejemplo de Mandelbrot reduce un bucle escalar por píxel a dos líneas (z = z * z + c aplicado a toda la cuadrícula, luego un conteo de iteraciones acotadas), se ejecuta en la GPU de forma predeterminada, y la sesión señala que “es ciertamente posible un 10x más rápido”⁴. Un solucionador de distribución de calor expresa la iteración de Jacobi como una sola llamada a conv2d. El ejemplo de ajuste de curvas usa grad para calcular gradientes exactos sin derivadas escritas a mano, la misma idea detrás del entrenamiento de todo modelo de ML⁴.

MLX Swift es de código abierto bajo una licencia MIT, instalable mediante Swift Package Manager, y uno de cuatro front-ends (Swift, Python, C++ y C) que comparten las mismas operaciones y el mismo modelo de evaluación perezosa, así que puedes “prototipar en Python y enviar en Swift”⁴. El ecosistema incluye mlx-swift (el framework central), mlx-swift-lm (implementaciones de modelos de lenguaje) y mlx-swift-examples (muestras ejecutables de LLM, difusión y entrenamiento)⁴. Para el contexto de ML en el dispositivo que lo rodea, consulta MLX on-device ML on Apple Silicon.

Qué adoptar primero

Ordena el trabajo según quién seas.

Si envías apps y rara vez tocas las perillas de rendimiento del compilador, adopta la ergonomía ahora e ignora el sistema de propiedad. Reemplaza las líneas @available apiladas con anyAppleOS donde tus plataformas se alineen, usa @diagnose para silenciar las advertencias de obsolescencia justo donde estés a mitad de una migración, y echa mano de los selectores de módulo (::) la próxima vez que una dependencia colisione con SwiftUI en un nombre como View¹.

Si mantienes una suite grande de XCTest, activa la interoperabilidad y empieza a escribir hoy las pruebas nuevas en Swift Testing. Mueve los planes de prueba existentes al modo complete para que los problemas entre frameworks sean errores que no puedas pasar por alto, reutiliza tus helpers de XCTest mediante la interoperabilidad en lugar de reescribirlos de entrada, y migra los archivos que tocas más. Mantén la automatización de la interfaz de usuario, las pruebas de rendimiento y las pruebas de excepciones de Objective-C en XCTest¹².

Si escribes código sensible al rendimiento, las adiciones de propiedad son lo principal. Audita las propiedades calculadas calientes que contienen valores grandes y cámbialas de get/set a borrow/mutate. Donde antes bajabas a UnsafePointer, considera Ref/MutableRef, UniqueArray y la Continuation de reanudación única. Mide antes de recurrir a @inline(always) o @specialized, porque el optimizador suele tener razón y forzarlo puede hacer que el binario sea más grande y más lento¹.

Si tu trabajo es del lado del servidor o numérico, los nuevos paquetes son puntos de entrada listos para producción: gRPC Swift te da un cliente tipado y streaming bidireccional a partir de un archivo .proto, y MLX Swift te da computación de arrays acelerada por GPU y diferenciación automática que se lee como la matemática³⁴.

Preguntas frecuentes

¿Cuál es la diferencia entre Swift 6.3 y Swift 6.4?

Apple desarrolló y lanzó ambas en el mismo ciclo de la WWDC26 y las presentó juntas. A grandes rasgos, Swift 6.3 introdujo los selectores de módulo (::) y el atributo @specialized, y entregó el primer SDK oficial de Swift para Android. Swift 6.4 agregó la disponibilidad anyAppleOS, los any/some opcionales sin paréntesis, el protocolo Iterable para los bucles for, los accesores borrow/mutate, @inline(always), el atributo @C para exportar funciones de Swift a C, y las mejoras de depuración de Swift embebido. La sesión cubre las dos como un solo cuerpo continuo de trabajo¹.

¿Tengo que migrar de XCTest a Swift Testing?

No. XCTest todavía se distribuye y todavía funciona, y la recomendación de Apple es incremental: escribe las pruebas nuevas en Swift Testing y migra las viejas a medida que las tocas. La interoperabilidad de frameworks de pruebas permite que ambos coexistan en un mismo target y se llamen entre sí a su API, así que puedes reutilizar los helpers de XCTest desde pruebas de Swift Testing. La automatización de la interfaz de usuario, las pruebas de rendimiento y el código que lanza excepciones de Objective-C permanecen en XCTest¹².

¿Qué hace el nuevo protocolo Iterable que Sequence no hace?

Sequence copia los elementos hacia afuera a medida que itera. Iterable permite que el bucle for tome prestados los elementos en su lugar, así que funciona con elementos no copiables y omite el conteo de referencias en objetos y tipos de copia al escribir. Devuelve los elementos en lotes de spans en lugar de uno a la vez, lo que es más eficiente, y puede lanzar errores durante la iteración. Como tomar prestado prohíbe la mutación, no puedes mutar la colección mientras la recorres en un bucle. Un bucle for prefiere Sequence cuando está disponible y recurre a Iterable¹.

¿Cuándo debería usar MLX Swift en lugar de Accelerate o Metal Performance Shaders?

Usa MLX Swift cuando tu objetivo principal sea escribir código matemático con un ojo puesto en el rendimiento y quieras que el código se lea como la matemática, con ejecución automática en GPU y diferenciación automática mediante grad. Accelerate sigue siendo la opción para las primitivas vectoriales de CPU ajustadas a mano, BNNS para los bloques de construcción de redes neuronales, y Metal Performance Shaders para el acceso directo a los kernels de GPU. MLX se sitúa junto a ellos en lugar de reemplazarlos⁴.

¿gRPC Swift es solo para servicios de backend?

No. La sesión de la WWDC construye una app de iOS como el cliente de gRPC, generando un cliente tipado a partir de un archivo .proto, y muestra RPC unarios además de streaming bidireccional impulsando actualizaciones de UI en vivo. La codificación binaria de Protobuf produce mensajes aproximadamente de la mitad del tamaño del JSON equivalente, lo que ayuda en redes móviles deficientes. Apple también usa gRPC Swift para la comunicación entre procesos y en servicios como Private Cloud Compute, iCloud Keychain y Photos, y el uso compartido de archivos de SharePlay³.

El clúster del ecosistema de Apple

La actualización de Swift de 2026 se entrelaza con el resto de la serie del ecosistema de Apple: el desglose de Swift Testing vs. XCTest sobre el modelo de pruebas, los internals de Observable en SwiftUI que los cambios de concurrencia tocan, de qué está hecho SwiftUI a nivel del framework, y MLX on-device ML on Apple Silicon para el contexto de la computación numérica. El centro de todo ello es la serie del ecosistema de Apple. Para construir apps de iOS con agentes de IA en el ciclo, consulta la guía de desarrollo de agentes en iOS.

Referencias