Durante la transición a Apple Silicon, publicar una aplicación universal fue la decisión más prudente: un único paquete contenía código arm64 para los nuevos Mac y x86_64 para los modelos Intel. Seis años después del primer Mac con M1, Apple ha empezado a cerrar esa etapa y permite que determinadas aplicaciones ya publicadas en la Mac App Store abandonen la arquitectura Intel.
La novedad afecta a las aplicaciones universales cuyo target sea macOS 13 o posterior. Si cumplen esa condición, pueden enviar una actualización que contenga únicamente arm64, aunque sus versiones anteriores también fueran compatibles con Mac Intel. Hasta ahora, la posibilidad de publicar solo para Apple Silicon estaba pensada principalmente para aplicaciones que nunca habían ofrecido soporte Intel; el cambio anunciado en las notas de App Store Connect elimina esa restricción para las aplicaciones universales elegibles.
No se trata de un requisito inmediato ni de una migración automática. Mantener un binario universal continúa siendo válido. Apple ofrece una nueva decisión de producto: conservar durante más tiempo la compatibilidad con el parque Intel o simplificar la aplicación y sus entregas alrededor de una única arquitectura.
Tres cambios relacionados, pero diferentes
El final del Mac con Intel mezcla tres calendarios que conviene separar. Confundirlos puede llevar tanto a abandonar usuarios antes de tiempo como a conservar trabajo que ya no aporta suficiente valor.
El primero es el hardware capaz de instalar cada versión del sistema. Apple ha comunicado a los desarrolladores que macOS 26 es la última versión de macOS compatible con ordenadores Mac basados en Intel. macOS 27 solo puede instalarse en Mac con Apple silicon. Un Mac Intel que permanezca en macOS 26 no se transforma por ello en un dispositivo inutilizable, pero deja de avanzar a las siguientes versiones principales del sistema.
El segundo calendario corresponde a Rosetta, la capa que traduce instrucciones x86_64 cuando una aplicación Intel se ejecuta en Apple silicon. Desde macOS 26.4, el sistema puede mostrar una notificación al abrir aplicaciones que todavía dependen de Rosetta. Apple mantendrá Rosetta como herramienta de propósito general durante macOS 27 y, a partir de macOS 28, conservará solo un subconjunto de su funcionalidad para determinados juegos antiguos sin mantenimiento que dependen de frameworks Intel. Apple detalla esta transición en su aviso sobre los próximos cambios de Rosetta.
El tercero es la política de la Mac App Store. Desde junio de 2026, una aplicación universal con macOS 13 o posterior como versión mínima puede retirar x86_64 y enviar una compilación solo arm64. Esta posibilidad no depende de que Rosetta desaparezca: una aplicación universal actual ya ejecuta su segmento arm64 de forma nativa en Apple silicon y no necesita Rosetta. Retirar el soporte directo para Intel sirve para dejar de mantener los Mac con Intel, no para corregir la ejecución de una aplicación universal en los Mac modernos.
La diferencia también permite identificar la prioridad. Si una aplicación todavía se distribuye solo como x86_64, debe incorporar arm64 cuanto antes para no depender de Rosetta. Si ya es universal, el futuro de Apple silicon está cubierto y la retirada de x86_64 puede decidirse con más calma.
Qué se gana al publicar únicamente para Apple silicon
Un ejecutable universal contiene dos segmentos Mach-O. El código fuente se compila para cada arquitectura, se enlaza por separado y finalmente se combina en un mismo archivo. Al retirar x86_64, desaparece una de esas representaciones de código. El ejecutable principal, los frameworks propios, las extensiones y otros binarios universales pueden reducir su tamaño.
Esto no implica que la aplicación completa vaya a ocupar exactamente la mitad. Imágenes, modelos, vídeos, catálogos de recursos y otros datos independientes de la CPU siguen siendo los mismos. La reducción real depende de cuánto pesan los ejecutables frente al resto del paquete. En una utilidad pequeña puede ser apreciable; en una aplicación dominada por recursos, mucho menor. Aun así, Apple señala como ventajas tanto la reducción de descarga y almacenamiento como la simplificación del desarrollo.
La ganancia más duradera suele estar en el mantenimiento. Dejar una sola arquitectura permite:
- eliminar compilaciones y pruebas específicas para
x86_64; - dejar de exigir segmentos Intel a frameworks, librerías, ayudantes y herramientas internas;
- retirar rutas de código condicionadas por la arquitectura;
- simplificar la matriz de integración continua y los equipos de prueba;
- optimizar sin tener que conservar supuestos propios del hardware Intel.
La simplificación puede ser especialmente valiosa cuando una dependencia ha dejado de publicar binarios Intel o cuando una característica moderna requiere mantener implementaciones alternativas. El coste de compatibilidad no está solo en los minutos de compilación: aparece en cada actualización de dependencias, cada incidencia específica de plataforma y cada entrega que debe comprobarse en hardware antiguo.
Qué se pierde al retirar x86_64
La contrapartida es clara: la nueva versión ya no puede ejecutarse en ningún Mac Intel, aunque ese equipo tenga macOS 13, 14, 15 o 26. Elevar el deployment target y retirar una arquitectura son filtros distintos. Cumplir el requisito de macOS 13 permite enviar el binario a la tienda, pero no hace compatible arm64 con un procesador Intel.
Por eso la decisión no debería basarse solo en la antigüedad de los modelos. Conviene medir cuántas instalaciones activas siguen utilizando Intel, qué tipo de clientes representan y cuánto tiempo se ha prometido soporte. Una aplicación de consumo puede tener una proporción residual, mientras que una herramienta profesional, educativa o corporativa puede seguir instalada en equipos con ciclos de renovación mucho más largos.
También importa el modelo de negocio. En una aplicación de pago único, impedir que un cliente existente reciba nuevas funciones tiene un impacto diferente al de un servicio que necesita mantener una versión segura y compatible para acceder a su infraestructura. Si existen documentos compartidos, sincronización o formatos que evolucionan, una versión Intel congelada puede necesitar un periodo de compatibilidad adicional en el servidor.
Una estrategia razonable consiste en publicar antes una última versión universal de mantenimiento. Esa entrega puede comunicar el cambio dentro de la aplicación, resolver problemas conocidos y fijar un formato de datos que siga siendo interoperable durante un tiempo. La actualización posterior, ya solo arm64, debe acompañarse de unas notas de versión claras. La disponibilidad de compilaciones anteriores para usuarios concretos no debería asumirse como sustituto de este plan: conviene comprobar el comportamiento real de la ficha y de las actualizaciones en App Store Connect.
Cambiar Architectures no es toda la migración
Apple resume el cambio técnico en una instrucción: configurar la compilación como arm64, reconstruir y enviar la aplicación. En Xcode, el ajuste relevante es Architectures (ARCHS) del target. Si el proyecto utiliza archivos .xcconfig, la intención puede expresarse directamente:
ARCHS = arm64
El ajuste debe aplicarse a la configuración utilizada para archivar, normalmente Release, y al nivel correcto del proyecto. No conviene confundirlo con Build Active Architecture Only (ONLY_ACTIVE_ARCH). Este último puede acelerar compilaciones locales generando solo la arquitectura del Mac actual, pero no define por sí solo las arquitecturas que tendrá el archivo destinado a distribución.
La revisión tampoco termina en el ejecutable principal. Un paquete de macOS puede contener varios binarios:
- extensiones de la aplicación o del sistema;
- servicios XPC;
- herramientas auxiliares y agentes de inicio;
- frameworks y librerías dinámicas incrustadas;
- plug-ins, importadores o generadores de miniaturas;
- ejecutables copiados mediante fases de compilación propias.
Todos los componentes que vayan a ejecutarse deben contener arm64. Un framework solo Intel no se vuelve compatible porque la aplicación principal se compile para Apple silicon: el enlazador puede impedir el archivo o el problema puede aparecer al cargar dinámicamente el componente.
Este es un buen momento para localizar condiciones que ya no representan una variante real. Por ejemplo, un proyecto puede haber acumulado implementaciones separadas durante la transición:
#if arch(x86_64)
let preferredBatchSize = 4
#elseif arch(arm64)
let preferredBatchSize = 12
#endif
Cuando el producto solo admite arm64, la rama Intel deja de compilarse y puede eliminarse. Aun así, no todas las diferencias de rendimiento deben fijarse por arquitectura. La familia Apple silicon incluye equipos con capacidades muy distintas; cuando exista una API para consultar memoria, núcleos, disponibilidad de una característica o presión térmica, esa capacidad real suele ser una señal mejor que asumirla a partir de arm64.
También deben revisarse los scripts que descargan artefactos según CURRENT_ARCH, los paquetes binarios XCFramework, el código C o C++ con intrínsecos Intel y cualquier herramienta externa que se ejecute durante la compilación. Retirar la salida x86_64 puede permitir borrar varias excepciones, pero primero hay que comprobar que la ruta arm64 no dependía accidentalmente de ellas.
Verificar el archivo que llegará a la tienda
La comprobación debe hacerse sobre un Archive de distribución, no sobre una compilación Debug del equipo de desarrollo. Xcode puede generar localmente solo la arquitectura activa y producir un resultado diferente al archivado final.
Para inspeccionar el ejecutable principal pueden utilizarse lipo o file sobre el contenido del .app exportado:
lipo -archs MiAplicacion.app/Contents/MacOS/MiAplicacion
file MiAplicacion.app/Contents/MacOS/MiAplicacion
El resultado esperado es únicamente arm64. La misma comprobación debe repetirse con frameworks, extensiones, servicios XPC y ayudantes incrustados. Además de confirmar que no queda x86_64, es importante probar una instalación limpia y una actualización desde la última versión universal. Son recorridos diferentes: el segundo puede conservar cachés, bases de datos, plug-ins o procesos auxiliares instalados por una versión anterior.
Después de procesar la subida, App Store Connect muestra los requisitos calculados para cada compilación. En Build Metadata se pueden comprobar tanto la versión mínima de macOS como las arquitecturas admitidas. Esa pantalla es la última oportunidad para detectar que una configuración heredada, un valor de LSMinimumSystemVersion o un ajuste aplicado en un nivel inesperado no coincide con lo previsto.
Las pruebas funcionales también deberían aprovechar el cambio. Si se mantenían rutas alternativas para Intel y Apple silicon, la cobertura puede concentrarse ahora en la única que se distribuirá. Eso no reduce la diversidad de Mac con Apple silicon: siguen existiendo distintas generaciones, cantidades de memoria, GPU y configuraciones. Retirar Intel elimina un eje de la matriz, no la necesidad de probar el producto en equipos representativos.
Una retirada gradual suele ser mejor que una fecha arbitraria
La nueva política de la Mac App Store abre la puerta, pero no indica cuándo debe atravesarla cada aplicación. La fecha adecuada aparece al combinar cuatro señales: uso real de Intel, coste de mantenerlo, compromisos con clientes y beneficio técnico de concentrarse en Apple silicon.
Si una dependencia crítica exige abandonar x86_64, el cambio puede desbloquear mejoras que de otro modo serían inviables. Si el soporte Intel apenas necesita trabajo y todavía existe una base relevante de usuarios, mantener una última rama universal durante más tiempo puede ser una inversión razonable. En ambos casos conviene separar el mantenimiento de las nuevas funciones: la rama Intel puede recibir correcciones críticas durante un periodo definido mientras el desarrollo principal avanza solo en arm64.
El anuncio sobre Rosetta añade urgencia a las aplicaciones que aún no son nativas, pero no obliga a precipitar la retirada de Intel en las que ya son universales. Para estas últimas, el cambio importante es otro: Apple ya permite elegir. A partir de ahora, conservar x86_64 deja de ser una condición heredada de la tienda y pasa a ser una decisión explícita de soporte que debería revisarse en cada ciclo de producto.