Xcode 27 abandona Intel: qué se detiene y qué se sigue publicando

Todo lo anterior lo publica Apple como texto en beta, en las notas de versión de Xcode 27 beta 4 y de macOS 27 beta 4.³⁶

Apple clasificó bajo Novedades, y no bajo Obsolescencias, el cambio relacionado con Intel que más probablemente altere un binario que ya publicas. Las notas de versión de Xcode 27 incluyen una sección titulada Intel Deprecation con exactamente dos entradas, y la que impide que una app de macOS se compile como Universal por defecto está del lado de Novedades.¹²

En resumen

• Detrás del titular se esconden tres cambios distintos, y las propias frases de Apple los mantienen separados. Xcode 27 se instala y se ejecuta únicamente en Macs con Apple silicon.² El SDK de macOS 27 sigue permitiendo que las apps Universal lleguen a macOS 12 y posteriores.² Y ARCHS_STANDARD deja de incluir x86_64 en cuanto el deployment target de macOS o DriverKit de un target llega a 27.0.¹
• Solo el tercero cambia lo que publicas, y lo cambia sin ningún diagnóstico. Apple indica la solución en esa misma entrada: “The x86_64 architecture can be added to the ARCHS build setting if this is needed.”¹
• Xcode 26.6 no permite anticipar el nuevo comportamiento. Forcé MACOSX_DEPLOYMENT_TARGET=27.0 en un proyecto exclusivo de macOS y ARCHS_STANDARD siguió resolviéndose como arm64 x86_64.¹³
• Dos hábitos de auditoría fabrican respuestas equivocadas. Pasar -sdk macosx hizo que un proyecto exclusivo de iOS reportara SUPPORTED_PLATFORMS = macosx y ARCHS_STANDARD = arm64 x86_64, y resolver la configuración a nivel de proyecto ocultó dos targets de macOS dentro de un proyecto cuyo target predeterminado es de iOS.¹⁴
• En 11 de mis proyectos de Xcode, que suman 44 targets: 21 se compilan para macOS, el deployment target de macOS más alto entre ellos es 26.5, y ninguno define ARCHS ni EXCLUDED_ARCHS.¹⁴ Los 51 archives de macOS en disco son x86_64 arm64.¹⁴
• El fin del software Intel llega con macOS 28, no con Xcode 27, y la frase de Apple trae una excepción que conviene leer: “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰

Todo lo anterior lo publica Apple como texto en beta, en las notas de versión de Xcode 27 beta 4 y de macOS 27 beta 4.³⁶

Tres frases, tres cambios distintos

La sección Intel Deprecation de Apple tiene dos entradas. Leerlas como una sola afirmación lleva a decisiones equivocadas en ambas direcciones.

La entrada de obsolescencia se refiere a la máquina que tienes sobre el escritorio, y no admite matices: “Xcode 27 will only install and run on Apple silicon Macs.”² Ningún ajuste de compilación cambia eso. Una Mac Intel deja de ser una máquina capaz de ejecutar el Xcode actual, y la tabla de compatibilidad de Apple añade un piso de software sobre el de hardware, al indicar macOS Tahoe 26.4 o posterior como requisito para Xcode 27 beta 4.⁴

Esa misma entrada protege después el resultado: “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² La tabla de compatibilidad de Apple coincide, ya que muestra un rango de deployment de macOS de 12 a 27 para Xcode 27 beta 4 frente a 11 a 26.5 para Xcode 26.6.⁴ El piso subió exactamente una versión. Los binarios Universal sobreviven.

Y la entrada se cierra preservando el flujo de trabajo en sí: “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”²

Viene entonces la entrada de Novedades, que es la capaz de cambiar un producto que ya publicas:

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. The x86_64 architecture can be added to the ARCHS build setting if this is needed.¹

Ahí hay cuatro detalles que conviene separar. Apple nombra dos ajustes y ningún otro, de modo que IPHONEOS_DEPLOYMENT_TARGET y sus hermanos quedan fuera de la regla. Apple nombra un umbral y no una versión del toolchain, así que el disparador es tu propio deployment target al cruzar 27.0. Apple dice “will not build Universal by default”, lo que describe un valor predeterminado, no una prohibición. Y en la misma frase entrega la salida, al señalar ARCHS como el lugar donde volver a poner x86_64.

El valor predeterminado que cambia sin dar error

El mecanismo es de lo más común, y eso es justamente lo que lo vuelve silencioso. La referencia de build settings de Apple describe ARCHS como “A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced.”⁵ El ajuste predefinido es ARCHS_STANDARD, y Apple confirma la dependencia en otro punto de esa misma referencia, al señalar que la autenticación de punteros “Has no effect if ARCHS has been overridden to not be based on ARCHS_STANDARD.”⁵

Así que un target que nunca menciona ARCHS hereda lo que le entregue la plataforma. Cambia lo que entrega la plataforma y el producto cambia de forma sin que se edite ningún archivo bajo control de versiones.

Nada del cambio produce un fallo. El compilador se ejecuta, el linker se ejecuta y el archive se valida. Nada en el toolchain trata una compilación de macOS con una sola porción arm64 como un error, porque no lo es. El resultado es una app de macOS correcta y firmada que lleva una porción de arquitectura donde antes llevaba dos. En una Mac con Apple silicon —la máquina que ahora usa por obligación todo desarrollador de Xcode 27—, la compilación exclusiva de arm64 se inicia y se comporta igual. La regresión aparece en un hardware que ya nadie tiene sobre el escritorio.

Calificar el modo de fallo como silencioso es cosa mía y no de Apple; Apple describe el valor predeterminado y ahí se detiene. Lo que Apple sí dice es que la corrección es aditiva, y la formulación importa a la hora de planificar: x86_64 “can be added to the ARCHS build setting if this is needed”.¹ Apple te deja a ti el juicio sobre la necesidad.

Lo que Xcode 26.6 te dice y lo que no

Mi máquina ejecuta Xcode 26.6 (build 17F113) sobre macOS 26.5.2, así que en este artículo no aparece ningún comportamiento de Xcode 27.¹³ La pregunta útil que puede responder un toolchain anterior es si ya se comporta del modo nuevo. No lo hace.

Apuntar xcodebuild a un proyecto exclusivo de macOS y sobrescribir el deployment target por encima del umbral que nombra Apple deja intacta la lista de arquitecturas:¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

La primera línea es xcodebuild devolviendo el valor sobrescrito; el resto son valores resueltos. El mismo comando con 26.0 devuelve líneas de arquitectura idénticas.¹³ Xcode 26.6 no implementa el umbral, así que nadie puede ensayar el cambio en el toolchain actual; cualquier comparación de antes y después tendrá que esperar a Xcode 27 en una Mac con Apple silicon.

Lo que sí se reproduce hoy es el alcance por plataforma. El mismo proyecto, resuelto contra el SDK de iOS, devuelve ARCHS_STANDARD = arm64 sin ningún x86_64 que perder, mientras que contra el SDK de macOS devuelve arm64 x86_64.¹³ La entrada de Apple nombra solo los deployment targets de macOS y DriverKit, y el lado iOS de un proyecto multiplataforma no tiene nada en juego.

Auditar tu propia exposición sin inventarla

Dos hábitos producen respuestas equivocadas dichas con seguridad. Caí en ambos.

El primero es pasar -sdk macosx para averiguar si un proyecto se compila para macOS. La bandera sobrescribe el propio SDK del proyecto, así que Xcode responde una pregunta sobre la bandera y no sobre el proyecto. Si se le pregunta sin sobrescritura, un proyecto de navegador mío, exclusivo de iOS, reporta su plataforma real; si se le pregunta con -sdk macosx, ese mismo proyecto reporta SUPPORTED_PLATFORMS = macosx y ARCHS_STANDARD = arm64 x86_64, puro artefacto.¹⁴ Empieza sin ningún -sdk:

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

Contra mi única app exclusiva de macOS vuelven dos líneas:¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

Lee las dos líneas, nunca una sola. Ese proyecto declara SDKROOT = macosx y ninguna línea SUPPORTED_PLATFORMS, así que una búsqueda de texto de SUPPORTED_PLATFORMS en los archivos del proyecto le da cero y se salta la única app exclusiva de macOS que tengo.¹⁴ La configuración resuelta llena el hueco a partir del SDK; grep no puede. Ignora MACOSX_DEPLOYMENT_TARGET en esta etapa, porque Xcode entrega uno de todos modos: tres de mis proyectos exclusivos de iOS siguen reportando un deployment target de macOS, dos en 26.5 y uno en 26.2.¹⁴

El segundo hábito es resolver la configuración a nivel de proyecto. xcodebuild -showBuildSettings sin -target responde por un único target, y un proyecto mixto entierra el resto. Mi proyecto de extensión de Safari se resolvió como SUPPORTED_PLATFORMS = iphoneos iphonesimulator y ARCHS_STANDARD = arm64, lo que se lee como un proyecto exclusivo de iOS sin exposición a Intel. Al enumerar sus targets aparecieron cuatro, dos de ellos de macOS, ambos resolviéndose como arm64 x86_64:¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

Una rareza con la que hay que contar: un target con SDKROOT = auto no resuelve ningún ARCHS_STANDARD hasta que nombras un SDK, de modo que 15 de mis 21 targets de macOS no imprimen nada en esa línea hasta que el comando añade -sdk macosx, momento en el cual sus proyectos resuelven arm64 x86_64.¹⁴ En blanco significa sin resolver, no vacío.

Después deja de confiar en la configuración y lee un binario. Los ajustes de compilación describen la intención; lipo describe el artefacto que realmente publicaste:

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

Prefiere lipo antes que los metadatos del propio archive. Dos de mis archives no llevan ninguna lista de arquitecturas ApplicationProperties en su Info.plist, así que una consulta con plutil contra el archive no devuelve nada mientras que lipo contra el binario que hay dentro devuelve x86_64 arm64.¹⁴ Que falte en los metadatos significa que el archive se escribió de otra manera, no que la app haya perdido una porción.

Qué contienen realmente 11 proyectos

Ejecuté la auditoría sobre 11 proyectos de Xcode que suman 44 targets. Ocho proyectos contienen al menos un target de macOS, 21 targets se compilan para macOS, y hoy la exposición al nuevo valor predeterminado es nula.¹⁴

El deployment target de macOS más alto de la flota es 26.5, y el más bajo 13.0, en una extensión de Safari que nadie ha vuelto a tocar en bastante tiempo. Ningún target cruza 27.0, así que ninguno entra en el régimen del valor predeterminado nuevo hasta que alguien suba un número a mano. Cero targets definen ARCHS, cero definen EXCLUDED_ARCHS, y la flota no contiene ningún archivo .xcconfig, de modo que cada decisión de arquitectura en los 44 targets viene de ARCHS_STANDARD.¹⁴

La evidencia de los archives pesa más que la de la configuración, porque los archives registran lo que realmente se publicó. Mi máquina guarda 79 archives creados entre abril y julio de 2026. Los 51 archives de macOS, repartidos en siete productos distintos, reportan x86_64 arm64. Los 28 archives de la familia iOS reportan arm64.¹⁴ Nadie en ninguno de esos proyectos eligió jamás Universal; lo produjo el valor predeterminado, todas las veces. Esa es la población sobre la que actúa el cambio de Apple, y justo por eso nadie va a notarlo.

Un vacío que conviene reconocer: subir un deployment target a 27.0 es un acto deliberado, y ninguno de mis proyectos tiene todavía motivo para hacerlo. El resultado limpio de la flota mide un momento, no una política.

Dónde termina de verdad el software Intel

El cambio de Xcode tiene que ver con las arquitecturas dentro de una compilación. El fin del software Intel como categoría está en macOS 28, y Apple lo dejó por escrito tanto en su documentación de Rosetta como en las notas de versión de macOS 27, que coinciden entre sí.

La documentación de Rosetta de Apple fija el plazo de forma directa. Rosetta “was designed to make the transition to Apple silicon easier, and will be available through macOS 27” como herramienta de uso general para apps Intel, y “Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.”⁷ Las notas de versión de macOS 27 enuncian la consecuencia con la misma excepción: “All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.”¹⁰ Un comando exclusivo de las betas, en otro punto de esas mismas notas, le da forma a esa excepción: sudo game-test-tool enable activa la compatibilidad con juegos Intel antiguos, y Apple advierte que “enabling legacy game support disables Rosetta.”¹⁵

macOS 27 dedica el intervalo a nombrar lo que no va a sobrevivir. La sección Deprecation Information de Apple informa que “Intel-based applications that will no longer run in macOS 28.0 now display a treatment in Get Info”, y otra entrada añade que “Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0”, incluido “unused Intel-based software discovered on the system”.⁸⁹

Hay tres entradas más discretas que pesan más para quien publica un producto para Mac.

Rosetta deja de ser persistente: “If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0.”¹¹ La documentación de Apple aporta el contexto, al señalar que macOS 27 “directly integrates support for Intel binary translation, without needing to install Rosetta”, al servicio de los binarios Intel de Linux en máquinas virtuales ARM y de los contenedores Intel de Linux.⁷ Las apps que un usuario hubiera fijado también cambian: las aplicaciones configuradas antes como “Open using Rosetta” ahora “have the application launch natively”, y Apple aconseja que “Any compatibility issues requiring Rosetta from the past should be re-assessed on macOS 27.”¹²

Los instaladores cambian de valores predeterminados: “Installer packages which specify no hostArchitecture will now default to arm64”, y Apple pide que te asegures de que “any pre and post install scripts behave as intended under arm64”.¹¹ Cualquier producto para Mac distribuido fuera de la App Store hereda ese punto, sea o no Universal su app.

Las apps anfitrionas de plugins son el caso más delicado. Apple advierte que “Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility”, y nombra las carpetas que hay que revisar a mano, entre ellas ~/Library/Audio/Plug-Ins/, ~/Library/Printers/ y ~/Library/ColorPickers/.¹⁰ El motivo por el que un plugin puede dejar varada a una app por lo demás nativa aparece en la documentación de Rosetta de Apple: “The system prevents you from mixing arm64 code and x86_64 code in the same process. Rosetta translation applies to an entire process, including all code modules that the process loads dynamically.”⁷ Un plugin Intel obliga por tanto a su anfitrión a ejecutarse traducido, y convierte un componente sin mantenimiento en una dependencia de toda la app respecto de un recurso que Apple ya programó para reducir.

Universal existe para llegar a las Macs Intel que funcionan con macOS 12 a 27, el rango que publica la tabla de compatibilidad de Apple para Xcode 27.⁴ Apple fechó el fin del software Intel en macOS 28 y dejó intacto el rango de deployment targets, así que la pregunta real de un equipo de macOS es cuántos de sus usuarios siguen usando una Mac que necesita esa porción.

Dos cosas que comprobé y no encontré: ni las notas de versión de Xcode 27 ni las de macOS 27 dicen nada sobre cambios en los requisitos de Universal Purchase de la Mac App Store, y ninguna de las dos fija una fecha de calendario para macOS 28.³⁶ Toma cualquier fecha que leas por ahí como una inferencia.

Preguntas frecuentes

¿Xcode 27 me impide publicar apps para Intel?

No, y Apple dice lo contrario en la misma entrada que declara obsoletas las Macs Intel como máquinas de desarrollo: “The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later.”² La tabla de compatibilidad de Apple confirma el rango, al indicar de macOS 12 a 27 como deployment targets para Xcode 27 beta 4.⁴ Lo que cambia es el valor predeterminado. Un target cuyo deployment target de macOS llega a 27.0 deja de recibir x86_64 desde ARCHS_STANDARD, y la corrección que indica Apple es que tú mismo añadas x86_64 a ARCHS.¹ Publicar para Intel pasa a ser una decisión que declaras y no una que heredas.

¿Mi compilación va a fallar si ARCHS_STANDARD elimina x86_64?

Nada en la entrada de Apple describe un error, una advertencia ni un diagnóstico de ningún tipo. Apple describe un valor predeterminado que cambia: los targets en macOS o DriverKit 27.0 y superiores “will not build Universal by default”.¹ Una compilación que pasa el compilador, el linker y la firma con una porción de arquitectura en lugar de dos es una compilación válida, y en la Mac con Apple silicon que Xcode 27 te obliga a usar, la diferencia es invisible en tiempo de ejecución.² Apple enuncia el valor predeterminado y deja la consecuencia sin escribir, así que la palabra silencioso es mía y no de Apple. Revisa lipo -archs en el binario archivado en vez de esperar a que un registro de compilación saque el tema.

¿Puedo probar el nuevo comportamiento en Xcode 26?

No. Hice la comprobación directamente en Xcode 26.6 (build 17F113): sobrescribir MACOSX_DEPLOYMENT_TARGET a 27.0 en un proyecto exclusivo de macOS sigue resolviendo ARCHS_STANDARD = arm64 x86_64, idéntico al mismo comando con 26.0.¹³ El toolchain anterior no implementa el umbral, así que ningún experimento con ajustes de compilación en Xcode 26 anticipa el cambio. Lo que Xcode 26.6 sí reproduce es el alcance: ese mismo proyecto resuelve ARCHS_STANDARD = arm64 contra el SDK de iOS y arm64 x86_64 contra el SDK de macOS, en línea con una entrada que nombra los deployment targets de macOS y DriverKit y nada más.¹¹³

¿Necesito ahora una Mac con Apple silicon?

Para ejecutar Xcode 27, sí, sin matices: “Xcode 27 will only install and run on Apple silicon Macs.”² Apple añade un piso de software sobre el de hardware, y exige macOS Tahoe 26.4 o posterior para Xcode 27 beta 4.⁴ El desarrollo para Intel sobrevive en toolchains anteriores, que es como lo plantea Apple: “Intel development is still possible with macOS versions that support Rosetta like macOS 27.”² La documentación de Rosetta de Apple le pone un límite a esa vía, al indicar que Rosetta “will be available through macOS 27” como herramienta de uso general, con un subconjunto reducido después, orientado a juegos antiguos sin mantenimiento.⁷

Ideas clave

Para quienes desarrollan apps de macOS: - Audita primero sin la bandera -sdk, lee SUPPORTED_PLATFORMS y SDKROOT juntos, e ignora MACOSX_DEPLOYMENT_TARGET cuando la pregunta sea si un target se compila para macOS siquiera. Xcode escribe un deployment target de macOS dentro de proyectos exclusivos de iOS: tres de los míos reportan uno (26.5, 26.5 y 26.2) sin compilarse para ninguna Mac.¹⁴ - Enumera los targets con xcodebuild -list antes de resolver la configuración. Una consulta a nivel de proyecto sobre mi extensión de Safari reportó un proyecto exclusivo de iOS y ocultó dos targets de macOS.¹⁴

Para equipos cuyos usuarios incluyen Macs Intel: - Decide x86_64 de forma explícita en lugar de heredarlo. Define ARCHS cuando subas un deployment target de macOS a 27.0, porque la entrada de Apple ofrece exactamente ese remedio y ninguna advertencia si lo pasas por alto.¹ - Verifica con lipo -archs contra el binario archivado, no contra los ajustes de compilación ni contra el Info.plist del archive. Dos de mis archives no llevan metadatos de arquitectura y aun así sus binarios son Universal.¹⁴

Para quienes gestionan versiones: - Separa la fecha límite del hardware de la fecha límite de publicación. Xcode 27 exige una Mac con Apple silicon desde el primer día; la salida Universal sobrevive hasta macOS 12 y posteriores, y Apple no ha publicado ninguna fecha de calendario para macOS 28.²⁴ - Inventaría plugins y paquetes de instalación Intel, no solo apps. Apple advierte que los plugins Intel “may not appear in Settings”, y un plugin Intel obliga a todo su proceso anfitrión a ejecutarse traducido.⁷¹⁰

El ciclo 27 no deja de esconder cambios de peso en lugares poco llamativos. La eliminación del linker y la regla de nombres de módulo rompen las compilaciones de plano al actualizar el toolchain, la macro @State las rompe a nivel de código fuente, y la clave de la pantalla de inicio bloquea un envío. El valor predeterminado de Intel no rompe nada y aun así cambia el producto, y por eso conviene auditarlo antes de actualizar y no después. El centro de toda la serie es la Serie del ecosistema Apple.

Referencias