O iPhone Duo muda a rotina de teste porque um mesmo app pode aparecer na tela externa compacta, na tela interna ampla, em posições parcialmente dobradas e em layouts de multitarefa. Mas há uma limitação importante para quem está começando agora: em 17 de setembro de 2026, a Apple informa que o suporte de desenvolvimento ao iPhone Duo chegará no Xcode 27.1, com SDKs atualizados e um simulador capaz de reproduzir as novas posições e orientações, e que a beta será disponibilizada mais tarde neste mês. O aparelho chega ao mercado em 23 de outubro com iOS 27.1.
Isso divide o trabalho em duas etapas. Antes da beta, vale corrigir tudo o que já impede o app de redimensionar bem. Assim que o Xcode 27.1 com suporte ao Duo estiver disponível, entra a validação específica de dobra, áreas reservadas, multitarefa, cenas e transições entre tamanhos. A própria Apple centraliza o material de preparação em Get ready for iPhone Duo e detalha a disponibilidade do Xcode na atualização de 16 de setembro de 2026.
O que o Xcode 27.1 acrescenta ao teste do iPhone Duo
Segundo a Apple, o Xcode 27.1 adicionará os SDKs e o simulador necessários para executar e testar apps para o iPhone Duo. O ponto mais importante não é apenas ter um novo tamanho de tela. O simulador precisa representar poses e orientações diferentes, porque o sistema reorganiza barras, áreas seguras, conteúdo e possibilidades de multitarefa conforme o aparelho está fechado, aberto ou parcialmente dobrado.
Na prática, o simulador deve entrar como parte de uma matriz de testes, não como uma captura única de layout. A Apple recomenda tratar a interface como redimensionável e adaptativa. No vídeo Design for iPhone Duo, a orientação é evitar larguras fixas, breakpoints ligados a uma resolução específica e layouts separados para cada pose. O foco deve estar em duas classes de tamanho principais: largura compacta na tela externa e largura regular na tela interna.
O que já dá para revisar antes da beta do Xcode 27.1
O melhor uso do tempo antes do simulador específico é eliminar dependências de dimensões rígidas. Um app que já responde bem a redimensionamento no iPad, no iPhone Mirroring e em janelas variáveis parte de uma base melhor para o Duo.
- Remova larguras e alturas fixas quando não forem essenciais. Componentes devem reagir ao espaço disponível, e não a um modelo de aparelho codificado no layout.
- Revise classes de tamanho. Em SwiftUI, UserInterfaceSizeClass e os valores de ambiente de largura e altura ajudam a tomar decisões com base no espaço disponível. Em UIKit, o equivalente passa por traits e size classes.
- Prefira navegação padrão. A Apple destaca que componentes como NavigationSplitView, UISplitViewController, TabView e UITabBarController se adaptam entre poses e tamanhos.
- Teste conteúdo em espaço estreito e largo. Uma tela que funciona apenas no modo aberto ainda não está pronta. O mesmo fluxo precisa continuar compreensível quando a largura cair para a classe compacta.
- Evite posicionar controles com coordenadas absolutas. Barras, botões e elementos interativos precisam acompanhar margens, safe areas e mudanças de eixo.
Matriz de testes para executar quando o simulador do Duo chegar
| Cenário | O que observar | Falhas típicas a procurar |
|---|---|---|
| Tela externa, aparelho fechado | Classe compacta, navegação, barras verticais, câmera e safe area | Conteúdo escondido, controles cortados, texto comprimido, barras sobrepostas |
| Tela interna totalmente aberta | Classe regular, uso do espaço extra, duas colunas ou sidebar quando fizer sentido | Conteúdo excessivamente esticado, vazios grandes, hierarquia visual perdida |
| Parcialmente dobrado em formato de livro | Região central da dobra, deslocamento de conteúdo e controles | Botões no vinco, texto ou imagens difíceis de ler no centro, gestos atravessando a dobra |
| Parcialmente dobrado em orientação retrato | Distribuição vertical, alcance dos controles e adaptação ao espaço útil | Ações importantes na metade menos acessível, elementos sobre a área de dobra |
| Split View lado a lado | Redimensionamento contínuo, classes de tamanho, geometria da cena | Layout que depende de largura mínima rígida, modais ou menus fora da área disponível |
| Vídeo fixado com app redimensionado | Mudança de altura em tempo real | Conteúdo cortado, rolagem quebrada, controles fora da tela |
| Rotação e mudança de pose | Refluxo do layout sem perder contexto | Reset de navegação, flashes de layout, estado visual incoerente |
| Múltiplas cenas | Criação e restauração de janelas onde forem permitidas | Erros não tratados, estado compartilhado incorretamente, ações disponíveis no display errado |
Dobra não deve virar um breakpoint manual
Um dos pontos mais fáceis de errar é transformar o ângulo da dobradiça em regra de layout. A Apple diferencia duas necessidades. Para efeitos e interações, SwiftUI oferece o modificador onHingeChange e UIKit oferece UIHingeInteraction, que informam estado e ângulo da dobradiça. Para layout, porém, a recomendação é usar as APIs de regiões e arranjos, não o ângulo bruto da dobradiça. Essa distinção aparece em Leverage multiple displays and scenes on iPhone Duo.
Isso evita criar dezenas de condições como “se o aparelho estiver em 70 graus, mova o botão”. O layout deve responder ao espaço utilizável e às regiões fornecidas pelo sistema. O ângulo pode servir para uma animação, um efeito de jogo ou outra interação contínua, mas não deve substituir a geometria de interface.
Safe areas e ReservedRegion: onde a dobra realmente entra no layout
A tela do Duo contém áreas que nem sempre devem receber conteúdo interativo. A Apple chama essas áreas de reserved regions. Elas incluem a região de divisão criada pela dobra quando o aparelho está parcialmente aberto e regiões de oclusão, como a câmera. No material Strike a pose with adaptive layouts on iPhone Duo, a Apple explica que a região da dobra fica ativa quando o aparelho está parcialmente fechado. Quando o dispositivo está totalmente plano, essa região fica inativa e sua largura é zero.
Para interfaces comuns, o caminho mais seguro continua sendo usar componentes e barras do sistema, que já respeitam safe areas e evitam a dobra. Para UIs personalizadas e edge to edge, o iOS 27.1 introduz ReservedRegion no SwiftUI e UIViewReservedRegion no UIKit. Elas permitem consultar regiões que dividem ou obstruem a área de conteúdo e posicionar elementos sem colidir com hardware ou interface do sistema.
Também é importante não presumir margens simétricas. A Apple pede que desenvolvedores testem safe areas e layout margins de cada lado, inclusive em Split View. Fundos e imagens decorativas podem ultrapassar a safe area quando isso for intencional, mas texto, botões e outros elementos interativos devem permanecer em regiões legíveis e tocáveis.
Breakpoints: use o espaço disponível, não o nome do dispositivo
Para o Duo, a regra prática é simples: não crie um caminho “iPhone Duo” separado se o mesmo resultado puder ser obtido por adaptação ao tamanho disponível. A tela externa é um caso compacto. A interna é um caso regular. Dentro dessas duas famílias, o app ainda pode perder largura ou altura por multitarefa, vídeo fixado, barras e mudança de orientação.
Um layout robusto deve responder a essas mudanças sem depender de uma lista de resoluções. Em uma tela de catálogo, por exemplo, a interface pode passar de uma coluna para duas quando houver espaço. Em um app com muita hierarquia, uma sidebar pode fazer sentido na tela interna. Já uma tela simples pode continuar com uma única coluna, apenas usando melhor as margens e o espaço extra. O critério deve ser a clareza da interface, não o fato de o aparelho estar aberto.
Estado do app: redimensionar não pode significar recomeçar
A Apple enfatiza que o iPhone Duo suporta multitarefa e múltiplas instâncias de interface. Ele é o primeiro iPhone em que um app pode ter várias cenas de UI, comportamento já conhecido no iPad. Há, porém, uma diferença importante: novas janelas podem ser criadas na tela interna, mas não na tela externa. A Apple recomenda tratar falhas ao solicitar novas cenas e indica UIWindowSceneActivationAction, que se oculta automaticamente quando a criação de novas janelas não está disponível.
Além do requisito oficial de cenas, vale incluir testes de continuidade de estado no checklist do produto. Ao alternar entre tela externa e interna, mudar orientação, entrar em Split View ou alterar a pose, verifique se o app preserva o que o usuário estava fazendo. Isso inclui navegação, texto ainda não enviado, seleção atual, reprodução de mídia, filtros e outras informações de contexto relevantes. Esse é um teste de qualidade do app, não uma promessa automática do sistema.
- Abra uma tela profunda, mude a pose e confirme que a navegação continua no mesmo ponto.
- Digite conteúdo em um formulário, redimensione a janela e verifique se nada é perdido.
- Inicie mídia ou uma tarefa longa e teste mudanças de tamanho e orientação.
- Abra uma segunda cena na tela interna, quando permitido, e confirme que cada janela mantém o estado correto.
- Tente solicitar uma nova cena em um contexto onde ela não está disponível e confirme que o app lida com isso sem erro visível.
O que ainda depende da beta e da documentação final
Em 17 de setembro, ainda não é possível fechar todos os detalhes do fluxo de testes porque a Apple não disponibilizou publicamente a beta do Xcode 27.1 com suporte ao iPhone Duo. Até essa versão chegar, ficam pendentes de confirmação prática os presets exatos do simulador, os controles usados para alternar poses e orientações, possíveis known issues do SDK e eventuais mudanças nas APIs antes do lançamento.
Por isso, não convém transformar vídeos de apresentação em contrato definitivo de implementação. Use os princípios já publicados para corrigir resizabilidade, navegação e safe areas. Depois, valide o comportamento no simulador do Xcode 27.1, releia as release notes correspondentes e faça uma rodada final em hardware real assim que houver acesso. O simulador é ideal para geometria, layout e muitos fluxos de estado, mas não substitui completamente a validação física de ergonomia, câmeras, dobra e desempenho.
Checklist de adaptação antes do lançamento
- Remover dimensões rígidas que impeçam redimensionamento.
- Revisar layouts nas classes compacta e regular.
- Adotar componentes de navegação e barras adaptativos sempre que possível.
- Garantir que conteúdo interativo respeite safe areas assimétricas.
- Planejar uso de ReservedRegion ou UIViewReservedRegion apenas onde a UI personalizada exigir.
- Não usar o ângulo da dobradiça como substituto das APIs de layout.
- Testar tela externa, tela interna, poses parcialmente dobradas, rotação e mudanças de altura.
- Testar Split View e redimensionamento com vídeo fixado.
- Validar preservação de estado durante redimensionamentos e transições.
- Revisar suporte a múltiplas cenas e tratar indisponibilidade de novas janelas.
- Executar a matriz novamente quando a beta do Xcode 27.1 com simulador do Duo for publicada.
- Repetir os testes após as release notes finais e, quando possível, em um iPhone Duo físico.
Em resumo
Preparar um app para o iPhone Duo não significa criar uma interface diferente para cada ângulo de dobra. O trabalho principal é tornar a UI realmente redimensionável, respeitar classes de tamanho, safe areas e regiões reservadas, e preservar o contexto do usuário enquanto a geometria muda. Em 17 de setembro de 2026, essa preparação já pode começar, mas a validação específica no simulador depende da beta do Xcode 27.1 que a Apple prometeu para mais tarde neste mês. A melhor estratégia é chegar a essa beta com os problemas de resizabilidade já resolvidos e usar o simulador para testar o que só o novo hardware introduz.
