Redimensionamento no iPad com iOS 27: a solução alternativa tem um preço

As notas de versão do iOS 27 trazem uma solução alternativa de uma linha para apps de iPad que não são continuamente redimensionáveis: declare suporte às quatro orientações de interface no seu Info.plist.¹ O que a nota deixa de fora é que o sistema cruza essa declaração global do app com as orientações suportadas por cada view controller.² Amplie o conjunto global e você o amplia em todo lugar, iPhone incluído, a menos que cada view controller restrito sobrescreva supportedInterfaceOrientations.

A versão resumida dessa mudança também está errada sobre o estado atual. A intenção da Apple é que as orientações declaradas parem de condicionar o redimensionamento contínuo. A nota de versão que registra essa intenção está listada na seção Known Issues, porque no Beta 4 elas ainda condicionam.¹

As duas metades importam. O comportamento é um bug a caminho de uma mudança deliberada, e a solução alternativa para o bug tem um efeito colateral que ninguém documenta no mesmo lugar.

Resumo

No iOS e iPadOS 27 Beta 4, um app de iPad compilado com o SDK do iOS 27 cujo UISupportedInterfaceOrientations omita qualquer uma das quatro orientações é tratado como não continuamente redimensionável — algo que a Apple lista como problema conhecido ao lado da afirmação de que as orientações “não deveriam mais ser uma condição para o redimensionamento contínuo”.¹ A solução documentada é declarar as quatro. Fazer isso amplia o conjunto de orientações de todo o app, e o sistema decide a rotação comparando as orientações globais do app com as de cada view controller.² Outros quatro problemas conhecidos envolvem o UIRequiresFullScreen entregando atualizações contínuas de redimensionamento onde o esperado seriam mudanças discretas de UIScreen.¹ Nem UIRequiresFullScreen nem UISupportedInterfaceOrientations estão obsoletos.³⁴

O que as notas de versão realmente dizem

Seis entradas da seção UIKit das notas do iOS e iPadOS 27 Beta 4 tratam disso, cinco delas em aberto.¹

A própria trava, listada em Known Issues:

“No iPad, se o seu app de iPad for compilado com o SDK do iOS 27 e seu UISupportedInterfaceOrientations não incluir todas as quatro orientações de interface, o app é tratado como não continuamente redimensionável. A partir do iOS 27, as orientações de interface suportadas não deveriam mais ser uma condição para o redimensionamento contínuo.”

Repare no tempo verbal da segunda frase. “Não deveriam mais ser uma condição” descreve o comportamento pretendido. A entrada existe como problema conhecido justamente porque o comportamento entregue ainda não corresponde à intenção.

Essa distinção muda o que você faz. Se as orientações de fato tivessem deixado de condicionar o redimensionamento, o conselho seria remover soluções alternativas. Como elas ainda condicionam, o conselho é aplicar uma — e esperar que o motivo dela desapareça.

Quatro problemas conhecidos em torno do UIRequiresFullScreen:

Um app de iPad compilado com o SDK do iOS 27 que define UIRequiresFullScreen recebe atualizações contínuas de redimensionamento, quando “cada redimensionamento deveria ser entregue como uma mudança discreta para uma nova UIScreen com bounds atualizados”. O mesmo vale para um app exclusivo de iPhone rodando no iPad, e de novo dentro do iPhone Mirroring.¹

Uma quarta entrada trata da orientação no iPhone Mirroring: um app compilado com o SDK do iOS 27 recebe uma cena que suporta todas as orientações “independentemente das orientações declaradas em UISupportedInterfaceOrientations ou retornadas por UIViewController.supportedInterfaceOrientations”, quando essas “deveriam ser respeitadas até o usuário começar a redimensionar a janela”.¹

Um resolvido: um problema anterior, em que os bounds de UIScreen.main mudavam no redimensionamento sob UIRequiresFullScreen, agora aparece em Resolved Issues.¹ Era um problema conhecido ativo num beta anterior. Se você está trabalhando com anotações feitas algumas semanas atrás, confira essa antes de repeti-la.

O que o redimensionamento contínuo traz para você

Antes de pesar o custo, vale ser preciso sobre o que está sendo travado, porque “continuamente redimensionável” carrega um significado específico.

Uma janela de iPad pode mudar de tamanho de duas formas. Ela pode saltar entre estados discretos, que é o que um app em modo de compatibilidade recebe: o sistema, nas palavras da Apple, “mantém um tamanho de cena consistente para o seu app, mas não apresenta a cena do seu app em tela cheia”.³ Ou ela pode acompanhar o arraste, recebendo um fluxo de tamanhos intermediários conforme o usuário move o controle de redimensionamento.

A diferença aparece na mão do usuário. Um app continuamente redimensionável reorganiza o layout enquanto a janela se move. Um app não continuamente redimensionável segura o layout e encaixa tudo no final, o que passa uma sensação de lentidão ao lado de apps do sistema que não fazem isso.

A Apple vem estreitando o caminho da compatibilidade há anos. O UIRequiresFullScreen chegou no iOS 9 para desativar por completo o modo multitarefa do iPad e o redimensionamento dinâmico.³ O Stage Manager no iPadOS 16 e o modo Windowed Apps no iPadOS 26 expandiram, cada um, o que uma janela pode fazer, e a documentação hoje descreve o modo de compatibilidade pelo que ele retira, não pelo que concede.

Ou seja, a pergunta que a solução alternativa responde é se o seu app de iPad participa do sistema moderno de janelas ou fica num modo que a Apple continua encolhendo. Isso vale uma mudança no Info.plist. Não vale uma mudança desprotegida — que é o assunto da próxima seção.

O preço da solução alternativa

A solução da Apple cabe numa frase: declare as quatro orientações de interface no Info.plist.¹ A consequência mora em outra página.

A documentação de UIViewController.supportedInterfaceOrientations explica como a rotação é decidida:²

“Para determinar se deve rotacionar, o sistema compara as orientações suportadas pelo view controller com as orientações suportadas pelo app — determinadas pelo arquivo Info.plist ou pelo [método] do app delegate — e com as orientações suportadas pelo dispositivo.”

Três conjuntos, cruzados. A declaração do Info.plist é um teto, não uma instrução. Um app que se manteve apenas em retrato listando uma orientação no Info.plist e nunca sobrescrevendo nada no nível de view controller perde essa restrição no instante em que aplica a solução alternativa.

Num app universal, isso cai no iPhone tanto quanto no iPad. E a própria recomendação da Apple é contra a declaração ampla ali: sobre a orientação de cabeça para baixo, “é melhor habilitá-la para o idiom [a família de dispositivos] do iPad. Dispositivos iOS sem botão de Início, como o iPhone 12, não suportam essa orientação. Você deve desabilitá-la inteiramente para o idiom do iPhone”.² A documentação do Info.plist diz o mesmo pelo outro lado, notando que o sistema ignora a orientação de cabeça para baixo “em dispositivos sem botão de Início”.⁴

Então a instrução honesta tem dois passos, não um:

<!-- 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
    }
}

Pule o segundo passo e você terá dito a um app universal para rotacionar de cabeça para baixo no iPhone só para obter um comportamento de janelas no iPad. A falha não é um crash nem um erro de compilação. É uma tela de câmera que vira enquanto alguém está usando.

Note também que os valores padrão de supportedInterfaceOrientations diferem por idiom, e o sistema só consulta essa propriedade quando shouldAutorotate retorna true.² Se você sobrescreveu isso, vale reler a interação antes de supor que sua restrição continua valendo.

Como descobrir se você é afetado

Nada disso gera erro de compilação, então a auditoria é manual. Três verificações, em ordem decrescente de quanto tempo economizam.

Veja o que o seu Info.plist realmente declara, por target. As chaves de orientação costumam ser definidas uma vez na criação do projeto e nunca mais revisitadas, e um app universal pode carregar declarações diferentes para iPhone e iPad via UISupportedInterfaceOrientations~ipad. Leia as duas.

# 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

O PlistBuddy sai com código diferente de zero quando a chave não existe, o que já é a resposta no caso do UIRequiresFullScreen: chave ausente significa que você nunca esteve em modo de compatibilidade.

Encontre os controllers que restringem orientação em código. São eles que continuam funcionando depois da mudança no Info.plist, e a ausência deles é o que torna a mudança perigosa.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Resultado vazio combinado com uma declaração restrita no Info.plist é exatamente o perfil que quebra: o app é somente retrato inteiramente por conta da property list, então ampliá-la remove a única restrição que existia.

Depois olhe o app, nos dois idioms. A falha é visual e o sinal automatizado é fraco. Um teste de UI que percorre uma tela e faz asserções sobre o conteúdo passa em qualquer orientação. O que você procura é uma view rotacionando onde antes não podia, o que significa rodar o build de iPhone e virar fisicamente o dispositivo ou o simulador depois da mudança no Info.plist.

Captura de mídia, digitalização de documentos, campos de assinatura, jogos e qualquer coisa com um canvas de proporção fixa são onde uma rotação inesperada custa mais caro — e são também onde as sobrescritas por controller mais claramente pertencem.

O UIRequiresFullScreen está sendo esvaziado, não descontinuado

Quatro dos cinco problemas em aberto envolvem o UIRequiresFullScreen.¹ A chave que tira um app do modo multitarefa do iPad agora é a condição sob a qual a entrega de redimensionamento se comporta de forma incorreta.

Ela não está obsoleta. A documentação do UIRequiresFullScreen mostra disponibilidade em iOS 9.0 e iPadOS 9.0, sem marcação de descontinuação, indisponibilidade ou beta.³ UISupportedInterfaceOrientations também não, disponível desde o iOS 3.2.⁴

Essa combinação merece ser nomeada. Um app que define UIRequiresFullScreen em 2026 compila sem aviso, é publicado sem nenhum comunicado de migração e cai num modo de compatibilidade que a Apple continua estreitando. A documentação já descreve o que esse modo significa em sistemas modernos: no iPadOS 26 e posteriores em iPads que suportam o modo Windowed Apps, e no iPadOS 16 ou posterior em iPads que suportam o Stage Manager, o sistema “mantém um tamanho de cena consistente para o seu app, mas não apresenta a cena do seu app em tela cheia”.³

A chave não faz mais o que o nome dela diz. Ela não foi aposentada, e nada no seu build vai te avisar disso.

O padrão: quem decide é o vínculo com o SDK

Toda entrada acima compartilha uma condição, e não é a versão do sistema operacional. Cada uma se aplica a apps “compilados com o SDK do iOS 27”.¹

Mesmo código-fonte, binário diferente, comportamento diferente. Isso apareceu repetidamente nesta versão: as imagens de itens de menu dependem do SDK contra o qual você fez o link, com três comportamentos distintos entre duas gerações de SDK. E a negação de acesso a contêineres entre equipes no macOS 27 parece ser o caso oposto: uma política no nível do sistema operacional, sem qualificador de SDK — que é exatamente por que vale a pena verificar a distinção em vez de presumi-la.

A consequência prática para os testes: um build contra o SDK do iOS 26 e um build contra o SDK do iOS 27 são sujeitos diferentes. Se a sua matriz de CI tem uma única versão do Xcode, ela testa apenas um deles.

O que fazer agora

Decida se você realmente precisa de redimensionamento contínuo. Se o seu app de iPad já declara as quatro orientações, nada aqui se aplica. A solução alternativa só é relevante se você restringiu orientações de propósito.

Se aplicar a solução, combine-a com sobrescritas por controller. A mudança no Info.plist é um teto; a restrição precisa migrar para supportedInterfaceOrientations nos controllers que precisam dela, condicionada ao idiom.

Audite o UIRequiresFullScreen separadamente. Quatro problemas em aberto o envolvem, e ele não é sinalizado no seu build. Faça grep nos seus arquivos Info.plist, incluindo qualquer target que você não considera um app de iPad, já que um dos problemas cobre apps exclusivos de iPhone rodando no iPad.

Espere que a trava desapareça. A Apple afirma que as orientações não deveriam mais condicionar o redimensionamento contínuo. Quando isso chegar, o motivo para declarar as quatro some, mas o conjunto ampliado de orientações continua no seu Info.plist até alguém removê-lo. Deixe um comentário explicando por que ele está ali.

Confira as notas de novo antes de agir. Uma dessas seis entradas já saiu de Known Issues para Resolved. Este post reflete o Beta 4 em 2 de agosto de 2026.

Principais conclusões

Para quem desenvolve apps de iPad: - As orientações declaradas ainda condicionam o redimensionamento contínuo no Beta 4, apesar de a Apple afirmar que não deveriam. Trate isso como um bug com solução alternativa, não como o novo comportamento. - A solução alternativa amplia o teto de orientações de todo o app. Adicione sobrescritas de supportedInterfaceOrientations por controller ou o seu build de iPhone começa a rotacionar. - Quatro problemas em aberto envolvem o UIRequiresFullScreen entregando atualizações de redimensionamento contínuas em vez de discretas.

Para quem mantém um app mais antigo: - O UIRequiresFullScreen não está obsoleto e não produz aviso nenhum, enquanto o comportamento que ele pede segue encolhendo. Audite-o explicitamente. - Todos os problemas aqui dependem de compilar com o SDK do iOS 27, não do sistema operacional que o usuário está rodando.

Perguntas frequentes

As orientações declaradas pararam de condicionar o redimensionamento contínuo?

No Beta 4, não. A Apple afirma que “a partir do iOS 27, as orientações de interface suportadas não deveriam mais ser uma condição para o redimensionamento contínuo” e registra essa afirmação na seção Known Issues, porque o comportamento atual ainda depende delas.¹

Qual é a solução alternativa, na prática?

Declarar as quatro orientações de interface em UISupportedInterfaceOrientations.¹ Combine isso com sobrescritas de supportedInterfaceOrientations nos view controllers que precisam continuar restritos, porque o sistema cruza o conjunto global do app com o de cada controller.²

Isso vai afetar o meu build de iPhone?

Se você publica um app universal e depende só do Info.plist para restringir a orientação, vai. A Apple recomenda desabilitar a orientação de cabeça para baixo inteiramente para o idiom do iPhone, e nota que o sistema a ignora em dispositivos sem botão de Início.²⁴

O UIRequiresFullScreen está obsoleto?

Não. A documentação mostra disponibilidade em iOS e iPadOS 9.0, sem marcação de descontinuação.³ Quatro dos problemas em aberto aqui o envolvem, então a ausência de um marcador de descontinuação não deve ser lida como um aval.

Devo remover a solução alternativa quando a Apple corrigir a trava?

Remova a parte de que você não precisa mais e mantenha a parte que te protege. Quando as orientações declaradas deixarem de condicionar o redimensionamento contínuo, o motivo para listar as quatro desaparece, e você pode estreitar o UISupportedInterfaceOrientations de volta ao que o seu app de fato suporta. As sobrescritas de supportedInterfaceOrientations por controller devem ficar de qualquer forma, já que expressar restrições de orientação onde a restrição pertence é mais durável do que depender de um teto global do app.

O modo de falha a evitar é o inverso: estreitar o Info.plist de volta esquecendo que as sobrescritas eram a única coisa mantendo uma tela de captura em pé.

Como sei se o meu app é continuamente redimensionável hoje?

Redimensione a janela num iPad e observe se o layout acompanha o arraste ou encaixa no final. Acompanhar significa continuamente redimensionável. Se encaixar, verifique duas coisas: se UIRequiresFullScreen está definido, o que desativa completamente o redimensionamento dinâmico, e se UISupportedInterfaceOrientations lista as quatro orientações, que é a condição descrita por este problema conhecido.¹³

Compilar contra um SDK mais antigo evita tudo isso?

Cada entrada depende de compilar com o SDK do iOS 27.¹ Um SDK mais antigo evita esses problemas específicos e adia a mudança futura, em vez de impedi-la.

Fontes