Redimensionamento do iPad no iOS 27: a solução alternativa tem um custo

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

Atualização de 24 de agosto: o bloqueio foi resolvido. As notas de versão atuais listam o problema 166422120 como corrigido – ele saiu dos problemas conhecidos entre a edição da beta 4 e a da beta 6, e a edição da beta 7 confirma: as orientações declaradas não condicionam mais o redimensionamento contínuo, em linha com a intenção declarada citada abaixo.¹ Se você publicou a solução das quatro orientações, ela não é mais necessária nas betas atuais; antes de removê-la, confira de novo os view controllers em que você adicionou sobrescritas de supportedInterfaceOrientations junto com ela, porque essas sobrescritas continuam sendo estruturais por conta própria (o comportamento de interseção descrito neste post permanece igual). Os problemas conhecidos de redimensionamento com UIRequiresFullScreen da época da beta 4 também aparecem como corrigidos entre os problemas resolvidos. A análise abaixo foi preservada como escrita, ancorada na beta 4, porque a mecânica dos efeitos colaterais da solução continua valendo em todo lugar onde ela permanece em builds já publicados. Para o panorama maior em que essa mudança se encaixa, veja A era do iPhone redimensionável.

A versão resumida dessa mudança também erra 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á arquivada em problemas conhecidos, porque na beta 4 elas ainda o condicionam.¹

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

TL;DR

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 seu app, e o sistema determina a rotação comparando as orientações do app com as de cada view controller.² Outros quatro problemas conhecidos envolvem o UIRequiresFullScreen, que entrega atualizações contínuas de redimensionamento onde se esperam 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 de UIKit nas notas do iOS e iPadOS 27 beta 4 tratam disso, e cinco delas seguem em aberto.¹

O bloqueio em si, arquivado em problemas conhecidos:

“No iPad, se o seu app de iPad for compilado com o SDK do iOS 27 e seu UISupportedInterfaceOrientations não incluir 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 porque o comportamento que está no ar ainda não corresponde à intenção.

Essa distinção muda o que você faz. Se as orientações tivessem de fato parado de condicionar o redimensionamento, o conselho seria remover as 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, em vez disso, ser entregue como uma mudança discreta para um novo UIScreen com bounds atualizados”. O mesmo vale para um app só de iPhone rodando no iPad, e de novo dentro do iPhone Mirroring.¹

Um quarto cobre o tratamento de orientações 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é que a pessoa comece a redimensionar a janela”.¹

Um resolvido: um problema anterior, em que os bounds de UIScreen.main mudavam ao redimensionar sob UIRequiresFullScreen, agora aparece em problemas resolvidos.¹ Ele era um problema conhecido ativo em uma beta anterior. Se você trabalha com anotações feitas algumas semanas atrás, confira esse antes de repeti-lo.

O que o redimensionamento contínuo traz para você

Antes de pesar o custo, vale ser preciso sobre o que está sendo bloqueado, porque “continuamente redimensionável” diz algo bem específico.

Uma janela do iPad pode mudar de tamanho de duas maneiras. Ela pode pular 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 arrasto, recebendo um fluxo de tamanhos intermediários conforme a pessoa move o controle de redimensionamento.

A diferença aparece na mão de quem usa. Um app continuamente redimensionável refaz o layout enquanto a janela se move. Um que não é continuamente redimensionável segura o layout e encaixa de uma vez no fim, o que soa lento ao lado dos 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 sair inteiramente do multitarefa do iPad e do redimensionamento dinâmico.³ O Stage Manager no iPadOS 16 e o modo Windowed Apps no iPadOS 26 ampliaram, cada um, o que uma janela pode fazer, e a documentação agora descreve o modo de compatibilidade pelo que ele retém, e não pelo que concede.

Então a pergunta que a solução alternativa responde é se o seu app de iPad participa do gerenciamento moderno de janelas ou fica num modo que a Apple segue encolhendo. Isso vale uma mudança no Info.plist. Não vale uma mudança sem proteções, que é justamente o assunto da próxima seção.

O custo da solução alternativa

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

O UIViewController.supportedInterfaceOrientations documenta como a rotação é decidida:²

“Para determinar se deve girar, o sistema compara as orientações suportadas pelo view controller com as orientações suportadas pelo app — conforme determinado 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 só em retrato listando uma orientação no Info.plist e nunca sobrescrevendo nada no nível do view controller perde sua restrição no instante em que aplica a solução alternativa.

Num app universal, isso cai tanto no iPhone quanto no iPad. E as próprias orientações da Apple pesam contra a declaração ampla ali: sobre a orientação de cabeça para baixo, “a prática recomendada é habilitá-la para o idiom 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, observando que o sistema ignora a orientação de cabeça para baixo “em dispositivos sem botão de início”.⁴

Ou seja, 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 girar de cabeça para baixo no iPhone só para obter um comportamento de janelas do iPad. A falha não é um crash nem um erro de compilação. É uma visualização de câmera que vira enquanto alguém está usando.

Vale notar também que os padrões de supportedInterfaceOrientations diferem por idiom, e que o sistema só o consulta quando shouldAutorotate retorna true.² Se você sobrescreveu isso, vale reler a interação antes de supor que a 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 tempo economizado.

Confira o que o seu Info.plist realmente declara, target por target. As chaves de orientação costumam ser definidas uma vez na criação do projeto e nunca mais revisadas, e um app universal pode carregar declarações diferentes para iPhone e iPad por meio de 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, e isso em si já é a resposta para o UIRequiresFullScreen: nenhuma chave significa que você nunca esteve em modo de compatibilidade.

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

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Um resultado vazio combinado com uma declaração estreita no Info.plist é exatamente o perfil que quebra: o app é só retrato unicamente em virtude 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 verifica seu conteúdo passa em qualquer orientação. O que você procura é uma view girando 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 os lugares onde uma rotação inesperada custa mais caro, e também são onde as sobrescritas por controller mais claramente se encaixam.

O UIRequiresFullScreen está sendo esvaziado, não descontinuado

Quatro dos cinco problemas em aberto envolvem o UIRequiresFullScreen.¹ A chave que tira um app do multitarefa do iPad é agora a condição sob a qual a entrega de redimensionamentos 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 obsolescência, indisponibilidade ou beta.³ O UISupportedInterfaceOrientations também não está, 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 nota de migração e cai num modo de compatibilidade que a Apple segue estreitando. A documentação já descreve o que esse modo significa em sistemas modernos: no iPadOS 26 e posteriores em iPads compatíveis com o modo Windowed Apps, e no iPadOS 16 ou posterior em iPads compatíveis com 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 SDK de compilação

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

Mesmo código-fonte, binário diferente, comportamento diferente. Isso apareceu repetidas vezes nesta versão: as imagens dos itens de menu dependem do SDK contra o qual você fez a linkagem, com três comportamentos distintos ao longo de duas gerações de SDK. E a negação de acesso a contêineres entre times no macOS 27 parece ser o caso oposto, uma política em nível de sistema sem qualificador de SDK, que é exatamente por isso que vale checar 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 objetos 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ê precisa mesmo 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 as 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, com base no idiom.

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

Espere que o bloqueio 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 fica 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á passou de problemas conhecidos para resolvidos. Este post reflete a beta 4 em 2 de agosto de 2026.

Pontos principais

Para quem desenvolve apps de iPad: - As orientações declaradas ainda bloqueiam o redimensionamento contínuo na 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 amplia o teto de orientações de todo o seu app. Adicione sobrescritas de supportedInterfaceOrientations por controller, ou o seu build de iPhone começa a girar. - Quatro problemas em aberto envolvem o UIRequiresFullScreen entregando atualizações contínuas de redimensionamento em vez de discretas.

Para quem mantém um app mais antigo: - O UIRequiresFullScreen não está obsoleto e não gera aviso nenhum, enquanto o comportamento que ele pede segue encolhendo. Audite-o explicitamente. - Todo problema aqui depende de compilar com o SDK do iOS 27, e não do sistema que a pessoa está usando.

Perguntas frequentes

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

Não na beta 4. 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 arquiva essa afirmação em problemas conhecidos porque o comportamento atual ainda depende delas.¹

Qual é a solução alternativa exata?

Declarar as quatro orientações de interface em UISupportedInterfaceOrientations.¹ Combine-a com sobrescritas de supportedInterfaceOrientations nos view controllers que precisam continuar restritos, porque o sistema cruza o conjunto de todo o 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, sim. A Apple recomenda desabilitar inteiramente a orientação de cabeça para baixo para o idiom do iPhone, e observa que o sistema a ignora em dispositivos sem botão de início.²⁴

O UIRequiresFullScreen está obsoleto?

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

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

Remova a parte de que você não precisa mais e mantenha a parte que te protege. Quando as orientações declaradas pararem de condicionar o redimensionamento contínuo, o motivo para listar as quatro desaparece, e você pode estreitar o UISupportedInterfaceOrientations de volta para o que o seu app realmente suporta. As sobrescritas de supportedInterfaceOrientations por controller devem ficar de qualquer jeito, já que expressar restrições de orientação onde a restrição pertence é mais durável do que depender de um teto válido para todo o 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 arrasto ou encaixa de uma vez no fim. Acompanhar significa continuamente redimensionável. Se encaixar de uma vez, verifique duas coisas: se o UIRequiresFullScreen está definido, o que tira o app inteiramente do redimensionamento dinâmico, e se o 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 final, em vez de impedi-la.

Fontes