macOS 27: migra tus apps tras el último macOS compatible con Intel

Apple publicó macOS 27 Golden Gate el 14 de septiembre de 2026. La versión 27.0 (build 26A428) aparece en el registro de releases de Apple Developer, junto con Xcode 27 (27A266a). La página de compatibilidad de Apple Support confirma un cambio básico para cualquier plan de actualización: el sistema solo se instala en Macs con chips Apple silicon, incluidos los equipos con chips de las familias M y A. Los Macs Intel quedan fuera de esa lista y tendrán que permanecer en una versión anterior compatible.

El aviso de Apple Developer del 9 de septiembre de 2026 resume que macOS 26 fue la última versión compatible con Macs Intel y que macOS 27 funciona únicamente en Apple silicon. Para Rosetta, la documentación empresarial posterior de Apple aporta el matiz decisivo: continúa como herramienta general de compatibilidad durante macOS 27. Son dos límites distintos —hardware Intel y ejecución de software Intel— y no deben tratarse como si ocurrieran al mismo tiempo.

La consecuencia práctica es clara: macOS 27 es la última ventana general de migración con Rosetta en Apple silicon. Una app que todavía necesita traducción no es una base segura para el siguiente ciclo del sistema; la migración debe cubrir el ejecutable principal y todo lo que la aplicación instala o carga.

Dos compatibilidades distintas: el Mac y la app

Conviene separar dos preguntas que suelen mezclarse:

1. ¿Puede este Mac instalar macOS 27? Solo los modelos con Apple silicon que aparecen en la lista oficial de Apple. Un Mac Intel no se convierte en compatible por tener una app universal.
2. ¿Puede esta app ejecutarse en un Mac Apple silicon? Una app que contiene únicamente código x86_64 necesita traducción Rosetta. Una app universal contiene slices arm64 y x86_64 y puede ejecutarse de forma nativa en ambos tipos de Mac.

En macOS 27, Rosetta todavía traduce instrucciones x86_64 para Apple silicon y trabaja a nivel de proceso. Cuando el sistema encuentra una app solo Intel, inicia la capa de traducción; cuando encuentra un binario universal, prefiere la porción arm64. El usuario puede forzar el modo traducido en una app universal para dar tiempo a un plugin antiguo, pero Rosetta no modifica el archivo ni combina sus ejecutables: el binario universal se construye durante el proceso de compilación.

La traducción tampoco resuelve todos los casos. Apple indica que Rosetta no traduce extensiones de kernel ni aplicaciones de máquinas virtuales que virtualizan plataformas x86_64. Tampoco se debe asumir que una aplicación universal hace universales automáticamente sus plugins o servicios auxiliares: cada binario debe revisarse.

Qué debes inventariar antes de compilar

El ejecutable que aparece en Contents/MacOS/ es solo el comienzo. La guía de Apple para binarios universales recomienda auditar, como mínimo:

• aplicación principal y extensiones de aplicación;
• plugins de audio, vídeo, edición o automatización;
• frameworks estáticos y dinámicos, además de librerías de terceros;
• herramientas de compilación y utilidades de línea de comandos;
• helpers que se ejecutan con la app, en el inicio de sesión o con privilegios elevados;
• launch agents, launch daemons y otros servicios en segundo plano;
• extensiones DriverKit;
• instaladores, actualizadores y desinstaladores;
• extensiones de kernel, que necesitan ser nativas y no tienen una vía de Rosetta.

Haz el inventario del artefacto que realmente entregas, no solo del proyecto de Xcode. Un instalador puede incluir un helper descargado después; una aplicación de vídeo puede cargar plugins de otros proveedores; y una herramienta empresarial puede dejar un daemon fuera del bundle principal. Cualquiera de ellos puede ser el componente que falle en una actualización.

Una ruta reproducible para encontrar dependencias Intel

1. Separa las flotas

Obtén el modelo y la arquitectura de cada entorno de desarrollo, pruebas y producción. Marca aparte los Macs Intel que todavía reciben soporte: no podrán subir a macOS 27, pero pueden seguir siendo parte de tu matriz de compatibilidad en la última versión de macOS que admitas.

En los Macs Apple silicon, registra además si una ejecución ocurre de forma nativa o traducida. La documentación de Apple ofrece la comprobación sysctl.proc_translated para detectar un proceso bajo Rosetta. Es útil durante las pruebas porque una app puede parecer correcta mientras todavía está evitando su camino arm64.

2. Comprueba cada archivo ejecutable

En un Mac de laboratorio puedes inspeccionar el ejecutable real con las herramientas incluidas en el sistema:

file MiAplicacion.app/Contents/MacOS/MiAplicacion
lipo -archs MiAplicacion.app/Contents/MacOS/MiAplicacion

El resultado debe permitirte clasificar el archivo como arm64, x86_64 o universal. Repite la comprobación en frameworks, plugins, helpers, binarios de instalación y daemons; apunta la ruta y la arquitectura a una tabla versionada en tu repositorio o en tu sistema de entrega.

Estos comandos no sustituyen al lanzamiento real. Un bundle puede declarar una arquitectura correcta y fallar al cargar una dependencia dinámica, al iniciar un servicio o al abrir un plugin. La auditoría de slices es un filtro rápido, no una certificación de compatibilidad.

3. Construye el binario universal

Apple define un binario universal como uno que contiene código para arm64 y x86_64. Xcode compila cada arquitectura y utiliza lipo para combinarlas en el producto final. Si utilizas Makefiles o un sistema de compilación propio, configura ambos objetivos y combina los ejecutables como parte del proceso reproducible. Rosetta no participa en este paso: su función es traducir instrucciones en tiempo de ejecución.

La documentación de Apple todavía menciona Xcode 12.2 o posterior como requisito histórico para construir binarios universales. Para un proyecto actual, usa Xcode 27 (27A266a) o la versión pública que corresponda al SDK y al mínimo de macOS que hayas elegido; el número histórico no debe convertirse en una recomendación de toolchain para producción.

Aísla el código específico de arquitectura con las condiciones del compilador (#if arch(arm64) y #if arch(x86_64) en Swift, o los macros correspondientes en C y Objective-C). Revisa también dependencias precompiladas: si una librería solo ofrece x86_64, tu aplicación seguirá teniendo una pieza Intel aunque el ejecutable principal tenga dos slices.

4. Prueba instalación, actualización y operación

En un Mac Apple silicon actualizado, prueba como mínimo:

• instalación limpia desde el instalador que reciben los usuarios;
• actualización sobre la versión anterior, conservando preferencias y datos;
• primer lanzamiento y migración de datos;
• plugins y extensiones de aplicación;
• login items, helpers, launch agents y launch daemons;
• permisos, sandbox, acceso a archivos y dispositivos;
• firma, notarización y validaciones de Gatekeeper;
• actualización automática, reparación y desinstalación;
• suspensión, reanudación, cambio de usuario y reinicio.

Separa las pruebas en dos entornos. En un Mac Intel con macOS 26 valida el slice x86_64, porque es la última versión compatible con ese hardware. En un Mac con Apple silicon y macOS 27 prueba el camino nativo arm64 y, mientras Rosetta siga formando parte de tu transición, ejecuta de forma explícita los plugins o componentes Intel. Un binario universal no elimina la necesidad de comprobar ambas arquitecturas si todavía las distribuyes.

Conserva una vía de regreso operativa: una versión anterior instalada en un volumen o equipo de laboratorio, un instalador recuperable y un procedimiento documentado para restaurar datos. El rollback no tiene que significar mantener Rosetta indefinidamente; significa poder aislar un fallo sin dejar a una flota sin herramienta.

LSRequiresNativeExecution no es un parche universal

Apple documenta la clave LSRequiresNativeExecution para impedir que una app universal se ejecute mediante traducción. Si se establece en YES, Launch Services exige la arquitectura nativa y elimina la opción de abrir con Rosetta. Puede ser una decisión razonable cuando ya verificaste toda la cadena de plugins y helpers, pero es peligrosa como primer paso: si una dependencia sigue siendo Intel, la app puede dejar de arrancar.

No añadas la clave para ocultar un problema de compatibilidad. Primero comprueba que la app funciona en Apple silicon y en Intel, valida las dependencias y registra el motivo en el control de cambios. Si el producto necesita priorizar una arquitectura sin bloquear la traducción, Apple también documenta LSArchitecturePriority, pero esa configuración no reemplaza la auditoría.

Qué deben revisar las empresas antes de actualizar sus Macs

Apple anuncia en macOS Golden Gate 27 nuevas capacidades de gestión para controlar qué apps o binarios pueden ejecutarse, consolidar avisos de consentimiento de privacidad y ampliar Platform SSO. Para una empresa, el cambio de Rosetta debe entrar en el piloto de actualización junto con las políticas de ejecución y el inicio de sesión, no como un proyecto separado que se valida después.

El piloto debería incluir perfiles de MDM reales, usuarios estándar y administradores, herramientas de seguridad, software de acceso remoto y aplicaciones internas. Conserva dos referencias de prueba separadas: un Mac Intel con macOS 26 para validar la arquitectura anterior y un Mac con Apple silicon y macOS 27 para comprobar tanto la ejecución nativa como la traducción con Rosetta. Documenta además un plan de recuperación con instaladores, copias de datos y equipos de laboratorio; una instalación limpia no reproduce necesariamente una actualización sobre un Mac corporativo.

La fecha que debes usar para planificar

Las fuentes de Apple deben leerse por fecha y contexto. El aviso del 9 de septiembre de 2026 identifica macOS 26 como la última versión para Macs Intel y macOS 27 como un sistema exclusivo de Apple silicon. La documentación empresarial publicada el 14 de septiembre aclara que Rosetta continúa como herramienta general durante macOS 27. Apple sitúa el corte general del software Intel en macOS 28.0, salvo juegos antiguos sin mantenimiento. macOS 28.0 no está disponible en esta fecha: es el siguiente corte documentado por Apple.

La recomendación operativa es migrar ahora sin atribuir a Rosetta una función que no tiene. Construye el binario universal durante la compilación, valida sus componentes y usa un Mac con Apple silicon y macOS 27 para comprobar la ejecución traducida mientras siga formando parte de tu matriz de compatibilidad. Mantén macOS 26 en hardware Intel solo para probar el slice x86_64. Planifica la retirada general antes del corte documentado para macOS 28.0.

Checklist de salida

• La flota está separada entre Macs Apple silicon compatibles con macOS 27 y Macs Intel que permanecerán en una versión anterior.
• El ejecutable principal, extensiones, frameworks, plugins, helpers, CLI, daemons, instaladores y actualizadores están inventariados.
• Cada artefacto está clasificado como arm64, x86_64 o universal.
• La versión de distribución contiene arm64 y x86_64 donde todavía sea necesario mantener ambas plataformas.
• Se probó instalación limpia, actualización, primer lanzamiento, permisos, firma, notarización, servicios y desinstalación.
• Se probó el producto nativo en Apple silicon y el slice Intel en un Mac Intel compatible.
• Plugins y dependencias de terceros tienen una versión arm64 o un plan de reemplazo.
• LSRequiresNativeExecution solo se usa después de validar toda la cadena de ejecución.
• Existen entornos de laboratorio separados para Intel/macOS 26 y Apple silicon/macOS 27, además de un plan de recuperación documentado.
• Administración y soporte tienen instrucciones para usuarios que aún ejecutan la versión Intel.

macOS 27 no convierte por sí solo una aplicación Intel en una aplicación Apple silicon. macOS 26 fue el último sistema para hardware Mac Intel; macOS 27 requiere Apple silicon y conserva Rosetta como última ventana general de transición. Apple sitúa el corte general del software Intel en macOS 28.0, salvo juegos antiguos. Si tu producto ya es universal, el trabajo inmediato es demostrar que sus plugins, frameworks, helpers e instaladores también lo son. Si aún distribuyes un binario solo x86_64, la prioridad es construir, firmar y probar una versión universal antes del siguiente corte.

Fuentes primarias

• Releases — Apple Developer — registra macOS 27.0 (26A428) y Xcode 27 (27A266a), ambos del 14 de septiembre de 2026.
• App Store submissions now open for the latest OS releases — Apple Developer — aviso del 9 de septiembre de 2026 sobre el fin del soporte para Macs Intel y el requisito de Apple silicon en macOS 27.
• macOS 27 Golden Gate es compatible con estos ordenadores — Soporte de Apple — lista de modelos compatibles y fecha de publicación.
• Cómo actualizar a macOS 27 Golden Gate — Soporte de Apple — confirma que macOS 27 requiere un Mac con Apple silicon de las familias M o A.
• Upcoming changes to Rosetta support for Intel-based macOS apps — Apple Developer — aviso del 1 de septiembre de 2026 sobre la transición y la recomendación de migrar las apps Intel.
• About the Rosetta translation environment — Apple Developer Documentation — alcance, proceso de traducción y ejecutables que Rosetta no puede traducir.
• macOS 27 Golden Gate Release Notes — Apple Developer Documentation — documenta el corte general del software Intel en macOS 28.0, salvo juegos antiguos, y los cambios de transición en macOS 27.
• Building a universal macOS binary — Apple Developer Documentation — slices arm64/x86_64, componentes que deben auditarse y claves de Launch Services.
• Porting your macOS apps to Apple silicon — Apple Developer Documentation — plan de portabilidad y advertencias para extensiones y tecnologías antiguas.
• What's new for enterprise in macOS Golden Gate 27 — Soporte de Apple — confirma Rosetta durante macOS 27 y documenta gestión de apps y binarios, privacidad y Platform SSO.
• LSRequiresNativeExecution — Apple Developer Documentation — comportamiento de la clave que exige ejecución nativa.