Redimensionamiento del iPad en iOS 27: la solución alternativa tiene un costo

Las notas de la versión de iOS 27 de Apple ofrecen una solución alternativa de una sola línea para las apps de iPad que no admiten redimensionamiento continuo: declarar compatibilidad con las cuatro orientaciones de interfaz en el Info.plist.¹ Lo que la nota omite es que el sistema intersecta esa declaración de toda la app con las orientaciones admitidas por cada view controller.² Si amplías el conjunto de toda la app, lo amplías en todas partes, iPhone incluido, a menos que cada view controller restringido sobrescriba supportedInterfaceOrientations.

La versión de titular de este cambio también se equivoca sobre el estado actual. La intención de Apple es que las orientaciones declaradas dejen de condicionar el redimensionamiento continuo. La nota de la versión que registra esa intención está archivada bajo Known Issues, porque en la Beta 4 todavía lo condicionan.¹

Ambas mitades importan. El comportamiento es un error en el camino hacia un cambio deliberado, y la solución alternativa para ese error tiene un efecto secundario que nadie documenta en el mismo lugar.

Resumen

En iOS y iPadOS 27 Beta 4, una app de iPad compilada con el SDK de iOS 27 cuyo UISupportedInterfaceOrientations omita alguna de las cuatro orientaciones se trata como no redimensionable de forma continua, algo que Apple incluye como problema conocido junto con la afirmación de que las orientaciones “ya no deberían ser una condición para el redimensionamiento continuo”.¹ La solución alternativa documentada consiste en declarar las cuatro. Al hacerlo, se amplía el conjunto de orientaciones de toda la app, y el sistema determina la rotación comparando las orientaciones de toda la app con las de cada view controller.² Otros cuatro problemas conocidos tienen que ver con UIRequiresFullScreen entregando actualizaciones de redimensionamiento continuo cuando lo previsto son cambios discretos de UIScreen.¹ Ni UIRequiresFullScreen ni UISupportedInterfaceOrientations están obsoletos.³⁴

Lo que dicen realmente las notas de la versión

Seis entradas de la sección UIKit de las notas de iOS y iPadOS 27 Beta 4 tienen que ver con esto; cinco siguen abiertas.¹

La condición en sí, archivada bajo Known Issues:

“En iPad, si tu app de iPad está compilada con el SDK de iOS 27 y su UISupportedInterfaceOrientations no incluye las cuatro orientaciones de interfaz, la app se trata como no redimensionable de forma continua. A partir de iOS 27, las orientaciones de interfaz admitidas ya no deberían ser una condición para el redimensionamiento continuo.”

Fíjate en el tiempo verbal de la segunda oración. “Ya no deberían ser una condición” describe el comportamiento previsto. La entrada existe como problema conocido porque el comportamiento que se está distribuyendo todavía no coincide con esa intención.

Esa distinción cambia lo que hay que hacer. Si las orientaciones hubieran dejado realmente de condicionar el redimensionamiento, el consejo sería eliminar las soluciones alternativas. Como todavía lo condicionan, el consejo es aplicar una y contar con que su motivo acabará desapareciendo.

Cuatro problemas conocidos en torno a UIRequiresFullScreen:

Una app de iPad compilada con el SDK de iOS 27 que establezca UIRequiresFullScreen recibe actualizaciones de redimensionamiento continuo, cuando “cada redimensionamiento debería entregarse como un cambio discreto a una nueva UIScreen con límites actualizados”. Lo mismo ocurre con una app solo para iPhone ejecutándose en iPad, y otra vez dentro de iPhone Mirroring.¹

Un cuarto caso cubre el manejo de orientaciones en iPhone Mirroring: una app compilada con el SDK de iOS 27 obtiene una escena que admite todas las orientaciones “sin importar las orientaciones declaradas en UISupportedInterfaceOrientations o devueltas por UIViewController.supportedInterfaceOrientations”, cuando esas “deberían respetarse hasta que el usuario empiece a redimensionar la ventana”.¹

Uno resuelto: un problema anterior en el que los límites de UIScreen.main cambiaban al redimensionar bajo UIRequiresFullScreen aparece ahora en Resolved Issues.¹ Era un problema conocido activo en una beta previa. Si trabajas con apuntes tomados hace unas semanas, revisa esa entrada antes de repetirla.

Qué te aporta el redimensionamiento continuo

Antes de sopesar el costo, conviene precisar qué es exactamente lo que está condicionado, porque “redimensionable de forma continua” tiene un significado concreto.

Una ventana de iPad puede cambiar de tamaño de dos maneras. Puede saltar entre estados discretos, que es lo que obtiene una app en modo de compatibilidad: el sistema, en palabras de Apple, “mantiene un tamaño de escena consistente para tu app, pero no presenta la escena a pantalla completa”.³ O puede seguir el arrastre y recibir un flujo de tamaños intermedios a medida que el usuario mueve el control de redimensionamiento.

La diferencia se nota en la mano del usuario. Una app redimensionable de forma continua redistribuye su contenido mientras la ventana se mueve. Una que no lo es mantiene su diseño y salta al final, lo que se percibe como lentitud frente a las apps del sistema que sí acompañan el arrastre.

Apple lleva años estrechando el camino de la compatibilidad. UIRequiresFullScreen llegó en iOS 9 para desactivar por completo la multitarea y el redimensionamiento dinámico en iPad.³ Stage Manager en iPadOS 16 y el modo Windowed Apps en iPadOS 26 ampliaron cada uno lo que una ventana puede hacer, y la documentación ahora describe el modo de compatibilidad en función de lo que retiene, no de lo que concede.

Así que la pregunta que responde esta solución alternativa es si tu app de iPad participa en el sistema de ventanas moderno o se queda en un modo que Apple no deja de estrechar. Eso vale un cambio en el Info.plist. No vale hacerlo sin protección, que es el tema de la siguiente sección.

El costo de la solución alternativa

La solución de Apple se enuncia en una sola oración: declarar las cuatro orientaciones de interfaz en el Info.plist.¹ La consecuencia vive en otra página.

UIViewController.supportedInterfaceOrientations documenta cómo se decide la rotación:²

“Para determinar si debe rotar, el sistema compara las orientaciones admitidas por el view controller con las orientaciones admitidas por la app —determinadas por el archivo Info.plist o por el [método] del app delegate— y con las orientaciones admitidas por el dispositivo.”

Tres conjuntos, intersectados. La declaración del Info.plist es un techo, no una instrucción. Una app que se ha mantenido solo en vertical listando una orientación en el Info.plist y sin sobrescribir nada a nivel de view controller pierde su restricción en el momento en que aplica la solución alternativa.

En una app universal, eso cae sobre el iPhone tanto como sobre el iPad. Y la propia guía de Apple desaconseja la declaración amplia ahí: sobre la orientación vertical invertida, “conviene habilitarla para el idiom de iPad. Los dispositivos iOS sin botón de inicio, como el iPhone 12, no admiten esta orientación. Deberías desactivarla por completo para el idiom de iPhone”.² La documentación del Info.plist dice lo mismo desde el otro lado, al señalar que el sistema ignora la orientación invertida “en dispositivos sin botón de inicio”.⁴

Así que la instrucción honesta son dos pasos, no uno:

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

Si te saltas el segundo paso, le habrás dicho a una app universal que gire boca abajo en iPhone con tal de obtener un comportamiento de ventanas en iPad. El fallo no es un cierre inesperado ni un error de compilación. Es una vista de cámara que se voltea mientras alguien la está usando.

Ten en cuenta también que los valores por defecto de supportedInterfaceOrientations difieren según el idiom, y que el sistema solo lo consulta cuando shouldAutorotate devuelve true.² Si has sobrescrito eso, vale la pena releer la interacción antes de dar por sentado que tu restricción se sostiene.

Cómo saber si esto te afecta

Nada de esto produce un error de compilación, así que la auditoría es manual. Tres comprobaciones, en orden descendente según el tiempo que ahorran.

Revisa qué declara realmente tu Info.plist, por target. Las claves de orientación suelen configurarse una vez al crear el proyecto y no se vuelven a tocar, y una app universal puede arrastrar declaraciones distintas para iPhone y iPad mediante UISupportedInterfaceOrientations~ipad. Lee ambas.

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddy devuelve un código de salida distinto de cero cuando falta una clave, lo que ya es la respuesta en el caso de UIRequiresFullScreen: si no hay clave, nunca estuviste en modo de compatibilidad.

Localiza los controladores que restringen la orientación en el código. Son los que siguen funcionando después del cambio en el Info.plist, y su ausencia es lo que hace peligroso ese cambio.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Un resultado vacío combinado con una declaración estrecha en el Info.plist es exactamente el perfil que se rompe: la app es solo vertical únicamente en virtud de la property list, así que ampliarla elimina la única restricción que existía.

Después, mira la app en los dos idioms. El fallo es visual y la señal automatizada es débil. Una prueba de UI que recorre una pantalla y verifica su contenido pasa en cualquier orientación. Lo que buscas es una vista que rote cuando antes no podía, y eso significa ejecutar la compilación de iPhone y girar físicamente el dispositivo o el simulador después del cambio en el Info.plist.

La captura de contenido multimedia, el escaneo de documentos, los campos de firma, los juegos y cualquier cosa con un lienzo de proporción fija: ahí es donde una rotación inesperada sale más cara, y ahí es también donde con más claridad corresponden las sobrescrituras por controlador.

UIRequiresFullScreen se vacía por dentro; no queda obsoleta

Cuatro de los cinco problemas abiertos tienen que ver con UIRequiresFullScreen.¹ La clave que saca a una app de la multitarea del iPad es ahora la condición bajo la cual la entrega de redimensionamientos se comporta de forma incorrecta.

No está obsoleta. La documentación de UIRequiresFullScreen muestra disponibilidad en iOS 9.0 e iPadOS 9.0, sin marca de obsolescencia, indisponibilidad ni beta.³ Tampoco lo está UISupportedInterfaceOrientations, disponible desde iOS 3.2.⁴

Esa combinación merece nombrarse. Una app que establece UIRequiresFullScreen en 2026 compila sin advertencias, se distribuye sin aviso de migración y aterriza en un modo de compatibilidad que Apple no deja de estrechar. La documentación ya describe lo que significa ese modo en sistemas modernos: en iPadOS 26 y posteriores en iPads compatibles con el modo Windowed Apps, y en iPadOS 16 o posteriores en iPads compatibles con Stage Manager, el sistema “mantiene un tamaño de escena consistente para tu app, pero no presenta la escena a pantalla completa”.³

La clave ya no hace lo que dice su nombre. No ha sido retirada, y nada en tu compilación te lo va a decir.

El patrón: la vinculación al SDK decide

Todas las entradas anteriores comparten una condición, y no es la versión del sistema operativo. Cada una se aplica a apps “compiladas con el SDK de iOS 27”.¹

Mismo código fuente, binario distinto, comportamiento distinto. Esto ha aparecido repetidamente en esta versión: las imágenes de los elementos de menú dependen del SDK contra el que enlazaste, con tres comportamientos diferenciados entre dos generaciones de SDK. Y la denegación de contenedores entre equipos de macOS 27 parece ser el caso opuesto, una política a nivel de sistema operativo sin condicionante de SDK, y precisamente por eso vale la pena comprobar la distinción en lugar de darla por supuesta.

La consecuencia práctica para las pruebas: una compilación contra el SDK de iOS 26 y una compilación contra el SDK de iOS 27 son sujetos distintos. Si tu matriz de CI tiene una sola versión de Xcode, solo prueba uno de los dos.

Qué hacer ahora

Decide si de verdad necesitas el redimensionamiento continuo. Si tu app de iPad ya declara las cuatro orientaciones, nada de esto te afecta. La solución alternativa solo es relevante si restringiste las orientaciones deliberadamente.

Si aplicas la solución alternativa, acompáñala de sobrescrituras por controlador. El cambio en el Info.plist es un techo; la restricción tiene que trasladarse a supportedInterfaceOrientations en los controladores que la necesiten, condicionada al idiom.

Audita UIRequiresFullScreen por separado. Cuatro problemas abiertos tienen que ver con esa clave, y tu compilación no la señala. Busca en tus archivos Info.plist, incluido cualquier target que no consideres una app de iPad, ya que uno de los problemas cubre apps solo para iPhone ejecutándose en iPad.

Cuenta con que la condición desaparecerá. Apple afirma que las orientaciones ya no deberían condicionar el redimensionamiento continuo. Cuando eso llegue, el motivo para declarar las cuatro se esfuma, pero el conjunto ampliado de orientaciones se queda en tu Info.plist hasta que alguien lo quite. Deja un comentario explicando por qué está ahí.

Vuelve a revisar las notas antes de actuar. Una de estas seis entradas ya pasó de Known Issues a Resolved. Este artículo refleja la Beta 4 al 2 de agosto de 2026.

Puntos clave

Para quienes desarrollan apps de iPad: - Las orientaciones declaradas siguen condicionando el redimensionamiento continuo en la Beta 4, pese a que Apple afirma que no deberían. Trátalo como un error con solución alternativa, no como el nuevo comportamiento. - La solución alternativa amplía el techo de orientaciones de toda la app. Añade sobrescrituras de supportedInterfaceOrientations por controlador o tu compilación de iPhone empezará a rotar. - Cuatro problemas abiertos tienen que ver con UIRequiresFullScreen entregando actualizaciones de redimensionamiento continuas en lugar de discretas.

Para quien mantiene una app antigua: - UIRequiresFullScreen no está obsoleta y no genera ninguna advertencia, mientras el comportamiento que solicita se sigue estrechando. Audítala de forma explícita. - Todos los problemas de aquí están condicionados a compilar con el SDK de iOS 27, no al sistema operativo que ejecuta el usuario.

Preguntas frecuentes

¿Las orientaciones declaradas ya dejaron de condicionar el redimensionamiento continuo?

En la Beta 4 no. Apple afirma que “a partir de iOS 27, las orientaciones de interfaz admitidas ya no deberían ser una condición para el redimensionamiento continuo”, y archiva esa afirmación bajo Known Issues porque el comportamiento actual sigue dependiendo de ellas.¹

¿Cuál es la solución alternativa concreta?

Declarar las cuatro orientaciones de interfaz en UISupportedInterfaceOrientations.¹ Acompáñala de sobrescrituras de supportedInterfaceOrientations en los view controllers que deban permanecer restringidos, porque el sistema intersecta el conjunto de toda la app con el de cada controlador.²

¿Esto va a afectar mi compilación de iPhone?

Si distribuyes una app universal y dependes solo del Info.plist para restringir la orientación, sí. Apple recomienda desactivar la orientación invertida por completo para el idiom de iPhone, y señala que el sistema la ignora en dispositivos sin botón de inicio.²⁴

¿UIRequiresFullScreen está obsoleta?

No. Su documentación muestra disponibilidad en iOS e iPadOS 9.0 sin marca de obsolescencia.³ Cuatro de los problemas abiertos aquí tienen que ver con ella, así que la ausencia de un marcador de obsolescencia no debe leerse como un respaldo.

¿Debería eliminar la solución alternativa cuando Apple corrija la condición?

Elimina la parte que ya no necesitas y conserva la que te protege. Cuando las orientaciones declaradas dejen de condicionar el redimensionamiento continuo, el motivo para listar las cuatro desaparece y podrás volver a estrechar UISupportedInterfaceOrientations a lo que tu app realmente admite. Las sobrescrituras de supportedInterfaceOrientations por controlador deberían quedarse en cualquier caso, porque expresar las restricciones de orientación donde de verdad corresponden es más duradero que confiar en un techo de toda la app.

El modo de fallo a evitar es el inverso: estrechar de nuevo el Info.plist olvidando que las sobrescrituras eran lo único que mantenía derecha una pantalla de captura.

¿Cómo sé si mi app es actualmente redimensionable de forma continua?

Redimensiona la ventana en un iPad y observa si el diseño sigue el arrastre o salta al final. Si lo sigue, es redimensionable de forma continua. Si salta, comprueba dos cosas: si UIRequiresFullScreen está establecida, lo que desactiva por completo el redimensionamiento dinámico, y si UISupportedInterfaceOrientations lista las cuatro orientaciones, que es la condición que describe este problema conocido.¹³

¿Compilar contra un SDK más antiguo evita todo esto?

Cada entrada está condicionada a compilar con el SDK de iOS 27.¹ Un SDK más antiguo evita estos problemas concretos, y retrasa el cambio final en lugar de impedirlo.

Fuentes