Respuesta corta: macOS 27 funcionará solo en Mac con Apple silicon, y Xcode 27 también requiere un Mac con Apple silicon para instalarse y ejecutarse. Para un target cuyo deployment target mínimo sea macOS 27.0, Xcode 27 deja de incluir x86_64 en ARCHS_STANDARD de forma predeterminada. Eso no significa que todos los desarrolladores deban eliminar de inmediato la parte Intel: si la app todavía necesita admitir Mac Intel con macOS 26 o anterior, un binario universal sigue siendo la opción coherente.
La clave es separar tres decisiones que suelen mezclarse: qué Mac pueden ejecutar el sistema operativo, qué arquitecturas contiene el ejecutable y cuál es el deployment target mínimo declarado por la app. El 9 de septiembre de 2026, Apple abrió los envíos con los SDK más recientes y pidió a los desarrolladores optimizar sus apps para macOS 27. La regla práctica es sencilla: macOS 27 como mínimo apunta a arm64; soporte para Mac Intel con macOS 26 o anterior apunta a un binario universal. Consulta el aviso de envíos de Apple.
Qué cambia realmente en macOS 27
El primer corte es de hardware. Apple indica que macOS 26 es la última gran versión compatible con Mac Intel y que macOS 27 será exclusivo de Apple silicon. En paralelo, las notas de Xcode 27 dicen que la propia herramienta solo se instala y ejecuta en Mac con Apple silicon.
El segundo corte está en el build. En Xcode 27, cuando MACOSX_DEPLOYMENT_TARGET es 27.0 o superior, ARCHS_STANDARD deja de incluir x86_64 de forma predeterminada. Es un cambio del valor por defecto, no una prohibición absoluta de compilar código Intel: las notas permiten añadir x86_64 manualmente a ARCHS cuando sea necesario. En la práctica, sin embargo, una parte x86_64 no crea compatibilidad de hardware con macOS 27 porque ningún Mac Intel ejecutará esa versión del sistema.
El tercer corte es de herramientas. Usar el SDK de macOS 27 no obliga a establecer macOS 27 como deployment target. Un proyecto puede compilarse con Xcode 27 y el SDK más nuevo, pero seguir declarando una versión mínima anterior para mantener compatibilidad con equipos y sistemas antiguos. Esa diferencia entre Base SDK y deployment target es central para elegir entre universal y arm64-only.
Rosetta: por qué la redacción oficial exige cautela
Las páginas oficiales de Apple publicadas en septiembre de 2026 no están perfectamente alineadas en la forma de describir la transición de Rosetta. El aviso del 1 de septiembre afirma que macOS 27 es la última versión de uso general compatible con Rosetta y que la transición está terminando; la documentación técnica también dice que Rosetta permanece disponible durante macOS 27. El comunicado del 9 de septiembre, en cambio, describe macOS 26 como la última versión con soporte para Mac Intel y Rosetta, al mismo tiempo que reitera que macOS 27 será Apple silicon only.
Para planificar el producto, la conclusión segura no depende de resolver esa diferencia de redacción: no uses Rosetta como estrategia de compatibilidad para una app Intel-only durante el ciclo de macOS 27. La dirección de Apple es añadir soporte nativo para Apple silicon ahora. En macOS 26.4 o posterior, los usuarios que abran apps dependientes de Rosetta pueden recibir avisos del sistema que recomiendan una versión nativa. Lee el aviso de transición de Rosetta y la documentación del entorno de traducción.
Apple también informa que, después del periodo de transición de uso general, conservará un subconjunto de funciones de Rosetta para juegos antiguos y sin mantenimiento que dependen de frameworks Intel. Es una excepción específica y no debe interpretarse como garantía de ejecución para aplicaciones Intel genéricas.
Checklist por escenario: Intel-only, universal o ya nativa
| Escenario actual | Qué hacer ahora | Resultado recomendado |
|---|---|---|
| App Intel-only (x86_64) | Auditar bibliotecas, frameworks, plug-ins, helpers y herramientas; añadir arm64; probar en Apple silicon; revisar cualquier dependencia de Rosetta. | Universal si todavía se admiten Mac Intel con macOS 26 o anterior; arm64-only si el nuevo mínimo es macOS 27. |
| Binario universal (arm64 + x86_64) | Confirmar que todas las dependencias siguen siendo universales y que la parte arm64 funciona de forma nativa sin Rosetta. | Mantener universal mientras el producto siga admitiendo Intel; eliminar x86_64 cuando esa compatibilidad deje de formar parte de la política de soporte. |
| App ya nativa arm64 | Revisar componentes integrados y CI; subir el deployment target solo cuando tenga sentido para la base de usuarios. | Seguir en arm64. Si el mínimo pasa a macOS 27, el valor predeterminado de Xcode 27 ya converge hacia esa arquitectura. |
Cuándo mantener un binario universal
El binario universal sigue siendo útil si distribuyes la misma app a usuarios de Mac Intel con macOS 26 o anterior. Un ejecutable universal contiene las partes arm64 y x86_64, y el sistema selecciona la adecuada para la máquina. En Apple silicon, la parte arm64 se ejecuta de forma nativa; en un Mac Intel compatible, se ejecuta la parte x86_64. Apple mantiene documentación específica sobre cómo crear y verificar binarios universales para macOS.
También tiene sentido mantener universal durante una ventana de transición empresarial, cuando los clientes tienen ciclos de renovación de hardware más lentos o cuando la política oficial de soporte todavía incluye Intel. Lo importante es no equiparar “compilar con el SDK de macOS 27” con “exigir macOS 27”. Puedes adoptar Xcode 27, usar sus SDK actuales y seguir eligiendo un deployment target anterior.
Cuándo limitar el build a arm64
Si tu app pasa a exigir macOS 27, no hay un beneficio práctico en mantener una parte x86_64 para llegar a Mac Intel porque esos equipos no pueden ejecutar el sistema. El aviso del 9 de septiembre indica de forma explícita que, para limitar una app a Mac con Apple silicon, el desarrollador debe establecer la arquitectura del build en arm64, recompilar y reenviar.
Arm64-only también puede ser una decisión de producto antes de elevar el deployment target, siempre que estés dispuesto a terminar el soporte para Mac Intel. Esto reduce combinaciones de prueba y puede simplificar dependencias, pero sigue siendo un cambio de compatibilidad: los usuarios de Intel deben saber cuál es la última versión que seguirá funcionando para ellos.
Qué revisar en Xcode 27
- Architectures (ARCHS): prioriza los valores predeterminados de Xcode salvo que exista un motivo claro para personalizarlos. Con deployment target 27.0 o superior, el valor por defecto ya deja fuera x86_64.
- Build Active Architecture Only: los builds de Debug suelen centrarse en la arquitectura de la máquina activa, mientras que Release debe producir el conjunto de arquitecturas previsto para distribución.
- Excluded Architectures: elimina workarounds antiguos que solo existían porque una dependencia no admitía Apple silicon. Pueden ocultar un problema en lugar de resolverlo.
- CI y máquinas de build: como Xcode 27 solo funciona en Apple silicon, los runners Intel deben migrarse si la pipeline depende de esta versión de Xcode.
- Deployment target: súbelo a 27 solo cuando estés dispuesto a dejar atrás sistemas anteriores; no lo hagas únicamente porque usas el SDK 27.
La recomendación general de Apple es mantener los ajustes de arquitectura en sus valores predeterminados siempre que sea posible, porque esos valores siguen las arquitecturas de CPU recomendadas para la plataforma. TN3117 explica estos ajustes.
Dependencias, plug-ins y helpers son donde suele romperse la migración
Añadir arm64 solo al ejecutable principal no es suficiente. El código cargado en el mismo proceso necesita una arquitectura compatible. Esto incluye frameworks propios y de terceros, bibliotecas estáticas y dinámicas, plug-ins, extensiones, herramientas de línea de comandos, daemons, launch agents y otros binarios incluidos con la app. La documentación de portabilidad de Apple indica que una dependencia sin la arquitectura necesaria puede impedir un build nativo correcto o su ejecución. Consulta la guía de portabilidad a Apple silicon.
Si el proyecto usa código de bajo nivel, revisa también supuestos específicos del procesador, assembly, intrinsics, código JIT, tamaños de página de memoria y otros detalles arquitectónicos. Muchas apps basadas en frameworks de alto nivel solo necesitan recompilar, pero el software que depende directamente de detalles de hardware exige pruebas adicionales.
Cómo verificar que el artefacto final tiene las arquitecturas correctas
Después de un Archive o build de distribución, inspecciona el ejecutable real dentro del bundle en lugar de confiar únicamente en los ajustes del proyecto. Apple recomienda herramientas como lipo o file. Con lipo -archs, un binario universal debe listar arm64 y x86_64; un build limitado a Apple silicon debe listar solo arm64.
Haz la misma comprobación en los componentes integrados críticos. Una app puede parecer universal en el ejecutable principal y aun así fallar al cargar un plug-in o framework que solo tenga x86_64. Si mantienes un build universal, prueba tanto la ejecución nativa arm64 como la parte x86_64 bajo el entorno de traducción disponible durante la transición.
Un plan de distribución que no confunda macOS 26 con 27
- Define primero tu política de soporte: ¿la próxima versión todavía necesita admitir Mac Intel?
- Si la respuesta es sí, mantén un deployment target compatible con macOS 26 o anterior y distribuye un binario universal.
- Si la respuesta es no y el mínimo pasa a macOS 27, deja que el build converja a arm64-only.
- Actualiza todas las dependencias antes de eliminar Rosetta de tus supuestos de prueba.
- Migra CI y máquinas de desarrollo que todavía dependan de Xcode en Mac Intel, porque Xcode 27 requiere Apple silicon.
- Informa a los usuarios de versiones Intel-only sobre la versión nativa e identifica con claridad la última release compatible con el entorno anterior.
Tres errores que conviene evitar
Error 1: asumir que “macOS 27 es Apple silicon only” significa que todas las apps deben ser arm64-only hoy. Si todavía admites macOS 26 en Mac Intel, un binario universal sigue atendiendo a ambos grupos.
Error 2: tratar universal e Intel-only como si fueran lo mismo. Una app universal ya contiene arm64 y se ejecuta de forma nativa en Apple silicon; una app Intel-only depende de traducción durante la transición.
Error 3: confundir el SDK con el deployment target. Compilar en Xcode 27 no significa que la app tenga que exigir macOS 27. El deployment target es lo que declara la versión mínima del sistema operativo compatible con la app.
La decisión práctica para cada proyecto
Si el proyecto todavía tiene usuarios de Mac Intel, la transición más limpia es universal ahora y arm64-only cuando termine el soporte a Intel. Si ya no existe un compromiso con Intel y la próxima versión exige macOS 27, simplifica a arm64 y valida todas las dependencias nativas. Para una app que todavía es Intel-only, la prioridad no es estimar cuánto tiempo Rosetta podría servir de respaldo: es crear y probar una versión arm64 antes de que un cambio del sistema operativo convierta la deuda técnica en incompatibilidad para el usuario.
