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

Las notas de versión de iOS 27 de Apple ofrecen una solución alternativa de una sola línea para las apps de iPad que no son continuamente redimensionables: declarar compatibilidad con las cuatro orientaciones de interfaz en tu Info.plist.¹ Lo que la nota omite es que el sistema cruza 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, salvo que cada view controller restringido sobrescriba supportedInterfaceOrientations.

Actualización del 24 de agosto: El bloqueo quedó resuelto. Las notas de versión actuales indican el problema 166422120 como corregido – salió de los problemas conocidos entre la edición de la beta 4 y la de la beta 6, y la edición de la beta 7 lo confirma: las orientaciones declaradas ya no condicionan el redimensionamiento continuo, tal como describe la intención citada más abajo.¹ Si publicaste la solución de las cuatro orientaciones, ya no hace falta en las betas actuales; antes de quitarla, vuelve a revisar los view controllers a los que les agregaste sobrescrituras de supportedInterfaceOrientations junto con ella, porque esas sobrescrituras siguen siendo determinantes por sí solas (el comportamiento de intersección descrito en este artículo no cambió). Los problemas conocidos de redimensionamiento con UIRequiresFullScreen de la época de la beta 4 también figuran como corregidos entre los problemas resueltos. El análisis que sigue se conserva tal como se escribió, anclado a la Beta 4, porque la mecánica de los efectos secundarios de la solución sigue aplicándose dondequiera que esa solución continúe en builds ya publicados. Para el panorama más amplio en el que encaja este cambio, mira La era del iPhone redimensionable.

La versión resumida 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 versión que registra esa intención está archivada entre los problemas conocidos, porque en la Beta 4 todavía lo condicionan.¹

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

TL;DR

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 continuamente redimensionable, algo que Apple enumera como problema conocido junto a la afirmación de que las orientaciones «ya no deberían ser una condición para el redimensionamiento continuo».¹ La solución documentada consiste en declarar las cuatro. Hacerlo amplía el conjunto de orientaciones de toda tu app, y el sistema determina la rotación comparando las orientaciones de la app con las de cada view controller.² Otros cuatro problemas conocidos tienen que ver con UIRequiresFullScreen, que entrega actualizaciones de redimensionamiento continuas donde se esperan cambios discretos de UIScreen.¹ Ni UIRequiresFullScreen ni UISupportedInterfaceOrientations están obsoletos.³⁴

Lo que dicen realmente las notas de versión

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

El bloqueo en sí, archivado entre los problemas conocidos:

«En iPad, si tu app de iPad se compila con el SDK de iOS 27 y su UISupportedInterfaceOrientations no incluye las cuatro orientaciones de interfaz, la app se trata como no continuamente redimensionable. 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 un comportamiento previsto. La entrada existe como problema conocido porque el comportamiento que se envía todavía no coincide con esa intención.

Esa distinción cambia lo que te toca hacer. Si las orientaciones hubieran dejado realmente de condicionar el redimensionamiento, el consejo sería quitar las soluciones alternativas. Como todavía lo condicionan, el consejo es aplicar una y esperar que su motivo desaparezca.

Cuatro problemas conocidos alrededor de UIRequiresFullScreen:

Una app de iPad compilada con el SDK de iOS 27 que define UIRequiresFullScreen recibe actualizaciones de redimensionamiento continuas, cuando «cada redimensionamiento debería entregarse como un cambio discreto a un nuevo UIScreen con bounds actualizados». Lo mismo ocurre con una app solo para iPhone ejecutándose en iPad, y otra vez dentro de iPhone Mirroring.¹

Un cuarto 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 ni las devueltas por UIViewController.supportedInterfaceOrientations», cuando esas «deberían respetarse hasta que la persona empiece a redimensionar la ventana».¹

Uno resuelto: un problema anterior, en el que los bounds de UIScreen.main cambiaban al redimensionar bajo UIRequiresFullScreen, ahora aparece entre los problemas resueltos.¹ Era un problema conocido activo en una beta previa. Si trabajas con notas tomadas hace unas semanas, revisa ese antes de repetirlo.

Qué te aporta el redimensionamiento continuo

Antes de sopesar el costo, conviene ser preciso sobre lo que está bloqueado, porque «continuamente redimensionable» significa algo muy 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 de tu app a pantalla completa».³ O puede seguir el arrastre, recibiendo un flujo de tamaños intermedios a medida que la persona mueve el control de redimensionamiento.

La diferencia se nota en la mano de quien usa la app. Una app continuamente redimensionable recompone su diseño mientras la ventana se mueve. Una que no lo es mantiene su diseño y encaja de golpe al final, lo que se percibe como lentitud al lado de las apps del sistema que no hacen eso.

Apple lleva años estrechando el camino de la compatibilidad. UIRequiresFullScreen llegó en iOS 9 para desactivar por completo la multitarea del iPad y el redimensionamiento dinámico.³ 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 por lo que retiene, más que por lo que concede.

Así que la pregunta que responde esta solución alternativa es si tu app de iPad participa en el manejo moderno de ventanas o se queda en un modo que Apple sigue reduciendo. Eso justifica un cambio en Info.plist. No justifica un cambio sin protecciones, que es de lo que trata la siguiente sección.

El costo de la solución alternativa

La solución de Apple se enuncia en una sola frase: declarar las cuatro orientaciones de interfaz en 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, cruzados. La declaración de Info.plist es un techo, no una instrucción. Una app que se mantuvo solo en vertical listando una orientación en Info.plist y sin sobrescribir nunca nada en el nivel del view controller pierde su restricción en cuanto aplica la solución alternativa.

En una app universal, eso aterriza tanto en iPhone como en iPad. Y la propia guía de Apple desaconseja la declaración amplia ahí: sobre la orientación invertida, «lo recomendable es 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 deshabilitarla por completo para el idiom de iPhone.»² La documentación de Info.plist dice lo mismo desde el otro lado, y señala que el sistema ignora la orientación invertida «en dispositivos sin botón de inicio».⁴

Así que la instrucción honesta tiene 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 rote boca abajo en iPhone con tal de obtener un comportamiento de ventanas de iPad. El fallo no es un crash 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 la consulta cuando shouldAutorotate devuelve true.² Si sobrescribiste eso, conviene releer la interacción antes de dar por hecho que tu restricción se mantiene.

Cómo saber si te afecta

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

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

# 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 termina con código distinto de cero cuando falta una clave, y eso mismo es la respuesta para UIRequiresFullScreen: si no hay clave, nunca estuviste en modo de compatibilidad.

Encuentra los controllers que restringen la orientación por código. Son los que siguen funcionando después del cambio en Info.plist, y su ausencia es lo que vuelve peligroso ese cambio.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Un resultado vacío combinado con una declaración estrecha en Info.plist es exactamente el perfil que se rompe: la app está solo en 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 ambos idioms de dispositivo. 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 donde antes no podía, lo que implica ejecutar el build de iPhone y girar físicamente el dispositivo o el simulador después del cambio en Info.plist.

La captura de medios, el escaneo de documentos, los campos de firma, los juegos y cualquier cosa con un lienzo de proporción fija son los lugares donde una rotación inesperada sale más cara, y también donde las sobrescrituras por controller encajan con más claridad.

UIRequiresFullScreen se está vaciando por dentro, no marcando como obsoleto

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 mal.

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

Vale la pena nombrar esa combinación. Una app que define UIRequiresFullScreen en 2026 compila sin advertencias, se publica sin aviso de migración y aterriza en un modo de compatibilidad que Apple sigue estrechando. La documentación ya describe lo que ese modo significa en los sistemas modernos: en iPadOS 26 y posteriores en iPads compatibles con el modo Windowed Apps, y en iPadOS 16 o posterior en iPads compatibles con Stage Manager, el sistema «mantiene un tamaño de escena consistente para tu app, pero no presenta la escena de tu app a pantalla completa».³

La clave ya no hace lo que dice su nombre. No la han retirado, y nada en tu build te lo va a advertir.

El patrón: decide el SDK con el que compilas

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

Mismo código fuente, binario distinto, comportamiento distinto. Eso ha aparecido una y otra vez en esta versión: las imágenes de los elementos de menú dependen del SDK contra el que enlazaste, con tres comportamientos distintos a lo largo de dos generaciones de SDK. Y la denegación de acceso a contenedores entre equipos en macOS 27 parece ser el caso opuesto, una política a nivel del sistema operativo sin condición de SDK, que es justamente por lo que vale la pena comprobar la distinción en lugar de suponerla.

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

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 aplica. La solución alternativa solo es relevante si restringiste las orientaciones a propósito.

Si aplicas la solución, acompáñala con sobrescrituras por controller. El cambio en Info.plist es un techo; la restricción tiene que mudarse a supportedInterfaceOrientations en los controllers que la necesiten, según el idiom de dispositivo.

Audita UIRequiresFullScreen por separado. Hay cuatro problemas abiertos que lo involucran, y tu build no te lo señala. Pasa un grep por tus archivos Info.plist, incluidos los de cualquier target que no consideres una app de iPad, ya que uno de los problemas cubre apps solo para iPhone ejecutándose en iPad.

Espera que el bloqueo desaparezca. 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 de orientaciones ampliado 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 problemas conocidos a resueltos. 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 bloqueando el redimensionamiento continuo en la Beta 4, pese a que Apple afirma que no deberían. Trátalo como un bug con solución alternativa, no como el nuevo comportamiento. - La solución amplía el techo de orientaciones de toda tu app. Agrega sobrescrituras de supportedInterfaceOrientations por controller o tu build de iPhone empezará a rotar. - Hay cuatro problemas abiertos en los que UIRequiresFullScreen entrega actualizaciones de redimensionamiento continuas en lugar de discretas.

Para quien mantenga una app más antigua: - UIRequiresFullScreen no está obsoleta y no genera ninguna advertencia, mientras que el comportamiento que solicita se sigue estrechando. Audítala de forma explícita. - Cada problema mencionado aquí depende de compilar con el SDK de iOS 27, no del sistema operativo que ejecute la persona usuaria.

Preguntas frecuentes

¿Las orientaciones declaradas dejaron de bloquear 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 entre los problemas conocidos porque el comportamiento actual sigue condicionándose a ellas.¹

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

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

¿Esto afectará a mi build de iPhone?

Si publicas una app universal y dependes solo de Info.plist para restringir la orientación, sí. Apple recomienda deshabilitar por completo la orientación invertida 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 que aparecen aquí la involucran, así que la ausencia de una marca de obsolescencia no debe leerse como un respaldo.

¿Debería quitar la solución alternativa cuando Apple corrija el bloqueo?

Quita 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 admite de verdad. Las sobrescrituras de supportedInterfaceOrientations por controller deberían quedarse en cualquier caso, porque expresar las restricciones de orientación donde la restricción pertenece es más duradero que confiar en un techo de toda la app.

El modo de fallo que hay que evitar es el inverso: volver a estrechar 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 continuamente redimensionable ahora mismo?

Redimensiona la ventana en un iPad y observa si el diseño sigue el arrastre o encaja de golpe al final. Si lo sigue, es continuamente redimensionable. Si encaja de golpe, revisa dos cosas: si UIRequiresFullScreen está definida, 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 depende de compilar con el SDK de iOS 27.¹ Un SDK más antiguo evita estos problemas concretos y retrasa el cambio final, pero no lo impide.

Fuentes