Swift 7: qué se sabe realmente tras Swift 6.4 y qué es pura especulación

Circula por Medium y otros sitios una pieza titulada «Why Swift 7 Could Be Apple's Biggest Update Ever», firmada el 20 de julio de 2026, que presenta Swift 7 como algo casi inminente: fin del modo Swift 5, tipos no copiables estabilizados, genéricos variádicos ampliados y «cambios de ruptura revisados» que se remontan a Swift 3. Conviene separar lo que ese texto acierta de lo que da por hecho sin fuente. A día de hoy, 10 de noviembre de 2026, Swift 7 no existe, no tiene fecha y no hay un anuncio oficial de que vaya a llegar con ninguna de esas medidas. Lo que sí hay es una hoja de ruta bastante visible en las propuestas de Swift Evolution y en las versiones 6.2, 6.3 y 6.4, y de ahí se pueden sacar conclusiones razonables.

Dónde estamos: Swift 6.4, no Swift 7

La última versión estable es Swift 6.4, publicada a mediados de septiembre de 2026 (las fuentes consultadas dan el 14 o el 15 de septiembre). Se presentó en la WWDC26 y la página de instalación de swift.org ya ofrece el parche 6.4.2. Antes llegó Swift 6.3, el 24 de marzo de 2026, y antes Swift 6.2, el 15 de septiembre de 2025. Hay un error en el texto de Medium: afirma que 6.3 y 6.4 salieron con menos de dos semanas de diferencia, cuando entre una y otra pasaron casi seis meses.

Tampoco aparece Swift 7 en el material oficial: ni en la sesión «What's new in Swift» de la WWDC26, ni en el boletín de junio de 2026 de swift.org, ni en el anuncio de Swift 6.3, ni en la cobertura de prensa del lanzamiento de 6.4. La propia sesión de Apple dice que muchas de las novedades siguen en progreso, sobre todo las de propiedad (ownership), y no menciona ni una 6.5 ni una 7.

Qué trajeron realmente 6.2, 6.3 y 6.4

Swift 6.2 (septiembre de 2025): concurrencia más accesible

Swift 6.2 introdujo la llamada «concurrencia accesible» (approachable concurrency): aislamiento al actor principal por defecto como opción para código de interfaz, scripts y ejecutables; funciones asíncronas que se ejecutan en el contexto de quien las llama; y el atributo @concurrent para marcar de forma explícita el código que debe correr en el pool concurrente. Añadió además InlineArray (un array de tamaño fijo con almacenamiento en línea, con la sintaxis [40 of Sprite]), Span para acceso seguro a memoria contigua, comprobaciones opt-in de seguridad de memoria estricta y soporte de WebAssembly.

Swift 6.3 (24 de marzo de 2026): interoperabilidad y plataformas

• Atributo @c: expone funciones y enumeraciones de Swift a C y genera la declaración de cabecera. Combinado con @implementation permite implementar en Swift una función declarada en una cabecera C, lo que facilita migrar bases de código C de forma gradual.
• Selectores de módulo con :: (por ejemplo ModuleA::getValue()) para resolver conflictos de nombres.
• Atributos de rendimiento para bibliotecas: @specialize, @inline(always) y @export(implementation).
• Swift SDK para Android, el primero oficial, con herramientas para integrar Swift en apps Kotlin/Java existentes.
• Swift Build integrado en Swift Package Manager en fase de vista previa, mejoras en Embedded Swift y novedades en Swift Testing (Test.cancel(), severidad en Issue.record, adjuntos de imagen).

Swift 6.4 (septiembre de 2026): ownership y menos fricción

Swift 6.4 incorpora 26 propuestas de Swift Evolution según el seguimiento de SwiftLee Weekly. Las más relevantes para el rumbo del lenguaje son estas:

• Concurrencia: SE-0493 permite código asíncrono dentro de defer; SE-0504 añade el «escudo» de cancelación de tareas (withTaskCancellationShield); SE-0518 introduce ~Sendable para marcar de forma explícita que un tipo no es Sendable; SE-0520 avisa cuando se ignora un error lanzado por una tarea; SE-0528 convierte en error de compilación el descarte de una continuación, que hasta ahora era un fallo en tiempo de ejecución.
• Ownership y tipos no copiables: SE-0507 añade los accesores borrow y mutate; SE-0516 el protocolo Iterable, que permite bucles for-in con tipos no copiables; SE-0517 UniqueBox; SE-0519 Ref y MutableRef; SE-0527 RigidArray y UniqueArray; SE-0499 permite ~Copyable y ~Escapable en protocolos simples de la biblioteca estándar. Además, los tipos no copiables ya pueden ser Equatable, Comparable y Hashable.
• Sintaxis: SE-0521 permite escribir some P? y any P? sin paréntesis; SE-0522 introduce el control de avisos a nivel de código fuente con @diagnose; llega el selector de módulo ::; y anyAppleOS sustituye a la lista de plataformas en las comprobaciones de disponibilidad.
• Herramientas: Swift Build pasa a ser el motor de compilación por defecto en SwiftPM, hay generación de SBOM (SE-0509) y Subprocess llega a la versión 1.0.
• WebAssembly: el puente con JavaScript mediante JavaScriptKit es entre 35 y 40 veces más rápido en los benchmarks que Goodnotes mostró en la WWDC.

Un detalle que el texto de Medium recoge a medias: lo de «quitar paréntesis alrededor de opcionales» es SE-0521, y es cierto que es una mejora de ergonomía menor. Lo que no cuadra es presentarlo, junto con @diagnose, como «lo que de verdad llegó» y de ahí inferir el contenido de Swift 7; son simplemente las partes más visibles de una versión con muchas piezas.

Dos ejemplos rápidos de la 6.4 en código:

// SE-0493: await dentro de defer
func procesar(_ sesion: Sesion) async throws {
    defer {
        await sesion.cerrar()
    }
    try await sesion.enviar(datos)
}

// Disponibilidad con anyAppleOS (sesión WWDC26)
@available(anyAppleOS 27, *)
func mostrarEstado() { /* ... */ }

// Accesores borrow y mutate (SE-0507), ejemplo de la sesión WWDC26
public var value: Value {
    borrow { valuePointer.pointee }
    mutate { &valuePointer.pointee }
}

Las cuatro afirmaciones sobre Swift 7, una a una

1. «El fin del modo Swift 5»

Es la afirmación más delicada y la menos respaldada. Swift tiene modos de lenguaje (formalizados en SE-0441) precisamente para poder introducir cambios que rompen el código fuente sin romper a quien no ha migrado. Swift 6 introdujo el modo de lenguaje 6, con comprobación estricta de carreras de datos, pero el modo Swift 5 sigue existiendo y sigue siendo el valor por defecto en compilaciones sin configurar: en los foros de Swift se explica que mantener -swift-version 5 por defecto es la única opción que no compromete la compatibilidad de código existente. Hay hilos y propuestas que dan por hecho que en algún momento llegará un modo 7 y que modos antiguos se retirarán, pero son conjeturas de usuarios, no un plan anunciado. De hecho, la tendencia de los últimos años va en sentido contrario al de «cerrar la puerta»: Swift 6.2 y 6.4 añaden herramientas de migración, avisos y funciones opt-in para que el paso a datos sin carreras sea gradual.

Lo razonable: un hipotético modo 7 podría activar por defecto parte de lo que hoy es opt-in, pero eliminar el modo 5 de golpe contradiría la política de estabilidad de código fuente del proyecto. No hay evidencia pública de que se vaya a hacer.

2. «Tipos no copiables, estabilizados»

Aquí el texto va por delante de la realidad en el matiz, pero no en la dirección. ~Copyable llegó en Swift 5.9 y se extendió a los genéricos en Swift 6.0, y no está en un estado «experimental»: se usa en producción, y en la biblioteca estándar ya hay Span, InlineArray, UniqueBox, UniqueArray o Ref. Lo que sigue en marcha es completar el ecosistema alrededor: iteración, accesores, protocolos con soporte, contenedores. Eso es precisamente lo que ha traído 6.4 y lo que SE-0474 (accesores yielding, aceptada en 2026) y SE-0527 siguen empujando. Esto no necesita esperar a un Swift 7; llega en versiones 6.x.

El ejemplo de «gestor de ficheros» del artículo de Medium, con un descriptor de fichero cuyo cierre consume el valor, es un buen caso de uso. Una versión mínima y correcta sería:

import Darwin

struct DescriptorFichero: ~Copyable {
    private let fd: Int32

    init(fd: Int32) { self.fd = fd }

    consuming func cerrar() {
        Darwin.close(fd)
        discard self
    }
}

Con consuming el compilador impide usar el descriptor después de cerrarlo, y discard self evita ejecutar un deinit que no existe aquí. Es el tipo de API que Swift 6.4 hace cada vez más cómoda de usar.

3. «Genéricos variádicos más allá de los parameter packs»

Los parameter packs ya existen: llegaron en Swift 5.9 (SE-0393) y se completaron después con iteración sobre packs. No he encontrado ninguna propuesta aceptada o en revisión que describa unos «genéricos variádicos más allá de los parameter packs»; el texto de Medium no cita ninguna. Es posible que esté refiriéndose a mejoras incrementales sobre packs, pero tal como está redactado no se puede verificar.

4. «Cambios de ruptura revisados desde Swift 3»

No hay constancia pública de una iniciativa así. Swift Evolution sí discute de forma continua qué cambios requieren un nuevo modo de lenguaje, pero la afirmación de que decisiones de Swift 3 se reabren para Swift 7 carece de fuente. Si te interesa seguirlo de primera mano, el lugar es la sección de propuestas y el foro oficial, no un resumen de terceros.

Hacia dónde apunta el lenguaje de verdad

Aunque Swift 7 no esté sobre la mesa, la dirección general sí se ve en lo que Apple y la comunidad están construyendo:

• Swift como lenguaje de sistemas. Apple dijo en la WWDC26 que usa Swift «en todas las partes del sistema operativo», incluido el kernel y hasta las capas más bajas del firmware. El boletín de junio detalla que el transporte QUIC de su pila de red se reescribió en Swift (y se publicó como swift-nio-quic) y que el intérprete de hinting de TrueType de macOS e iOS se migró de C a Swift, con un 13 % más de velocidad de media.
• Multiplataforma. Android tiene SDK oficial desde 6.3, Windows y WebAssembly avanzan, y se han creado grupos de trabajo para networking, build y empaquetado y Windows. El Swift Package Index se ha incorporado a Apple y sigue siendo de código abierto.
• Seguridad de memoria sin recolector. La combinación de Span, tipos no copiables y modo estricto de memoria insegura va en la línea de lo que Rust ofrece, y ya lo comentamos en ¿Se está convirtiendo Swift en el Rust de Apple?.
• Concurrencia sin fricción. 6.2 redujo el coste de adopción con el aislamiento por defecto; 6.4 sigue limando asperezas (~Sendable, weak let, escudo de cancelación). La comprobación estricta de carreras de datos del modo 6 sigue siendo el objetivo; el camino para llegar es gradual.

Qué hacer ahora mismo

La recomendación del texto original, migrar sin esperar, es acertada aunque su justificación («Swift 7 lo hará obligatorio») no esté demostrada. Con lo que existe hoy:

• Activa el modo de lenguaje 6 por targets, empezando por los módulos pequeños, y usa las upcoming features con las herramientas de migración de 6.2 en adelante para que el compilador te proponga las correcciones.
• Para apps de interfaz, valora el aislamiento al actor principal por defecto de 6.2 en lugar de anotar @MainActor por todas partes.
• Identifica en tu código recursos que deban tener propiedad única (descriptores, sockets, buffers) y plantéalos como ~Copyable, apoyándote en los nuevos contenedores y accesores de 6.4.
• Sigue el repositorio swift-evolution y el foro: ahí se discuten las propuestas meses antes de que lleguen al compilador, y es la única forma fiable de enterarte de un hipotético cambio de modo.

Conclusión

Swift 7 es, hoy por hoy, una expectativa y no un proyecto anunciado. Lo comprobable es que el lenguaje avanza por versiones 6.x con cadencia anual (septiembre), que el trabajo de fondo está en ownership, concurrencia segura e interoperabilidad, y que el modo Swift 5 sigue vivo. Cualquier artículo que dé fechas o contenidos concretos de Swift 7 está especulando, y conviene leerlo como tal.

Fuentes

• Swift.org: Swift 6.2 Released
• Swift.org: Swift 6.3 Released
• Swift.org: What's new in Swift, June 2026
• Apple: What's new in Swift (WWDC26, sesión 262)
• SwiftLee Weekly: Swift 6.4 y sus 26 propuestas
• InfoQ: Swift 6.4 released
• SE-0441: modos de lenguaje
• Foro Swift: versión de lenguaje por defecto

Imagen: Pexels / Daniil Komov