Xcode 27 convierte los deployment targets antiguos en errores de compilación. Esta es la línea.

Corrección del 19 de octubre de 2026: La afirmación anterior de que el soporte para macOS 11 y versiones anteriores terminaría en la Mac App Store en abril de 2027 no estaba respaldada. El anuncio de Apple establece requisitos de SDK para otras plataformas, pero no fija ese plazo para macOS. Se han corregido los pasajes afectados.

Abre un proyecto de app para Mac que ha compilado sin problemas durante años, cambia a la beta de Xcode 27, pulsa build y se detiene:

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

En Xcode 26 esa frase era una advertencia amarilla que podías ignorar y seguir adelante. En Xcode 27 es un error rojo y la compilación no continúa. Ese es todo el cambio, y es más pequeño y más grande de lo que parece: más pequeño porque la documentación de Apple ha declarado durante años un mínimo de macOS 11 e iOS 15; más grande porque Xcode nunca lo hizo cumplir, y una gran cantidad de apps en producción dependen silenciosamente de eso.

Este artículo expone lo que Xcode 27 realmente exige (según las propias tablas y notas de la versión de Apple), lo que Xcode 26 realmente permitía (según el SDK en nuestro propio disco), a quién afecta, el ajuste no documentado que convierte el error de nuevo en advertencia, y cómo se distinguen los deployment targets compatibles de los requisitos de SDK de la App Store según la plataforma.

Puntos clave

• Los deployment targets admitidos por Xcode 27 son macOS 12–27, iOS/iPadOS/tvOS 15–27, watchOS 9–27, visionOS 1–27, DriverKit 21–27, según la página de soporte de Xcode de Apple para la beta 6. Por debajo de esos valores, la compilación falla.
• Xcode 26 documentaba macOS 11 como su mínimo, pero en realidad aceptaba 10.13. Revisamos el archivo de configuración del SDK de macOS 26.0: 34 deployment targets válidos, empezando en 10.13. Xcode 27 cierra esa brecha al convertir el rango documentado en el rango exigido.
• El mínimo de macOS cambió durante la beta. En junio, la nota de Apple decía que el back-deployment Universal era "hasta macOS 27 inclusive"; los desarrolladores lo interpretaron como Big Sur. La nota de la beta 6 dice "macOS 12 y posteriores". Planifica para Monterey, no para Big Sur.
• Existe una vía de escape no documentada, __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO, que según se informa convierte el error de nuevo en advertencia. No tiene soporte oficial, puede desaparecer, y no cambia el hecho de que Apple no está probando esos targets.
• Los requisitos de SDK de la App Store dependen de la plataforma. Apple ha anunciado para abril de 2027 el uso de los SDK de iOS/iPadOS 27, tvOS 27, visionOS 27 y watchOS 27 o posteriores. Ese anuncio no establece una fecha límite para dar soporte a macOS 11 o versiones anteriores en la Mac App Store.

Las cifras, oficialmente

La página de soporte de Xcode de Apple publica una tabla de para qué puede compilar cada versión de Xcode. Esta es la comparación que importa:

Plataforma	Xcode 26.6	Xcode 27 beta 6
macOS	11 – 26.5	12 – 27
iOS / iPadOS	15 – 26.5	15 – 27
tvOS	15 – 26.5	15 – 27
watchOS	8 – 26.5	9 – 27
visionOS	1 – 26.5	1 – 27
DriverKit	20 – 25.5	21 – 27

Léela con atención, porque el titular "Xcode 27 sube el mínimo" solo es cierto a medias. Para iOS, el mínimo documentado ha sido 15 durante todo Xcode 26 y se mantiene en 15 en Xcode 27. Para macOS sube una versión, de 11 a 12. Para watchOS, de 8 a 9. Sobre el papel, es un endurecimiento modesto.

Lo que no está sobre el papel es que las cifras de Xcode 26 nunca se hicieron cumplir.

Lo que Xcode 26 realmente permitía

Cada SDK dentro de Xcode incluye un archivo de configuración que declara qué deployment targets considera válidos. En nuestra máquina, con Xcode 26.0.1 (17A400) instalado, ese archivo está en:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

Leerlo requiere un solo comando:

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Salida en Xcode 26.0.1:

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

Así que, mientras la tabla de Apple decía "macOS 11", el SDK decía "10.13", y Xcode te dejaba escribir 10.13 en el campo del deployment target, te advertía, y aun así compilaba. Michael Tsai describe la práctica sin rodeos: los desarrolladores "han podido introducir targets antiguos manualmente", y mucho software independiente para Mac hizo exactamente eso para mantener a los usuarios de High Sierra, Mojave y Catalina en la versión actual.

Si tienes instalada la beta de Xcode 27, ejecuta el mismo comando contra su SDK (sustituyendo Xcode-beta.app) y verás el nuevo mínimo. Nosotros no tenemos la beta en esta máquina, así que nos basamos en la tabla de Apple y en los informes de los desarrolladores para la cifra de 12.0, en lugar de leerla nosotros mismos del archivo.

De advertencia a error

El diagnóstico en sí no es nuevo. El sistema de compilación de Apple lleva años emitiendo "the range of supported deployment target versions is X to Y" como advertencia. Lo que cambia en Xcode 27 es su severidad.

Un artículo en bleepingswift.com cita la forma que toma en iOS tal como aparece en Xcode 27:

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

La forma para macOS es el mismo mensaje con MACOSX_DEPLOYMENT_TARGET y un rango de 12.0 a 27.0.99. Se dispara por cada target, así que una app con una extensión, un widget y un test bundle que hereden un target antiguo lo mostrará cuatro veces, y arreglar solo la app principal no despeja la compilación.

Los mantenedores de Vienna RSS se toparon con esto el 10 de junio, dos días después de que saliera la beta: su target era 10.13, compilaba sin advertencias ni errores en Xcode 26, y en Xcode 27 "it's a hard requirement (build error)". Su siguiente preocupación es la que comparte todo desarrollador de Mac en esta situación: no se espera que Xcode 26 tenga soporte en macOS 27, así que la solución de "quedarse con el Xcode antiguo" tiene fecha de caducidad.

Qué cambió entre junio y la beta 6

El mínimo de macOS no fue estable durante el período de beta, y vale la pena saber qué versión de la historia has leído.

En junio, la nota de la versión sobre Intel decía, según se cita en los Apple Developer Forums:

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

Eso no dice nada sobre un mínimo. El resumen del primer día de Tsai interpretó la situación como "the minimum you can target is now Big Sur (or Monterey for Apple Silicon Macs)", y el issue de ViennaRSS decía macOS 12 sin rodeos. Las notas actuales de la beta 6 lo resuelven:

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. (162138432)

El mismo número de issue, redactado de nuevo para nombrar macOS 12. La actualización de septiembre de Tsai señala lo mismo: "Xcode 27 Beta 6 documents macOS 12.0 as the minimum deployment target now". Si tu plan de migración estaba construido sobre Big Sur, revísalo para Monterey.

A quién afecta esto realmente

Tres grupos, en orden decreciente de dolor.

Apps de Mac que aún dan soporte desde High Sierra hasta Big Sur

Este es el grupo del que trata la publicación de Tsai, y el que menos simpatía recibe de la plataforma. Matthias Gansrigler-Hrad, de Eternal Storms, lo expresó directamente en Mastodon:

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

Para estos desarrolladores, Xcode 27 es una elección forzada: subir el mínimo y dejar fuera a los usuarios de sistemas de 2017–2020, o quedarse en Xcode 26 y renunciar al SDK de macOS 27 y a todo lo que depende de él.

Apps de iOS y, sobre todo, librerías de iOS por debajo de 15

El mínimo de Apple para iOS ha sido 15 desde Xcode 26, así que una app que ya esté en 15 no nota nada. Pero el ecosistema estaba lleno de librerías que declaraban mínimos más bajos, y cada una genera ahora el diagnóstico en todos los proyectos que la importan. Los rastreadores de issues de GitHub se llenaron en la primera semana de junio con solicitudes casi idénticas tituladas "Support Xcode 27: raise minimum iOS deployment target to 15", contra el Facebook iOS SDK, que declaraba .iOS(.v12) en su Package.swift, contra Adjust, DataDog, SDWebImage y otros. Si dependes de un paquete cuyo mantenedor no ha respondido, estás bloqueado hasta que lo haga o hasta que hagas un fork.

Cualquiera con un target antiguo escondido en una dependencia

El caso sutil. Tu app apunta a 15. Un paquete Swift transitivo apunta a 13. Xcode 27 compila ese paquete con tu toolchain, ve 13, y hace fallar tu compilación. No existe una anulación del lado del consumidor en Swift Package Manager: la conclusión de bleepingswift, que coincide con la nuestra, es que "packages declaring older minimums in their platforms declaration require either upgrading to a newer package version or forking and updating the requirement yourself".

La vía de escape oculta

Existe una, y deberías conocerla y tener cuidado con ella.

Ighor July, escribiendo el 24 de julio en un texto que Tsai cita, informa que en la beta de Xcode 27 "a hidden setting changed those errors back into warnings, and the compiler still produced the older targets I tested". Describe el ajuste como "undocumented, absent from the normal Xcode interface, and currently being tested only" en un toolchain beta. Un lector de la publicación de Tsai, Harald Striepe, lo nombra:

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

Es un build setting, así que va donde van los build settings: un archivo .xcconfig asociado a la configuración, o un ajuste User-Defined añadido al final del panel Build Settings del target. Al establecerlo, la comprobación del deployment target vuelve al comportamiento de Xcode 26.

Ahora las salvedades, que no son pequeñas.

No tiene soporte oficial. Dos guiones bajos iniciales son la convención de Apple para ajustes internos. Puede ser renombrado o eliminado en cualquier beta, incluida la que llegue justo después de que empieces a depender de él.

Restaura la advertencia, no las pruebas. La valoración de Tsai sobre todo el cambio merece citarse por completo, porque es el marco honesto:

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

Desactivar el error te devuelve a compilar para un target que Apple ya no probaba antes y que ahora explícitamente no soporta. Lo que estuviera roto en Catalina en Xcode 26 seguirá roto.

El ajuste oculto no demuestra que la App Store acepte el resultado. Comprueba por separado los requisitos de cada plataforma.

Los requisitos de SDK de la App Store dependen de la plataforma

Los deployment targets compatibles con una versión de Xcode y los requisitos de SDK para subir apps a la App Store son condiciones diferentes. La versión de SDK necesaria para un envío debe comprobarse para la plataforma concreta.

El 9 de septiembre de 2026, Apple anunció los requisitos mínimos de SDK para abril de 2027: las apps para iOS/iPadOS, tvOS, visionOS y watchOS deberán compilarse con el SDK de la versión 27 o posterior de su plataforma. El anuncio no indica un día exacto de abril ni una versión mínima del SDK de macOS.

La página de próximos requisitos de Apple recoge requisitos de SDK desde el 28 de abril de 2026 para esas mismas plataformas. También enumera requisitos independientes para las apps de Mac. Esto no implica que las apps de Mac estén exentas de todos los requisitos ni que exista un plazo universal de SDK para todas las plataformas.

Según los requisitos del sistema de Xcode de Apple, Xcode 27 admite deployment targets de macOS 12–27 y iOS/iPadOS 15–27. Esos mínimos del toolchain son distintos de un requisito de SDK para subir apps. El anuncio de abril de 2027 no establece una fecha límite de la Mac App Store para dar soporte a macOS 11 o versiones anteriores.

El ajuste no documentado tampoco demuestra que una compilación que lo utilice vaya a superar la validación de la App Store. Comprueba los requisitos actuales de la plataforma y de la vía de distribución antes de fijar una fecha de fin de soporte.

Tampoco hay garantía de que Xcode 26, las compilaciones para deployment targets antiguos o la distribución directa con Developer ID sigan siendo válidos indefinidamente. Comprueba el toolchain, los sistemas operativos de desarrollo y de destino, y los requisitos vigentes de firma, notarización y distribución.

Conservar Xcode 26, y por qué eso deja de funcionar

La mitigación obvia es instalar ambos. Herramientas como xcodes facilitan mantener Xcode 26.6 junto a la beta de 27 y cambiar entre ellas con xcode-select. Para un proyecto con un target de 10.13 que todavía necesitas publicar este año, esa es la decisión correcta.

Tiene fecha de caducidad. La tabla de soporte de Apple indica que Xcode 26.6 requiere "macOS Tahoe 26.2 – macOS Tahoe 26.x". Nada dice que funcione en macOS 27, y la lectura de Tsai es que "using old versions of Xcode isn't a great solution because they aren't supported on Golden Gate". Puede que arranque; Apple no lo arreglará si no lo hace. Y añade un costo más sutil:

Swift also makes it more difficult to call newer APIs when using an older SDK.

Quedarse en Xcode 26 significa quedarse en el SDK de macOS 26, lo que implica que las API de macOS 27 solo son accesibles mediante dynamic lookup, o no lo son en absoluto. Para una app en modo mantenimiento, está bien. Para cualquier cosa que estés desarrollando activamente, es un estrangulamiento lento.

Xcode 27 en sí mismo es exclusivo de Apple silicon

Este es un cambio independiente que llega en la misma versión y se enreda con la historia del deployment target, así que conviene dejar claro cuál es cuál.

Las notas de la versión son inequívocas: "Xcode 27 will only install and run on Apple silicon Macs". El binario es solo arm64, como confirmó en los foros quien posee un MacBook Pro con Intel, después de que la línea "requires macOS Tahoe 26.4 or later" de las notas le llevara a esperar lo contrario: Tahoe funciona en un puñado de Macs Intel, Xcode 27 no.

El SDK sigue siendo Universal. Puedes compilar slices x86_64 y binarios Universal desde Xcode 27; simplemente tienes que hacerlo en Apple silicon. Es un requisito de hardware para el desarrollador, no una restricción de distribución sobre la app.

El otro cambio relacionado con Intel: Universal deja de ser el valor por defecto en 27.0

Un elemento más relacionado con Intel en las notas de la beta 6, archivado bajo "Intel Deprecation", que la mayoría de la cobertura pasó por alto:

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. (161837535)

Esto es lógico —macOS 27 no se ejecuta en ningún Mac con Intel, así que un target exclusivo de 27.0 no tiene máquinas Intel en las que correr—, pero tiene un efecto secundario. Rosetta sigue presente en macOS 27, y la nota para desarrolladores del 1 de septiembre de Apple reafirmó que 27 es su última versión. Una app exclusiva de 27.0 que deja x86_64 fuera por defecto tampoco puede ejecutarse bajo Rosetta en Apple silicon, algo que solo importa si distribuías un host de plug-ins exclusivo para Intel o algo similar. Añade x86_64 a ARCHS explícitamente si lo necesitas.

Un tercer mínimo que nadie menciona: libc++ en 11.0

Escondido en la misma lista de Deprecations: "The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0". Es un mínimo distinto, más bajo que el mínimo de 12.0 del sistema de compilación, y se aplica al runtime de C++ contra el que enlazas, no al deployment target que declaras. En la práctica solo aparece si has sorteado la comprobación del sistema de compilación —con el ajuste oculto, por ejemplo— y sigues apuntando a 10.15 o anterior con código C++. Entonces libc++ es lo siguiente que te detiene.

Cómo arreglarlo: dependencias

Para tus propios targets, el arreglo es un número en un campo de texto. Para las dependencias:

CocoaPods. Añade un hook post_install que reescriba el deployment target de cada pod target al mínimo, luego ejecuta pod install y limpia la carpeta de compilación. La versión del hook de bleepingswift tiene la forma estándar; lo importante es que se aplique a todos los pod targets, no solo a los que se quejan hoy.

Swift Package Manager. No existe una anulación. Tus opciones son: actualizar a una versión del paquete que haya elevado su platforms; abrir o votar el issue; o hacer un fork, editar Package.swift, y apuntar tu proyecto al fork hasta que el upstream se ponga al día. Revisa primero el issue tracker: para los SDK principales, alguien presentó la solicitud en la primera semana de junio y normalmente hay un pull request adjunto.

Frameworks vendorizados y XCFrameworks. Estos llevan su propio mínimo en su Info.plist y en sus Mach-O load commands. Xcode 27 no se niega a enlazar un framework binario antiguo, pero el linker advertirá sobre el desajuste de versión, y el comportamiento en el target antiguo es exactamente el que se probó, es decir, ninguno.

Qué significa "honesto" aquí

Vale la pena detenerse un momento en el planteamiento de Tsai, porque cambia con qué deberías estar enfadado.

Xcode 26 no daba soporte a macOS 10.13. Te permitía escribir 10.13, y generaba código, pero Apple no probaba que los frameworks del SDK de la versión 26 se comportaran correctamente en un sistema operativo de 2017. Los desarrolladores que publicaban esas compilaciones estaban haciendo su propio QA contra un SO que Apple había dejado atrás, y en la mayoría de los casos funcionaba, porque los frameworks son retrocompatibles por diseño. Pero ese "en la mayoría de los casos" cargaba con mucho peso en esa frase, y cada año la brecha entre el SDK y el target se ampliaba.

Xcode 27 convierte el rango documentado en el rango real. Eso es una pérdida para los usuarios de Macs antiguos y para los desarrolladores que los atendían. No es la pérdida de algo que Apple prometiera alguna vez.

El matiz regulatorio

Un hilo más. El 26 de agosto, Tsai recopiló comentarios sobre la Cyber Resilience Act de la UE, cuyas principales obligaciones entran en vigor el 11 de diciembre de 2027 y que exige actualizaciones de seguridad durante al menos cinco años. Un lector identificado como Frederik planteó la interacción con la App Store:

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

La planificación del mantenimiento depende de las decisiones sobre el deployment target, el toolchain y la vía de distribución. El anuncio de SDK de Apple para abril de 2027 no obliga por sí solo a terminar el soporte de macOS 11 en esa fecha. Comprueba las opciones reales de mantenimiento y actualización de tu app y consulta a un profesional jurídico cualificado sobre las obligaciones legales.

Lista de verificación para la migración

Para una app de Mac con un target antiguo, en orden:

1. Inventaría a tus usuarios reales. Si tus analíticas dicen que nadie está por debajo de macOS 12, esto es un cambio de una línea y una nota de la versión. La mayoría de las apps están aquí.
2. Fija el deployment target en 12.0 (macOS) o 15.0 (iOS) en cada target, incluyendo extensiones, helpers y tests. Compila con la beta de Xcode 27 y elimina cada instancia del diagnóstico.
3. Audita las dependencias en busca de declaraciones platforms y podspecs por debajo del mínimo. Haz fork de lo que sea necesario.
4. Decide qué hacer con los rezagados. Si necesitas seguir publicando para usuarios de macOS 10.13–11, comprueba los requisitos del toolchain, del entorno de ejecución y de la vía de distribución. Elige y prueba un plan de soporte viable y comunica la decisión real, sin programar una compilación final en función de un plazo no respaldado.
5. No envíes el ajuste oculto a producción a menos que hayas probado tú mismo el resultado en el SO antiguo y aceptes que el ajuste puede desaparecer en la próxima beta.
6. Si apuntas exclusivamente a 27.0, revisa ARCHS. Puede que acabes de descartar x86_64 sin darte cuenta.

Solución de problemas comunes

El error persiste después de subir el target de la app

Otro target del proyecto todavía tiene el valor antiguo. Selecciona el proyecto (no un target) en el navegador, revisa el deployment target a nivel de proyecto, y luego cada target y cada test bundle. Los widgets y las extensiones de app son los culpables habituales.

El error menciona un paquete del que no dependo directamente

Una dependencia transitiva. Usa swift package show-dependencies (o el package graph de Xcode) para averiguar quién lo trae, y luego actualiza ese paquete intermedio o haz fork del paquete final.

xcodebuild desde la línea de comandos falla pero la interfaz gráfica de Xcode compila

Comprueba qué toolchain está usando la línea de comandos: xcode-select -p. Puede que tengas la interfaz gráfica en la 26 y la línea de comandos en la 27, o viceversa.

Activé el flag oculto y no cambió nada

El flag tiene que ser visible para el sistema de compilación en el nivel donde se ejecuta la comprobación; un xcconfig a nivel de proyecto es el lugar más seguro. Si solo está fijado en un target, los demás targets seguirán dando error. Si sigue sin hacer nada, es posible que la beta que tienes lo haya eliminado.

Mis runners de CI son Intel

Xcode 27 no se instalará en ellos. Esto es una migración de hardware, no un problema de configuración. Los proveedores hospedados migraron a runners con Apple silicon hace tiempo; los Mac mini con Intel autogestionados ya están al final de su vida útil para compilaciones con el toolchain actual.

Preguntas frecuentes

¿Xcode 27 sube el mínimo de iOS?

No sobre el papel: la tabla de Apple dice iOS 15 desde Xcode 26. Lo que cambia es la exigencia: los targets por debajo de 15 que compilaban con una advertencia en Xcode 26 fallan en Xcode 27.

¿Cuál es el mínimo de macOS en Xcode 27?

macOS 12 Monterey, según la página de soporte de Xcode de Apple y las notas de la beta 6. Antes, en el ciclo de la beta, la nota se interpretaba como Big Sur; esa lectura está desactualizada.

¿Todavía puedo compilar apps Universal (Intel + Apple silicon)?

Sí, desde un Mac con Apple silicon. El SDK de macOS 27 admite el back-deployment Universal hasta macOS 12 y posteriores. El único caso en que x86_64 se excluye por defecto es un target fijado en 27.0 o superior.

¿Cuándo tengo que pasarme a Xcode 27?

Depende de la plataforma y de la vía de distribución. Apple ha anunciado para abril de 2027 los SDK de iOS/iPadOS 27, tvOS 27, visionOS 27 y watchOS 27 o posteriores; ese anuncio no establece un plazo para macOS. Comprueba los requisitos actuales de tu envío concreto. La distribución directa también exige comprobar el toolchain, los sistemas operativos de desarrollo y de destino, la firma y la notarización; Xcode 26 no ofrece una garantía indefinida.

¿Es seguro el ajuste oculto para compilaciones de la App Store?

Se desconoce. Nadie ha informado de un envío compilado con él, y es un flag interno no documentado. Trátalo como una herramienta para compilaciones locales y ramas legacy, no para tu pipeline de publicación.

Conclusión

El cambio de deployment target en Xcode 27 es una edición pequeña con una cola larga. Apple no subió mucho el mínimo —una versión en macOS, ninguna en iOS—, pero dejó de fingir que el mínimo era opcional, y una década de software independiente para Mac se construyó sobre esa ficción. El error de compilación que obtienes hoy es fácil de arreglar si tus usuarios están en sistemas modernos, e imposible de arreglar correctamente si no lo están.

Averigua cuál es tu situación. Si todavía publicas para macOS 11 o anterior, revisa tu base de usuarios y las opciones reales de toolchain, pruebas y distribución antes de decidir el fin del soporte. El anuncio de Apple para abril de 2027 no fija ese plazo para la Mac App Store. Si tus usuarios ya están en sistemas más recientes, sube el número, arregla las dependencias, revisa ARCHS si eres exclusivo de 27, y sigue adelante.

Lectura relacionada: audita tus apps de Intel antes de que termine Rosetta, el límite de compatibilidad de macOS 27 con Intel, arreglar una configuración de desarrollo en macOS Tahoe, y las mejores herramientas para desarrolladores de Mac este año.