Apple anunciou o iPhone Duo, seu primeiro iPhone dobrável, em 9 de setembro de 2026. Os pré-pedidos abrem em 16 de outubro e o aparelho chega às lojas em 23 de outubro, rodando iOS 27.1. O estranho é o timing: a Apple publicou as regras no mesmo dia, mas o SDK com o simulador do Duo só chega “mais adiante em setembro”. A documentação já existe, o hardware praticamente não — e essa é exatamente a janela para você ir atrás das suposições de layout no seu app que silenciosamente deixaram de ser verdade.
Este guia não é sobre o aparelho em si, disso vai ter review sobrando por aí. A notificação push em si é desenhada pelo sistema, então não há nada para mudar ali. Tudo que o seu app desenha por conta própria é o que agora precisa sobreviver a uma tela que muda de forma e proporção com a sessão já em andamento: mensagens in-app, rich media, o primer de permissão de push, loaders. É essa a superfície para a qual a Apple escreveu regras novas — e é exatamente a que a maioria dos times está prestes a ignorar.
No Brasil, onde o Android domina cerca de 85% do mercado mobile, é tentador tratar isso como um problema de nicho. Mas o público iOS por aqui está concentrado justamente nos segmentos que mais pagam e mais engajam — fintechs, superapps, e-commerce premium — então um app “visivelmente intocado” no iPhone Duo custa caro exatamente onde dói.
O que realmente mudou com o iOS 27 num iPhone dobrável
O iPhone Duo tem 2 telas com proporções quase idênticas. A interna tem 7.6 polegadas, cerca de 50% mais área de tela que um iPhone 18 Pro Max; a externa tem 5.4 polegadas, cerca de 90% da área de tela de um iPhone 18 Pro. As proporções são parecidas, mas não idênticas — mais um motivo para basear o layout em size classes, e não numa proporção que você assume valer para as duas telas.
Todo app participa do Split View. O Duo é o primeiro iPhone a rodar múltiplas instâncias da UI do seu app ao mesmo tempo, o que significa que sua mensagem in-app pode acabar em metade da tela, ao lado do app de outra pessoa.
E o formato muda no meio da sessão. O usuário desdobra o aparelho, ou dobra pela metade, com o seu modal ainda na tela. Layout deixa de ser algo que você decide uma vez, no lançamento.
3 níveis de compatibilidade, e onde a maioria dos apps está
A regra da Apple é direta: seu app roda no Duo sem recompilar. A pegadinha é quanto de tela ele ganha — e isso depende de qual SDK você usou para compilar.
- SDK mais antigo: roda, mas o conteúdo fica preso numa região do tamanho de um iPhone comum.
- SDK do iOS 27: sua UI se estende para a esquerda da área da status bar, na tela interna.
- SDK do iOS 27.1: sua UI chega até a borda da tela, e os botões padrão de navegação e toolbar passam a ficar dispostos na vertical.
Ou seja: um time que não faz nada lança suas mensagens in-app numa caixa do tamanho de um iPhone comum, dentro de uma tela de 7.6 polegadas. Não quebra. Só fica visivelmente intocado, ao lado de concorrentes que se deram ao trabalho de adaptar.
Por que o layout das suas mensagens in-app para de funcionar
3 motivos, e eles se somam.
Proporção de tela. A maioria dos templates de in-app e rich media foi desenhada para a proporção de um iPhone normal. As proporções da tela interna são diferentes, e templates feitos para as proporções antigas não vão encaixar onde você desenhou.
Orientação é o sinal errado. A tela interna é regular nas duas size classes e não respeita as interface orientations suportadas. Qualquer ramificação de layout baseada em orientação está lendo um sinal que a tela interna ignora. A instrução da Apple é direta: decida o layout a partir das size classes, não da orientação.
Safe area é assimétrica. Os insets e as margens de layout no Duo costumam ser diferentes em cada lado, então você trata cada borda individualmente, em vez de assumir um frame simétrico. Depois teste no Split View, onde o frame volta a ficar estreito.
A mensagem in-app que está na tela quando o aparelho abre
Esse é o caso que vale a pena pensar com calma, porque nenhum simulador deixou ninguém observar isso ainda: uma mensagem in-app modal está na tela e o usuário desdobra o aparelho. O frame muda embaixo de uma view que já está apresentada.
A Apple te dá 2 ferramentas aqui, e confundi-las é o erro mais fácil de cometer.
As hinge APIs — onHingeChange no SwiftUI e UIHingeInteraction no UIKit — reportam um estado discreto (fechado, parcialmente aberto, totalmente aberto) e um ângulo contínuo. Elas existem para serem observadas em tempo real e acionar interações e efeitos. A própria demo da Apple usa o ângulo da dobra para curvar o pitch de um instrumento virtual. É esse o registro para o qual elas servem — não mover os seus botões de lugar.
Layout passa por outra porta. A Apple aponta para as APIs de arrangement e region da talk “Strike a pose with adaptive layouts on iPhone Duo”, que introduz reserved regions, arrangement views com layouts em split e overlay, e displacement: reencaixar os elementos existentes no espaço que realmente está disponível, para que o conteúdo continue visível e alcançável enquanto o aparelho fecha. O iOS 27.1 adiciona ReservedRegion no SwiftUI e UIViewReservedRegion no UIKit, para que sua UI customizada possa reivindicar o espaço de que precisa sem colidir com a UI do sistema. Você consulta essas regiões com reservedRegions(kind:), onde .division é a própria dobra e .occlusion é a câmera.
Para um modal, isso se resume a uma regra: não use o ângulo da dobra para reposicioná-lo. Deixe que ele responda ao arrangement e à reserved region, para que, quando a tela abrir, seu conteúdo caia no lugar certo em vez de se agarrar a um frame que já não existe mais.
Notificações in-app no Split View
Como todo app agora está no pool de multitasking, suas notificações in-app podem acabar em metade da tela, ao lado do app de um desconhecido. É um frame bem mais estreito que a tela interna inteira — e é exatamente por isso que você precisa testar em meia largura. Um modal que funciona bem em tela cheia vai cortar conteúdo ou ficar apertado quando perder metade do espaço.
Também existe uma barreira rígida a considerar: você não pode abrir novas janelas na tela externa, ela é reservada para a experiência da tela interna. Qualquer lógica de apresentação que crie janelas precisa levar isso em conta.
A tela externa: seu layout compacto, mais widgets e Live Activities
A tela externa se comporta como a de qualquer outro iPhone. Seu app roda ali, e tudo que ele desenha também — mensagens in-app inclusive. A forma como a Apple enquadra isso: a tela externa tem um layout compact-width, igual a um iPhone comum, enquanto a tela interna é regular nas duas dimensões. Com 5.4 polegadas, é o frame de tela cheia mais estreito que sua mensagem in-app vai receber neste aparelho — então ela entra na sua matriz de testes, e não na pilha do “isso não se aplica”.
Tem uma segunda superfície empilhada em cima dessa. No Duo, o StandBy roda em qualquer uma das telas mesmo quando o aparelho não está carregando: você apoia o telefone e a tela externa continua acesa, virada para o ambiente. Um app sem widget e sem Live Activity simplesmente está ausente nesse momento. Presença ali vem através de um widget ou de uma Live Activity — o mesmo trabalho que você já faria para a lock screen e a Dynamic Island. Se você já construiu Live Activities, esse é o segundo lugar em que esse investimento se paga. Se ainda não construiu, aqui está mais um motivo.
Nosso texto anterior sobre iOS Live Activities cobre a base, e a regra antispam do iOS 27 explica o que você pode colocar nelas.
Um checklist de compatibilidade com o iPhone dobrável para antes de 23 de outubro
Você não tem acesso ao aparelho ainda, mas tudo o que não depende dele já está na mesa:
- Faça o inventário dos seus templates de in-app e rich media. Encontre todos os que fixam um frame, uma proporção de tela ou uma caixa do tamanho de um iPhone comum.
- Audite seus criativos em 16:9. Qualquer coisa construída para uma proporção fixa precisa de um plano para a tela interna.
- Encontre suas ramificações de orientação. Layout baseado em interface orientation está lendo um sinal que a tela interna ignora — migre isso para size classes.
- Verifique cada borda da safe area individualmente. Assuma assimetria; não assuma um inset simétrico.
- Procure por
UIScreen.mainno seu código. Num aparelho com duas telas isso é ambíguo, e a Apple já avisou que vai depreciar. Leia a tela a partir dewindow?.windowScene?.screene a escala a partir detraitCollection.displayScale. - Teste em compact width, não só desdobrado. A tela externa é onde suas mensagens in-app ganham menos espaço, e é uma superfície real para elas.
- Organize seu teste no Device Hub. Quando a beta do Xcode 27.1 for lançada, o simulador do Duo vai estar no Device Hub: abra, feche, gire e dobre pela metade com uma mensagem na tela.
- Segmente por modelo de aparelho. Garanta uma forma de segmentar usuários do Duo para testes separados assim que ele estiver disponível ao público.
- Revise o texto do seu primer de push e onboarding. O prompt de permissão que o usuário vê no onboarding continua sendo desenhado pelo sistema, mas qualquer tela customizada de pré-permissão que leva até ele herda as mesmas regras de layout das suas mensagens in-app.
Nada disso precisa do aparelho. Tudo isso precisa ser feito antes do aparelho chegar às mãos dos seus usuários, não depois.
Deixe sua mensageria pronta para o Duo
Corrigir isso manualmente em mensagens in-app, rich media e primers de push, em cada tela que seus usuários carregam no bolso, é o tipo de coisa que fica mais fácil numa única integração do que em seis. É esse o argumento para lidar com mensagens in-app e notificações push através de uma única plataforma de engajamento mobile como a Pushwoosh: comece grátis ou fale com nosso time sobre deixar sua mensageria pronta para o Duo antes de 23 de outubro.
Artigos relacionados
Ver todos