Projetando para o iPhone Duo: o que se move, o que se divide e o que fica

O que projetar para o iPhone Duo exige? Dois layouts, e não um layout por posição: “Um layout em compact width para a tela externa e um layout em regular width para a tela interna dão a você os fundamentos para todas as posições”, e o próprio conselho da Apple é “projetar seu app para que ele mude de tamanho livremente”. (4:32)¹² Sobre essa base se apoiam quatro padrões descritos pelo guia e pelos três Tech Talks que o acompanham: os controles migram para a lateral da tela e mantêm uma ordem de cima para baixo; o conteúdo se afasta desses controles, a menos que ocupe toda a largura de propósito; os elementos interativos se deslocam para longe da dobra, enquanto o conteúdo com rolagem não; e um novo container, o arrangement, divide ou sobrepõe duas views seguindo regras. Os Tech Talks descrevem as APIs por trás dos dois últimos pontos, e os arrangements chegam com o iOS 27.1.³

A Apple publicou Designing for iPhone Duo nas Human Interface Guidelines na tarde do keynote, junto com três Tech Talks voltados ao design: “Design for iPhone Duo”, “Strike a pose with adaptive layouts on iPhone Duo” e “Raise the bar with iPhone Duo”.¹²³⁴ O texto para desenvolvedores deste site trabalha a aritmética dos pontos e as regras do SDK. Este aqui trata das decisões de design que o guia pede, citadas com as palavras da própria Apple e com o marcador de tempo em cada Tech Talk, além do que pretendo fazer com elas nos meus próprios apps.

TL;DR: Projete para duas classes de tamanho e deixe o sistema cuidar das posições. As barras ficam verticais na lateral da tela externa e na tela interna em paisagem; só a tela interna em retrato mantém barras horizontais.⁴ Itens com ícone vão para a vertical, itens só de texto continuam horizontais, e o topo da barra vertical é para Back ou Close, seguidos de uma ação de destaque como Done.⁴ O conteúdo se afasta da barra por meio da área segura horizontal, a menos que seja imersivo e não role.² Na dobra, na posição de livro, “elementos como alertas migram para o lado trailing” (4:09) e, sobre uma mesa, os controles interativos descem para a metade inferior, enquanto “conteúdo de rolagem contínua, como artigos, feeds, documentos e listas, não se desloca” (3:46).³ Os arrangements são o novo container de layout, no formato split ou overlay, e a regra da Apple para escolher é a que você já usa: uma pilha horizontal ou vertical vira um split, e um ZStack vira um overlay.³

Uma regra antes dos padrões

Dois dos Tech Talks e o guia repetem a mesma frase, e é dela que se deve partir para projetar. Vince, do time de design da Apple: “As pessoas vão usar o iPhone Duo em muitas posições diferentes, e você vai querer que seu app fique ótimo em todas elas. Mas isso não significa projetar um layout sob medida para cada posição. Em vez disso, foque em duas classes de tamanho: compact width na tela externa e regular width na tela interna. Evite larguras fixas, breakpoints ou qualquer medida presa a uma tela específica” (3:50).² O guia diz a mesma coisa na seção sobre as posições.¹ Vince acrescenta um layout opcional, para o aparelho apoiado numa mesa como um laptop, em que “a mídia pode ficar no topo, enquanto os controles tocáveis ficam sobre uma base estável embaixo” (4:48), desde que ele “tenha exatamente os mesmos controles e a mesma hierarquia geral das outras posições” (4:57).²

Quadro da transmissão do evento da Apple de 9 de setembro de 2026, 11h05 no horário do Pacífico: a posição em pé. A lista do guia é “parcialmente dobrado como um livro, apoiado sobre uma superfície ou em pé sobre as bordas”.

Tudo o que vem a seguir pressupõe essa base, a mesma que a lista de verificação do iPhone redimensionável audita e que o texto sobre redimensionamento no iPad explica. Se um layout é construído a partir de classes de tamanho, margens de layout e insets de área segura, a promessa de Vince é que “seu app já deve se adaptar ao iPhone Duo” (4:27).²

A lateral: o que se muda para lá e o que fica

Na tela externa, os controles que ficavam no topo e embaixo “migram para o lado direito da tela, para maximizar o espaço vertical e ficarem mais fáceis de alcançar com o polegar direito” (1:18).² A lateral acomoda a barra de abas, as barras de ferramentas, controles de navegação como Back, a barra de status e a Dynamic Island, “que se expande verticalmente conforme as Live Activities chegam” (1:48).² Na tela interna, as barras continuam verticais em paisagem e voltam a ser horizontais em retrato, “a única posição em que mantivemos barras horizontais” (5:27), porque “há bastante espaço vertical para o conteúdo do app” (5:32).² No Split View, “quando um app está do lado esquerdo, os controles também migram para a borda esquerda da tela” (3:11).² E a barra é alinhada ao hardware, então “ela permanece no mesmo lado do aparelho em idiomas escritos da direita para a esquerda” (4:21).⁴

Quadro da transmissão do evento da Apple de 9 de setembro de 2026, 10h59 no horário do Pacífico: o aparelho meio dobrado, com a tela interna voltada para a frente e os controles laterais em sua borda direita.

Duas coisas decidem se um determinado controle vai para a vertical. A primeira é o container dele. Anna, do time de UI Frameworks: “garanta que você está usando as barras fornecidas por containers de navegação como TabView ou NavigationStack” (2:19), porque conteúdo vindo de instâncias personalizadas de UIToolbar, UINavigationBar ou UITabBar “não será considerado” (2:58).⁴ Em split views, “só a coluna de detalhe participa” (3:43), e inspetores “não recebem uma própria” (3:53).⁴ A segunda é o conteúdo do item. Barras verticais têm “altura de item flexível e largura fixa” (6:10), o que “as torna mais adequadas a representações de item compostas apenas por símbolo” (6:13).⁴ Por isso, “itens com ícone, como os botões back e share, mudam de eixo para a vertical. E itens só de texto, como o botão edit, continuam no eixo horizontal” (7:06).⁴ A versão de Vince é a do designer: “Itens de barra de ferramentas largos demais para o espaço da direita, como um botão de texto ou um controle segmentado, devem permanecer na barra de navegação no iPhone Duo” (6:22).²

A regra de ordenação é curta. “Reserve o topo para os controles de navegação principais, como back ou close, seguidos das ações de destaque, como done” (4:47).⁴ No SwiftUI, um Back ou Close personalizado usa o posicionamento cancellationAction (5:02) e uma ação de destaque usa topBarPinnedTrailing (5:24); no UIKit, é um item leading com leftItemSupplementsBackButton deixado no padrão false (5:06), e pinnedTrailingGroup para a ação de destaque (5:27).⁴ Todo o resto mantém o agrupamento original, com “um espaçador vertical separando visualmente os posicionamentos de cima e de baixo” (5:34).⁴

As regras do Tech Talk sobre barras para itens individuais, cada uma com a sua deixa:⁴

• O teste para um item personalizado: “ele apenas reforça o símbolo ou carrega uma informação autônoma?” (9:36)
• Uma contagem pertence a um badge, o que transforma um item de texto e símbolo em um item só de símbolo, que “se sente em casa numa barra vertical” (9:23); já “um botão de carrinho exibindo um valor em dinheiro” continua horizontal (9:52).
• Um item que alterna entre símbolo e texto, como Edit, continua horizontal; o botão Edit do sistema já faz isso, e um personalizado adota o AxisBehavior exclusivamente horizontal (8:11, 8:32).
• Uma view personalizada ou complexa fica horizontal por padrão (8:40); se ela “de fato oferecer suporte a uma representação vertical” (8:48), o axis behavior com preferência pela vertical a coloca na barra (8:54).
• Dê um título a todo item, mesmo quando ele exibe um símbolo, porque “o sistema o usa sempre que um item vai para um menu de overflow ou para uma forma expandida” (7:44).
• Barras de acessórios de teclado “devem continuar presas ao teclado em vez de migrar para o eixo vertical” (10:00).
• Views personalizadas leem a propriedade de ambiente toolbarVerticalEdge, ou o trait equivalente no UIKit, para saber se há uma barra vertical presente (10:35).

O overflow é onde as preferências de design se expressam, e o Tech Talk apresenta cinco regras:⁴

• “Por padrão, os itens vão para o overflow de baixo para cima” (13:23); cada item pode carregar uma prioridade de visibilidade alta, baixa ou personalizada, atribuída primeiro “por grupos” (13:36) e depois dentro de um grupo. As APIs de prioridade e overflow são as adições de barra de ferramentas da WWDC26, tratadas no texto deste site sobre o SwiftUI no iOS 27; em 13:49, o Tech Talk encaminha você para a sessão da WWDC26 da Apple sobre as novidades do SwiftUI.
• Decida o que comprime primeiro: em views voltadas à navegação, “a barra de ferramentas comprime primeiro, para que os destinos principais continuem acessíveis” (12:07), que é o padrão; em views orientadas a tarefas, “a barra de abas comprime primeiro, para preservar as ações usadas com frequência” (12:18), o que se define com toolbarCompressionBehavior (12:22).
• Junte o menu de overflow do próprio app ao do sistema, com ToolbarOverflowMenu no SwiftUI ou additionalOverflowItems no UIKit (12:36, 12:43), e reserve as reticências apenas para o overflow (12:53).
• “Ações usadas com frequência, como Compose no Mail ou New Note no Notes, devem estar entre as últimas a ir para o overflow” (13:59).
• Itens com badge “devem permanecer visíveis por mais tempo, para preservar a leitura de relance” (14:11).

Barras verticais não são obrigatórias. Um layout de página única com peso na parte de baixo, como o Calculator, ou uma folha com um único item de barra de ferramentas, como Close, podem desligar a barra com toolbarVerticalBehavior ou preferredVerticalBarBehavior (14:28, 14:37, 14:47).⁴

Centralizado ou deslocado para o lado

Com a barra em um dos lados, “muitas camadas agora estão assimétricas” (6:33).² Vince apresenta três posições. A maior parte do conteúdo se afasta para não ficar escondida atrás dos controles, e “se o seu app se alinha aos insets horizontais da área segura, esse afastamento acontece automaticamente” (6:58).² Parte da interface continua centralizada na tela inteira, sem afastamento, o que “funciona bem em interfaces imersivas e muito visuais que não rolam, desde que você tenha certeza de que os elementos interativos não serão bloqueados pelos controles da direita” (7:10).² E os dois se misturam: “uma imagem de fundo ou um cabeçalho de largura total com conteúdo em primeiro plano rolável e recuado” (7:22), contanto que “todo elemento interativo viva dentro dessa área rolável, para que nada fique coberto” (7:28).² A observação do guia sobre a área segura acrescenta o caso do Split View: a borda oposta pode carregar os controles do outro app, então a área segura importa nas duas bordas.¹

A dobra: o deslocamento

Quadro da transmissão do evento da Apple de 9 de setembro de 2026, 11h08 no horário do Pacífico: as camadas da tela. Parcialmente dobrada, a curva que atravessa o centro é a “folding region” do guia.

Maria, Human Interface Designer no sistema de design da Apple, abre com o princípio: “Um ótimo design para o iPhone Duo depende de saber quando adaptar” (2:25).³ Muitas interfaces “conseguem fluir naturalmente ao redor das reserved regions” (2:30), e o restante recorre ao deslocamento, “que ajusta o frame dos elementos existentes com base no espaço disponível, mantendo o conteúdo importante visível, alcançável e desobstruído mesmo quando o aparelho está parcialmente dobrado” (2:39).³ O padrão tem um alcance, “de um botão a um container inteiro ou a partes maiores de um layout” (3:03), com duas regras: “Se um elemento consegue se adaptar de forma independente, mova-o sozinho. E quando elementos funcionam juntos, mova-os juntos para preservar a relação entre eles” (3:17), e “atenção ao movimento excessivo” (3:26), porque “afastar um elemento demais da sua origem enfraquece a relação visual entre eles” (3:29).³ O exemplo dela é um menu de contexto sobre uma foto selecionada: em vez de centralizar o menu na região trailing, “os dois elementos se movem juntos e se alinham ao redor da dobra” (3:39).³

A exceção é aquela em que os designers mais vão se apoiar: “Conteúdo de rolagem contínua, como artigos, feeds, documentos e listas, não se desloca. Essas experiências já se adaptam por meio da rolagem, então movê-las entre as regiões disponíveis pode interromper a continuidade” (3:46).³ Vince diz o mesmo pelo outro lado: o sistema empurra os elementos interativos para fora da curva porque “os botões ficam difíceis de tocar quando caem bem na dobra” (9:28); o comportamento vem embutido em “folhas, alertas, menus, botões de barra de ferramentas e mais” (9:40), e “conteúdo rolável não precisa evitar essa região” (9:57).²

A orientação da dobra define as regiões: na posição de livro ela corre na vertical e as regiões são esquerda e direita; sobre uma mesa, ou em retrato, ela corre na horizontal e as regiões são superior e inferior.²³ Para onde vai um elemento deslocado depende da posição, e as razões dadas por Maria são a parte útil. Na posição de livro, “elementos como alertas migram para o lado trailing. Isso os mantém mais perto de onde vão aparecer quando o aparelho se fechar e a experiência continuar na tela externa” (4:09).³ Apoiado numa mesa, “a região superior funciona bem para conteúdo que se beneficia de ser visto à distância” (4:29), e “a região inferior funciona bem para controles interativos” (4:39), onde “elementos tocáveis, como os controles de mídia, podem migrar para cá, oferecendo uma superfície mais estável para o toque” (4:43).³ O Tech Talk sobre princípios concorda: em retrato e parcialmente dobrado, “os elementos interativos migram para a metade inferior da tela, ficando mais fáceis de alcançar e mantendo o aparelho estável sobre a superfície” (2:33).² Quando várias regiões serviriam, mantenha o critério contextual: um campo de busca “aproveita o espaço extra” (5:00) com o aparelho aberto e, conforme ele dobra, sua “largura e posição se adaptam para continuar sobre a view que está sendo pesquisada” (5:04).³

O sistema faz a maior parte disso. “Action sheets, alertas, menus e popovers são todos experiências contextuais leves que podem aparecer sobre uma reserved region” (5:23), e ele “reposiciona automaticamente os componentes ao redor da reserved region” (5:34).³ Um split view “mantém as duas colunas visíveis ajustando a largura delas e posicionando-as em uma divisão igual de 50/50” (5:40).³ A grade é o caso que fica por sua conta: no design do Fitness feito por Maria, “consigo preservar as margens externas enquanto aumento o espaçamento em torno da dobradiça, mantendo cada container dentro da sua região” (5:56).³ O resumo dela para todos os exemplos serve de briefing de design: “estamos movendo, redimensionando ou reorganizando o que já está ali. Mantenha conteúdo, funcionalidades e layouts disponíveis para que as pessoas acessem a experiência completa, independentemente de como estejam usando o iPhone Duo” (6:04).³

Reserved regions, a engrenagem por trás do deslocamento

Maria apresenta o termo no Tech Talk sobre layouts adaptativos: “Novos recursos de hardware também têm papel na definição do espaço disponível. Entre eles estão a dobradiça e as duas câmeras distribuídas entre a tela externa e a interna. Chamamos isso de reserved regions” (0:37), e recomenda tratá-las “exatamente como qualquer outra área à qual seu layout já se adapta” (0:53), tendo como exemplo os controles de janela do iPadOS.³ São três: a câmera externa, a câmera interna enquanto está ativa e a dobra (1:00, 1:18, 1:32).³ O texto para desenvolvedores traz as definições do guia para cada uma delas e registra minha checagem de que o guia não vincula nenhuma documentação para essas APIs, então esta seção fica na engrenagem.¹ Harry, engenheiro de UI Frameworks, descreve a API. “No SwiftUI, você consulta as reserved regions usando um GeometryProxy obtido de um GeometryReader ou do modificador onGeometryChange. Use o novo método reservedRegion no geometry proxy para obter as regiões disponíveis na sua view.” (6:38) No UIKit, “você vai usar o método reservedRegion disponível em UIView” (7:03), e “pode consultar a propriedade frame de uma reserved region para incorporá-la ao seu próprio layout” (7:07).³

Existem dois tipos. A dobra “é sustentada por uma division reserved region, porque divide uma área maior em várias áreas menores” (6:55), e “só fica ativa quando alguém dobrou o aparelho. Quando ele está plano, ela fica inativa e tem largura zero” (7:26).³ A câmera é uma occlusion region: essas “não dividem áreas, elas as ocluem” (7:54), e a região “fica ativa quando a câmera está ativa e inativa quando a câmera está inativa” (8:12).³ Regiões inativas podem ser consultadas com a opção includeInactive, e o motivo de Harry para olhar para elas é uma decisão de design: “em layouts de grade, você pode preferir um número par de colunas quando há uma division region presente, independentemente do estado de atividade dela” (7:41).³ O guia repete isso como regra.¹ Às 16h15 no horário do Pacífico no dia do keynote, o guia não vinculava nenhuma página de documentação para essas APIs, e a página de desenvolvedores da Apple data o beta do Xcode 27.1 como “ainda neste mês”.¹⁵

Arrangements: split ou overlay

Quadro da transmissão do evento da Apple de 9 de setembro de 2026, 11h00 no horário do Pacífico: a tela interna que a Apple diz ser 80 por cento maior, a superfície para a qual os arrangements existem.

A definição de Harry: “Entre esses containers de navegação e de conteúdo fica um container de layout. Esses containers de layout organizam duas views segundo um conjunto de regras. Eles se chamam arrangements” (9:20).³ As regras recebem entradas, “a classe de tamanho horizontal e vertical da view, a proporção entre a largura e a altura da view e se existem division regions ativas” (10:37), e produzem saídas: “se eu devo mostrar a view, para começar” (10:52) e, em caso afirmativo, “qual é o frame dela” (10:54).³ Depois, a data: “no iOS 27.1, você pode usar arrangements fornecidos pelo sistema nos seus próprios apps” (11:02).³

No SwiftUI, uma ArrangementView recebe uma view primária e uma secundária (11:25) e um estilo definido com arrangementViewStyle (11:57); no UIKit, um UIArrangementViewController recebe view controllers primário e secundário (11:39).³ O estilo split, que é o padrão, “divide horizontalmente quando a view é mais larga do que alta” (12:13) e verticalmente quando é mais alta, e pode ser restrito a um único eixo; se não conseguir dividir no eixo principal, ele “opta por mostrar apenas uma view” (12:49).³ O estilo overlay “prefere posicionar o conteúdo acima ou abaixo um do outro” (13:31) e, quando o aparelho dobra, ele “prefere posicionar as views primária e secundária lado a lado” (13:51), algo que uma view consegue detectar pela propriedade de ambiente overlayArrangementZIndex para alternar entre uma forma recolhida e uma expandida (14:01).³

Escolher entre os dois é o conselho mais claro do Tech Talk, e o guia o adota. “Se você já implementa um layout parecido com split em partes do seu app usando componentes como um HStack ou VStack, considere usar o split arrangement. Se você já implementa um layout parecido com overlay em partes do seu app usando componentes como um ZStack, considere usar o overlay arrangement” (14:44).³ Sem um padrão já existente, use um overlay “quando há uma relação clara de primeiro plano e plano de fundo entre suas views” (15:10), como controles sobre conteúdo legível no Accessibility Reader, e um split “quando é mais uma relação de principal e detalhe” (15:32), como um podcast e sua transcrição, em que “é importante que nenhum dos dois seja obscurecido em momento algum” (15:43).³ Os dois limites — containers de navegação em volta de um arrangement, e não dentro dele, e nenhum arrangement dentro de uma List ou ScrollView — estão em 16:15 e 16:26 do Tech Talk; o guia enuncia apenas o primeiro, na frase que o texto para desenvolvedores cita.¹³

A tela interna: três layouts honestos

“Você não quer só um app de iPhone esticado” (7:39).² Vince oferece três formatos. Um split view, que traz à tona “vários níveis da hierarquia do seu app ao mesmo tempo” (7:46), com a condição de que a hierarquia “não mude entre a tela externa e a interna” (7:51), porque as pessoas “podem abrir e fechar o aparelho com frequência enquanto usam seu app, então ele precisa ser previsível e consistente por dentro e por fora” (7:59).² Um refluxo, seguindo o Music, em que “um layout empilhado verticalmente” (8:15) vira “um layout de duas colunas quando há mais espaço horizontal” (8:18).² Ou uma barra de abas apresentada “como uma barra lateral na tela interna” (8:26), o que “funciona melhor para apps densos em informação, como neste exemplo do Health” (8:33).² O exemplo do Mail no guia é o caso do split view: uma lista ou uma mensagem quando fechado, as duas lado a lado quando aberto.¹

As folhas têm regras próprias. Na tela externa, “os controles da folha também migram para a lateral” (8:46), o que você pode desligar em uma folha com um único botão de barra de ferramentas; nesse caso, “as folhas param um pouco antes da câmera frontal e a barra de status se reposiciona sozinha” (9:04).² Na tela interna, as folhas “usam barras horizontais padrão” (9:13) por padrão e, quando o aparelho está parcialmente dobrado, elas “deslizam para o lado para não ficar sobre a dobra” (9:20).² O Tech Talk sobre barras acrescenta a exceção de posicionamento: as folhas da tela interna ficam “centralizadas por padrão, e os itens continuam horizontais” (4:03), mas com a API preferredPlacement, “folhas posicionadas à esquerda permanecem sem barra vertical, enquanto folhas posicionadas à direita recebem uma” (4:11).⁴

A auditoria

O Tech Talk sobre barras e o de layouts adaptativos terminam cada um com uma lista de auditoria, então aqui vão as duas reunidas. A lista final do Tech Talk sobre barras (15:10): compilar com os SDKs mais recentes, porque as barras verticais são um opt-in por SDK (2:06); auditar as barras e a ordem delas (4:41) e atualizar itens personalizados para que consigam se dispor verticalmente; e atribuir prioridades de visibilidade “para que o sistema consiga se adaptar” (15:26).⁴ Depois, do Tech Talk sobre layouts adaptativos (16:40): “comece auditando os layouts centralizados do seu app. Avalie se dá para transformá-lo em um layout de duas colunas, ou qual padrão de deslocamento faz sentido naquele caso de uso”; usar containers e apresentações padrão para ganhar o comportamento de graça (16:49); recorrer a ArrangementView para layouts split ou overlay personalizados; e “identificar nas suas views os controles dispostos manualmente com maior prioridade e considerar adotar a API ReservedRegions para implementar seu próprio deslocamento onde for necessário” (17:06).³

O que pretendo fazer com isso

Três dos meus apps são apps de iPhone, e o guia os separa com clareza. Essa separação é a minha leitura, não a da Apple.

• Get Bananas é uma lista. Listas não se deslocam, a barra de abas e a barra de ferramentas migram sozinhas para a lateral se eu continuar usando os containers do sistema, e a única decisão de design é a prioridade de visibilidade: a ação de adicionar item é o meu Compose, então ela deve ser a última a ir para o overflow.
• Reps registra cada série como uma linha com carga, repetições e uma ação de registro, em uma grade durante o treino, que é exatamente o exemplo do Fitness citado por Maria. A decisão: na posição de livro, uma linha de três colunas coloca a coluna do meio sobre a dobradiça, então a grade passa a duas colunas pareadas. Na posição de mesa, a ação de registro fica na metade inferior. O custo-benefício é um toque a mais por série em troca de um alvo que nunca cai na dobra, onde, segundo Vince, “os botões ficam difíceis de tocar” (9:28).² O cronômetro de descanso continua no topo, a região que, segundo Maria, funciona bem para “conteúdo que se beneficia de ser visto à distância” (4:29).³
• Return desenha gráficos de saúde, que são conteúdo com rolagem. Onde hoje um gráfico e seu seletor de período convivem em uma pilha vertical, a regra de Harry mapeia essa pilha para um split arrangement, que mantém os dois visíveis conforme o aparelho dobra; o gráfico em si nunca deveria se deslocar.

Principais conclusões

Para quem faz design: - Duas classes de tamanho, e não posições: compact width por fora, regular width por dentro.¹ O único extra opcional sugerido pelos designers da Apple é um layout de mesa que mantenha os mesmos controles.² - Ícones vão para a vertical, texto fica na horizontal; o topo da barra lateral é Back ou Close, depois Done; ações frequentes e itens com badge vão para o overflow por último.⁴ - Conteúdo com rolagem nunca se desloca; alertas, menus, folhas e controles se deslocam, e o destino segue o propósito: alertas para o lado trailing na posição de livro e para a região superior sobre a mesa, e controles de toque para a metade inferior.²³

Para quem faz engenharia de design: - A dobra é uma division region ativa apenas quando o aparelho está dobrado e com largura zero quando ele está plano; a câmera interna é uma occlusion region ativa apenas enquanto a câmera estiver ativa; ambas podem ser consultadas a partir de um GeometryProxy ou de uma UIView.³ - Os arrangements chegam com o iOS 27.1: uma pilha vira um split, um ZStack vira um overlay, e os containers de navegação ficam do lado de fora.³ - Use as barras do sistema vindas de containers de navegação, ou o layout vertical nunca vai acontecer.⁴

Perguntas frequentes

Preciso de um layout para cada posição?

Não. A Apple orienta projetar para duas classes de tamanho, compact width na tela externa e regular width na tela interna, e evitar larguras fixas, breakpoints ou medidas presas a uma tela.¹² O único extra opcional, vindo do Tech Talk de design, é um layout para a posição de mesa com os mesmos controles e a mesma hierarquia.²

Quais controles continuam horizontais no iPhone Duo?

Itens só de texto, itens largos demais para a barra lateral, como controles segmentados, itens que alternam entre símbolo e texto, como Edit, barras de acessórios de teclado e, se essa for a sua escolha, a barra inteira em um app de página única com peso embaixo ou em uma folha com um único item de barra de ferramentas.²⁴

O que é deslocamento?

É o padrão da Apple para mover, redimensionar ou reorganizar elementos existentes de modo que eles continuem visíveis e alcançáveis quando o aparelho está parcialmente dobrado. Alertas, menus, popovers, folhas e botões de barra de ferramentas recebem isso do sistema; conteúdo com rolagem fica de fora.²³

Quando chegam as arrangement views e as APIs de reserved region?

O Tech Talk sobre layouts adaptativos afirma que os arrangements fornecidos pelo sistema podem ser usados nos seus apps a partir do iOS 27.1, e a página de desenvolvedores da Apple situa o beta do Xcode 27.1 mais adiante em setembro. O guia de design ainda não vincula documentação para nenhuma das duas APIs.¹³⁵

Conteúdo com rolagem precisa evitar a dobra?

Não. Tanto o Tech Talk de design quanto o de layouts adaptativos deixam o conteúdo com rolagem de fora; ele já se adapta pela própria rolagem.²³

Fontes