Xcode 27 ya salió: requisitos, deployment targets y lo que se rompió

Xcode 27 salió el 14 de septiembre de 2026 como build 27A266a, tres días después del ítem “iOS 27.0 RC” del feed y junto con iOS 27.0 (24A437), macOS 27.0 (26A428) y el resto de las plataformas 27; App Store Connect empezó a aceptar ese mismo día builds hechos con los SDK 27.0 finales (GA), después de haber recibido builds con los SDK RC desde el 9 de septiembre.¹⁵ Requiere macOS Tahoe 26.6 o posterior y una Mac con Apple silicon, incluye Swift 6.4 y los SDK 27, depura dispositivos con iOS 17 o posterior, y sube tres pisos de despliegue: macOS 12, watchOS 9 y DriverKit 21.²³ Para los proyectos existentes trae tres fallos duros (la macro @State, una ruptura de código fuente por SE-0508 y el flag de enlazado -ld64), una regla del escaneo de dependencias que puede dar error, un cambio silencioso en ARCHS_STANDARD y dos advertencias; abajo ejecuto en 27A266a todo menos la regla del escaneo.²⁴⁶ {.answer-block}

TL;DR

• Fechas y builds. El feed de lanzamientos de Apple lista Xcode 27 (27A266a) y los seis sistemas operativos 27.0 el lunes 14 de septiembre; su ítem “iOS 27.0 RC (24A437)” lleva fecha del viernes 11 de septiembre, dos días después de que App Store Connect empezara a recibir subidas con el SDK RC, y la versión GA lleva el mismo número de build.¹⁵ Las propias notas de App Store Connect del 14 de septiembre dicen que ya puedes subir apps compiladas con Xcode 27 tanto para la tienda como para TestFlight.⁵
• Se movieron los requisitos y los pisos. Xcode 26.6 corría en macOS 26.2 y depuraba dispositivos con iOS 15; Xcode 27 necesita macOS 26.6, corre solo en Apple silicon y depura iOS 17, tvOS 17 y watchOS 10 o posteriores, tanto en el simulador como en hardware. Los deployment targets mínimos suben de macOS 11 a 12, de watchOS 8 a 9 y de DriverKit 20 a 21; iOS, iPadOS y tvOS se quedan en 15, y visionOS en 1.²³
• Tres fallos duros. La macro @State: el propio ejemplo de Apple, un inicializador que asigna una propiedad @State con valor en la declaración antes que las demás propiedades almacenadas, falla con variable 'self.title' used before being initialized; una propiedad computada con un literal de array o diccionario como valor inicial y un accessor init no compila cuando el getter va primero, una ruptura de código fuente que Apple atribuye a SE-0508; y el flag de enlazado -ld64, que Xcode 15 documentó, hace fallar el enlace con ld: library 'd64' not found.²⁴⁶⁸
• Cuatro cambios que advierten, pueden dar error o no dicen nada. El enlazador ignora -ld_classic con una advertencia porque ld64 ya no existe; los nombres duplicados de módulos Clang dentro de un mismo escaneo de dependencias “may report an error” (pueden reportar un error); un target solo para macOS fijado en 27.0 compila únicamente arm64 a menos que agregues x86_64 de vuelta, y nada avisa; y PreviewProvider lleva una deprecación en 27.0 con “Use #Preview instead.” mientras cada modificador de vista previa lleva su propio mensaje de reemplazo, y el compilador no muestra ninguno por debajo de un deployment target 27.0.²⁴
• Apple no ha publicado Xcode 27.1 al 15 de septiembre. Ni el feed de lanzamientos ni el índice de notas de la versión lo listan, y la página para desarrolladores de iPhone Duo de Apple todavía fecha la beta de 27.1 “later this month” (a finales de este mes); la brecha de SDK que describí en mi post sobre Duo para desarrolladores sigue vigente.¹

¿Qué se lanzó el 14 de septiembre?

La sección Overview de las notas de la versión dice: “Xcode 27 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27 requires a Mac running macOS Tahoe 26.6 or later.” (Xcode 27 incluye Swift 6.4 y los SDK 27, depura en dispositivo desde iOS 17, tvOS 17 y watchOS 10, y requiere una Mac con macOS Tahoe 26.6 o posterior.)² En esta Mac, xcodebuild -version imprime Xcode 27.0 Build version 27A266a y swift --version imprime Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).⁴

¿Qué requiere Xcode 27 en comparación con 26.6?

La tabla de compatibilidad de Apple es el documento que conviene revisar antes de actualizar una máquina de compilación. Las dos filas, lado a lado:³

Detrás de esas filas se esconden dos consecuencias. Instruments ahora rechaza dispositivos anteriores a iOS 17, watchOS 10 o tvOS 17, así que un equipo de perfilado montado sobre un iPhone viejo deja de funcionar antes que cualquier línea de la app.² Y Apple acota las interacciones de teclado y puntero del Device Hub con una sola frase: “only supported on the following OS versions and newer: macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0.” (solo se admiten en esas versiones o posteriores).²

El requisito de Apple silicon no tiene rodeo para la Mac en la que ejecutas Xcode, y no es novedad para quien leyó el post sobre Intel en julio; las notas GA conservan íntegra la redacción de julio: “Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27.” (Xcode 27 solo se instala y ejecuta en Macs con Apple silicon; el SDK de macOS 27 permite desplegar apps Universal hasta macOS 12; desarrollar para Intel sigue siendo posible con versiones de macOS que admiten Rosetta, como macOS 27.)² La tercera frase es el rodeo para las Macs a las que distribuyes, no para la que usas para compilar.

¿Qué cambió en la cadena de herramientas?

El enlazador. Las notas GA lo dicen en una frase: “The ld64 linker has been removed and the -ld_classic option is no longer supported.” (se eliminó el enlazador ld64 y la opción -ld_classic ya no se admite).² Así se ve en 27A266a: el usr/bin de la cadena de herramientas contiene un solo binario de enlazador, ld, que se identifica como ld-27037.1, compilado el 25 de agosto de 2026. Pasar el flag viejo no hace fallar el enlace. Con un hello.c que contiene la única línea int main(void){return 0;}, clang hello.o -o hello_classic -Xlinker -ld_classic imprime ld: warning: -ld_classic is no longer supported and will be ignored, sale con 0 y escribe el ejecutable. A la otra forma que Apple documentó en Xcode 15, -ld64, le va peor:⁸ clang hello.c -o hello_ld64 -Wl,-ld64 falla con ld: library 'd64' not found y sale con 1, porque el nuevo enlazador lee -ld64 como -l d64, una petición de una biblioteca llamada d64.⁴ Así que un proyecto que lleva -ld_classic en OTHER_LDFLAGS sigue compilando, con una advertencia nueva en cada enlace, y cualquier comportamiento que obtenía del enlazador viejo desapareció; un proyecto que lleva -ld64 deja de enlazar, con un error que nunca menciona al enlazador. Mi post sobre ld64 audita de dónde salieron esos flags y registra ambas ejecuciones.

Las arquitecturas por defecto. La sección Intel Deprecation enuncia la regla: “Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0.” (los targets con deployment target mínimo 27.0 en macOS o DriverKit ya no compilan en Universal por defecto, porque ARCHS_STANDARD deja de incluir x86_64).² Lo reproduje en un proyecto multiplataforma (Yawara, con SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx xros xrsimulator) con xcodebuild -showBuildSettings -sdk macosx; sin el argumento -sdk el proyecto no resuelve ningún ARCHS_STANDARD, un detalle que cubre el post sobre Intel. Con MACOSX_DEPLOYMENT_TARGET = 26.0 el ajuste se resuelve como ARCHS_STANDARD = arm64 x86_64; con 27.0 se resuelve como ARCHS_STANDARD = arm64, mientras ARCHS_STANDARD_64_BIT se mantiene en arm64 x86_64 en ambos casos.⁴ Nada avisa. Si distribuyes en Universal y subes el target, agrega x86_64 a ARCHS tú mismo.

La biblioteca estándar de C++. “The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0,” (el deployment target mínimo de la biblioteca estándar de C++ en macOS sube a 11.0) y las notas listan cambios de comportamiento bajo “Potentially breaking changes,” empezando por multi{map,set}::find, que ya no devuelve necesariamente el primer elemento coincidente.² La lista de novedades es larga: hashing para valores de std::chrono, zip, std::optional<T&>, std::views::indices(n) y más.²

El escaneo de dependencias, y la regla que puede hacerlo fallar. Apple dice que optimizó el escáner de dependencias de Swift “to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action,” (para evitar trabajo de preparación y búsquedas de cabeceras redundantes al resolver módulos Clang dentro de una misma acción de escaneo) y la mejora de velocidad trae un requisito: “every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error. Previously, the scanner may have tolerated duplicating names.” (todo módulo Clang alcanzable desde un mismo escaneo debe tener un nombre único; si dos module maps visibles en el mismo escaneo declaran un módulo con el mismo nombre, el escaneo puede reportar un error, algo que antes quizá se toleraba).² Apple nombra las dos formas que lo disparan: “projects or SDKs that vend the same Clang module name from more than one location on the header search path, and vendored third-party sources that ship a module.modulemap redeclaring an SDK module.” (proyectos o SDK que exponen el mismo nombre de módulo Clang desde más de una ubicación de la ruta de búsqueda de cabeceras, y fuentes de terceros incorporadas al proyecto que traen un module.modulemap que redeclara un módulo del SDK).² Igual que la eliminación del enlazador, la regla se dispara al actualizar la cadena de herramientas y no según el deployment target; mi post sobre ld64 pasa dos module maps en colisión por el escáner, compila un shim de SQLite3 incorporado que oculta el módulo del SDK y audita siete proyectos en busca de ambas formas.

¿Qué deja de compilar?

La macro @State. El cambio vive en las notas de la versión de iOS 27, no en las de Xcode, y depende del compilador con el que compilas, no del target al que despliegas: “Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.” (Xcode 27 introduce una nueva implementación de @State como macro de Swift, que se despliega hacia atrás hasta los sistemas alineados con iOS 17 y es en gran medida compatible a nivel de código fuente con la versión de property wrapper, con algunas excepciones.)⁶ Apple nombra cuatro excepciones y da listados de código para dos de ellas; las otras dos reciben una o dos frases cada una: “In rare situations, the automatic inference of generic arguments of @State is less flexible with the macro implementation. Write the type with more specificity.” (en casos raros la inferencia automática de argumentos genéricos de @State es menos flexible con la macro; escribe el tipo con más precisión) y “Composing @State with other property wrappers or macros is not supported.” (no se admite combinar @State con otros property wrappers o macros).⁶ Las dos con listados son las que atrapan al código existente. Un inicializador que asigna una propiedad @State que ya tiene valor en la declaración: SwiftUI siempre descartó esa asignación, y ahora “some such cases no longer compile.” (algunos de esos casos ya no compilan).⁶ Y el inicializador memberwise privado que el compilador sintetiza cuando todos los miembros almacenados son privados: “The state macro disables this synthesized initializer. So the code above no longer compiles.” (la macro desactiva ese inicializador sintetizado, así que el código de arriba ya no compila).⁶ En 27A266a el primer ejemplo falla tal cual está escrito, con error: variable 'self.title' used before being initialized en la línea que asigna page, porque el setter de la macro corre contra self antes de que exista title; mueve self.title = title por encima y el mismo archivo compila, con la asignación a @State descartada como antes.⁴⁶ El segundo ejemplo, una extensión que llama a self.init(page: page, title: title) sobre un struct cuyo @State no tiene valor en la declaración, compiló sin cambios en mi ejecución, y la expansión de la macro muestra la forma que lo permite: la macro emite private var _page: SwiftUICore.State<StickerPage> detrás de un accessor init con @storageRestrictions(initializes: _page), la construcción que deja que un inicializador memberwise reciba page:.⁴ Lee la nota como una descripción de formas que conviene revisar, y luego confirma cada una en tu propio código. El post sobre la macro @State cuenta ambos patrones en cuatro apps publicadas; lo escribí a partir de las notas de la beta en julio, antes de esta prueba GA, y su pregunta abierta también se cierra aquí: asignar el almacenamiento de respaldo directamente, _page = State(initialValue:) dentro de un inicializador, compila en 27A266a tanto con valor en la declaración como sin él.⁴

La ruptura por SE-0508. Bajo Swift Compiler, Known Issues: “A computed property with both an init accessor and an array/dictionary literal initial value will no longer compile if the getter is declared before the init accessor.” (una propiedad computada con un accessor init y un literal de array o diccionario como valor inicial ya no compila si el getter se declara antes del accessor init). Sigue un listado de código y luego la atribución: “This is a known source break from SE-0508.” La solución, completa: “Swap the init accessor and the getter such that the init accessor is declared first.” (intercambia el accessor init y el getter para que el init quede primero).² SE-0508 es “Array expression trailing closures”, implementada en Swift 6.4, y la propuesta predice exactamente este caso: “If the getter is declared before the init accessor, we will now attempt to parse as a trailing closure,” (si el getter va antes del accessor init, ahora se intentará interpretar como trailing closure) y agrega que “init accessors are however considered for disambiguation, so swapping the accessors is sufficient to make this valid regardless of initial value used,” (los accessors init sí cuentan para la desambiguación, así que intercambiarlos basta para que sea válido sin importar el valor inicial) y que el caso “does not appear in the source compatibility suite, or for internal Swift projects at Apple.” (no aparece en la suite de compatibilidad de código fuente ni en los proyectos internos de Swift en Apple).⁷ Se reproduce con un struct de nueve líneas. Con el getter primero, swiftc falla en la línea del accessor con error: initializers may only be declared within a type; mueve el accessor init con @storageRestrictions(initializes:) por encima de get y el mismo archivo compila.⁴

struct Container {
    private var storage: [Int] = []
    var items: [Int] = [] {
        @storageRestrictions(initializes: storage)
        init(initialValue) { storage = initialValue }   // debe ir antes de get
        get { storage }
        set { storage = newValue }
    }
}

PreviewProvider. La sección Previews lista una deprecación: “PreviewProvider and its family of preview modifiers.” (PreviewProvider y su familia de modificadores de vista previa).² El SDK la lleva, con un mensaje para el protocolo y otro distinto para cada modificador. En la interfaz de SwiftUI del SDK de iOS 27, public protocol PreviewProvider está bajo @available(anyAppleOS, deprecated: 27.0, message: "Use #Preview instead."); previewLayout dice “Use #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:) instead.”; previewDisplayName dice “Use #Preview(“name”) instead.”; previewInterfaceOrientation dice “Use #Preview(traits: .landscapeLeft) or other orientation traits instead.”; previewDevice dice “Use the device picker in Xcode’s canvas.” (usa el selector de dispositivo del canvas de Xcode); y previewContext, junto con los protocolos PreviewContext y PreviewContextKey, dice “Use #Preview with a Widget timeline provider or entries instead.” (usa #Preview con un timeline provider o entradas de Widget).⁴ Dos hechos deciden si alguna vez ves esos mensajes. El compilador compara la versión de la deprecación con el deployment target, así que los modificadores solo advierten en un target cuyo mínimo sea 27.0: un archivo que usa previewLayout, previewDisplayName y previewDevice produjo tres advertencias con -target arm64-apple-ios27.0-simulator y ninguna con 17.0 ni 26.0. Y PreviewProvider en sí nunca advierte, por una razón distinta. El SDK lo declara con @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) justo encima de la deprecación anyAppleOS, y en mi prueba un protocolo con ese par no produjo advertencia alguna, ni por conformar a él ni por usarlo como tipo de parámetro, con target 27.0, mientras que el mismo protocolo deprecado solo con @available(iOS, deprecated: 27.0), o solo con la forma anyAppleOS, advirtió en ambos casos; los modificadores llevan únicamente la deprecación anyAppleOS en sus propias declaraciones (la extension SwiftUICore.View que los contiene lleva el atributo de introducción, y esa forma heredada no suprime la advertencia), y por eso ellos advierten y el protocolo no.⁴ Con cualquier deployment target que realmente distribuyas, el log de compilación queda en silencio en ambos casos, así que busca PreviewProvider y los modificadores y pásate a #Preview, que el canvas ahora renderiza en cuadrículas por argumento gracias a la nueva sintaxis #Preview(arguments:).²⁴

El nuevo stat() de System. La biblioteca System ahora ofrece API de Swift para stat, lstat, fstat y fstatat, con un tipo Stat y métodos de instancia FilePath.stat().² Las notas listan como resuelto un conflicto en el que una extensión que llamaba a un stat() sin calificar chocaba con los métodos nuevos; si agregaste la calificación Darwin. mientras ese conflicto estaba vivo, puede quedarse.²

Address Sanitizer, en la dirección contraria. “Address Sanitizer might fail to launch on iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 when building with Xcode 26.4 or older.” (Address Sanitizer puede no arrancar en los sistemas 27.0 cuando se compila con Xcode 26.4 o anterior). La solución es Xcode 26.5 o posterior, lo cual importa para los equipos que mantienen un Xcode más viejo en la máquina de CI mientras los dispositivos se actualizan a 27.0.²

¿Qué cambió en el IDE y en las herramientas?

• Interface Builder compila sin simulador. Un nuevo modo de compilación, toolchain, “for UIKit (Cocoa Touch) based documents. Enabled by default, toolchain allows compiling IB documents without the need to download a simulator, which is especially useful for build servers.” (para documentos basados en UIKit; activado por defecto, permite compilar documentos de IB sin descargar un simulador, algo especialmente útil en servidores de compilación).²
• Los simuladores arrancan más rápido, y se reinician. “The simulator runtimes now contain a pre-built dyld cache. This will make first launch of a simulator much faster,” (los runtimes del simulador ahora traen una caché de dyld preconstruida, así que el primer arranque es mucho más rápido) y simctl gana un comando reboot.² Un problema conocido sobrevive, en palabras de Apple: “Some simulator runtimes are not completely deleted when removed, re-appearing after a reboot.” (algunos runtimes del simulador no se borran del todo al eliminarlos y reaparecen tras un reinicio).²
• El JSON de devicectl va por la versión 5. xcrun devicectl --version reporta 642.16 y list devices --json-output escribe "jsonVersion": 5; Apple marca como obsoletos los campos hardwareProperties, deviceProperties y connectionProperties en favor de un diccionario properties, y cualquier resultado que todavía los contenga lleva un _deprecationNotice.²⁴
• Pruebas de StoreKit. La interfaz de configuración de StoreKit puede definir códigos de oferta, puedes configurar paquetes de suscripciones para pruebas locales, y el Transaction Manager puede ejercitar compras con códigos de oferta sin dispositivo.²
• Organizer. Un Insights Overview “summarizes high-impact performance regressions,” (resume las regresiones de rendimiento de alto impacto) y una métrica Hitches reemplaza a la métrica Scrolling.²
• Asistente de código. Google Gemini se suma a la lista de modelos, y “Planning with agents is now first class in Xcode,” (planificar con agentes ya es una función de primera clase en Xcode) con planes como artefactos Markdown editables que apruebas antes de que el agente continúe; mi post sobre agentes de código cubre el flujo desde la beta, y las notas GA listan un editor de Markdown justo para esos artefactos.²
• Localización. Los agentes pueden traducir entradas de String Catalog, y exportar localizaciones ahora extrae NSLocalizedString y macros similares desde archivos de cabecera.²
• Icon Composer. Las notas lo llaman Icon Composer 2.0, “a new sharper rendering mode for upcoming 2027 operating systems” (un nuevo modo de renderizado más nítido para los sistemas operativos de 2027); el bundle dentro de 27A266a reporta la versión 27.0.²⁴
• Pruebas. Un test plan puede definir cómo trata Xcode un crash de la app objetivo durante las pruebas de UI, desde desactivado hasta fallo fatal, y swift test gana --maximum-repetitions con --repeat-until [pass|fail] más un resumen de fallos al final.²
• Depuración. Con bridging headers, LLDB “can now directly import explicitly built Swift modules and PCH from DerivedData,” (ahora puede importar directamente desde DerivedData los módulos Swift construidos explícitamente y los PCH) y un comando language swift task tree lista las tareas de concurrencia de Swift.²

Qué haría yo esta semana

1. Lee las filas de compatibilidad antes de tocar CI: macOS 26.6 en las Macs de compilación, solo Apple silicon, iOS 17 como dispositivo de prueba más viejo, y el piso de macOS 12, watchOS 9 o DriverKit 21 que le toque a tu producto.²³
2. Haz grep de -ld_classic y -ld64 y elimina ambos; el enlazador ignora el primero con una advertencia en cada enlace y falla de plano con el segundo. Ya que estás en los ajustes de compilación, busca archivos module.modulemap escritos a mano que redeclaren un módulo del SDK, la forma que Apple nombra para la regla del nombre de módulo único.²⁴
3. Si fijas cualquier target de macOS o DriverKit en 27.0 y distribuyes para Intel, define ARCHS explícitamente; ARCHS_STANDARD por sí solo te da arm64, algo que reproduje para macOS y que Apple afirma para ambos.²⁴
4. Busca PreviewProvider, previewLayout, previewDisplayName y previewDevice, y sigue el mensaje propio de cada anotación: el protocolo a #Preview, previewLayout a #Preview(traits: .sizeThatFitsLayout) o .fixedLayout(width:height:), previewDisplayName a #Preview("name") y previewDevice al selector de dispositivo del canvas. Los modificadores solo advierten con un deployment target 27.0 y la conformancia a PreviewProvider nunca advierte con ningún target, así que el log de compilación de un target real se queda en silencio.⁴
5. Compila una vez con Xcode 27 y lee dos diagnósticos: variable 'self.title' used before being initialized en un inicializador que asigna una propiedad @State que ya trae valor en la declaración antes que las demás propiedades almacenadas, que el post sobre la macro @State recorre paso a paso, y initializers may only be declared within a type en propiedades con un literal de array o diccionario como valor inicial y un accessor init, donde mueves el accessor por encima del getter.²⁴⁶
6. Sube un build a TestFlight con los SDK 27 ahora que App Store Connect los acepta, y ten presentes la regla de la launch screen y el mandato de escenas de UIKit, porque ambos obligan a la app desde el momento en que enlaza contra 27.⁵⁶

Preguntas frecuentes

¿Cuándo salió Xcode 27?

El lunes 14 de septiembre de 2026, como build 27A266a, el mismo día que iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0 y watchOS 27.0; el feed fecha su ítem iOS 27.0 RC (24A437) el 11 de septiembre, dos días después de que App Store Connect empezara a recibir builds con el SDK RC.¹⁵

¿Qué macOS requiere Xcode 27?

macOS Tahoe 26.6 o posterior en una Mac con Apple silicon. No se instala ni se ejecuta en Macs con Intel. Corre en macOS 27.0, que salió el mismo día.²³

¿Cuáles son los deployment targets mínimos en Xcode 27?

iOS 15, iPadOS 15, tvOS 15, watchOS 9, visionOS 1, macOS 12 y DriverKit 21. En comparación con Xcode 26.6, watchOS subió desde 8, macOS desde 11 y DriverKit desde 20.³

¿Xcode 27 sigue compilando apps Universal para Mac?

Sí, hasta macOS 12, pero no por defecto una vez que el MACOSX_DEPLOYMENT_TARGET de un target es 27.0: ARCHS_STANDARD entonces se resuelve solo como arm64, y tú mismo agregas x86_64 a ARCHS.²⁴

¿Ya salió Xcode 27.1?

No al 15 de septiembre de 2026. El feed de lanzamientos de Apple y el índice de notas de la versión de Xcode listan solo Xcode 27, y la página para desarrolladores de iPhone Duo de Apple sigue listando la beta de Xcode 27.1 como “Coming later this month” (disponible a finales de este mes); el SDK de iPhone Duo no forma parte de esta versión.¹

¿Dónde están las notas de la versión de Xcode 27?

En el sitio de documentación para desarrolladores de Apple, bajo Xcode Release Notes, una página para la versión; las secciones citadas aquí son Overview, Linking, Intel Deprecation, Previews, Swift Compiler, Address Sanitizer, Instruments, Device Hub, devicectl, Simulator, Interface Builder, C++ Standard Library, Organizer, Coding Intelligence, Source Editor, Icon Composer, StoreKit Testing in Xcode, Localization, Testing, Swift Package Manager, Debugging y System.² El cambio de la macro @State está, en cambio, en las notas de la versión de iOS y iPadOS 27, bajo SwiftUI.⁶

Fuentes