Prepare seu app para o iPhone Duo: um exemplo prático

Como preparar um app para o iPhone Duo? Compile com o SDK do iOS 27.1, percorra cada pose no simulador, corrija o que o percurso mostrar e organize o envio em torno de duas datas que a Apple ainda não anunciou. O iPhone Duo chega às lojas em 23 de outubro com o iOS 27.1.¹ O que um app recebe nele é decidido pela versão do SDK carimbada no binário: um mesmo arquivo-fonte linkado como 26.0, 27.0 e 27.1 apareceu como uma caixa do tamanho de um celular, como uma janela ao lado do trilho de status e como a tela inteira, com as barras na lateral e a dobra informada.¹² Em 2 de outubro, só os betas da Apple carimbam 27.1 ou posterior (o Xcode 27.1 beta, que tem o simulador do Duo, e o Xcode 27.2 beta), e o App Store Connect aceita os builds deles para o TestFlight, não para a loja.⁸ Este post faz o trabalho inteiro no Kiradex, um app para colecionadores de cartas que temos no TestFlight: o que veio de graça, o que o percurso pegou e a leitura do código não, as capturas para as duas telas e um briefing que você pode entregar a um agente de programação.

TL;DR

• O carimbo do SDK é o interruptor. O iOS lê a versão do SDK no LC_BUILD_VERSION do binário. Carimbada com 27.1, a sonda recebeu a tela inteira, 466 por 678 pontos fechado e 951 por 669 aberto, com barras verticais e regiões reservadas. Carimbada com 27.0, parou 80 pontos antes da borda onde fica o trilho de status, manteve as barras horizontais e não ficou sabendo nada sobre a dobra. Carimbada com 26.0, era um celular de 375 por 667 dentro de uma caixa. Confira o seu com otool -l.¹²
• O calendário tem duas datas em aberto. O TestFlight aceita builds com o SDK 27.1 desde 18 de setembro e builds do beta 27.2 desde 16 de setembro; a App Store aceita apenas builds com o SDK 27.0; os tamanhos de captura do Duo estão publicados e o upload delas “will be available later this year” (ficará disponível ainda este ano).⁸⁹ Uma chave de tela de lançamento agora também é obrigatória no upload.¹⁰
• Os contêineres do sistema fizeram quase tudo. Um TabView, um NavigationStack em quatro das cinco abas e itens de barra de ferramentas com título e símbolo colocaram as barras do Kiradex na lateral sem nenhum código específico do Duo. Um único ArrangementView dividiu a tela aberta e levou o divisor para a dobra na pose Book. Um único onHingeChange reproduz de novo a abertura do app quando o celular se desdobra.¹³
• O percurso pegou o que a leitura não pegou. Uma sheet cujo único botão é um “Done” em texto reserva o trilho lateral e o deixa vazio. A carta em tela cheia passa por baixo da câmera externa. Girada para retrato, a divisão empilha. Uma carta aberta no momento em que o celular se desdobra cai no layout compacto, esticado. O layout de largura regular, escrito para a tela interna, quebra num iPhone de 6,9 polegadas em paisagem.¹³
• Enquanto a loja não aceitar 27.1, uma mesma árvore de código precisa de dois Xcode. #available não ajuda; o SDK 27.0 não tem nenhum ArrangementView contra o qual compilar. Uma flag de compilação, ou #if canImport(SwiftUI, _version: 8.0.85), cerca as chamadas novas.¹⁴
• As capturas saem da mesma execução. As capturas do simulador têm exatamente os tamanhos do App Store Connect, e as aberturas das molduras do Duo da Apple também. As regras da Apple continuam pedindo vista frontal, sem modificações e sem renderizações 3D do aparelho.⁹¹¹

Onde as coisas estão em 2 de outubro

Três dessas linhas dependem da Apple, e nenhuma bloqueia o trabalho. A ordem que sai da tabela: levar o app para o SDK 27.1 e para o simulador, percorrer cada pose, corrigir o que o percurso mostrar, colocar esse build no TestFlight e deixar prontos o envio para a loja e as capturas do Duo para o dia em que cada um abrir.

O ponto de partida da própria Apple é a primeira das suas seis Tech Talks, de dez minutos, e tudo o que vem abaixo pressupõe que você a viu:

Passo um: o carimbo do SDK decide o que o celular te dá

A palestra abre com uma promessa de compatibilidade em três níveis. Um app que não foi compilado com o SDK do iOS 27 continua funcionando: “When the device is closed, your app will use the screen space to the left of the status bar and camera. When the device is open, your app will be a familiar size and aspect ratio.” (0:36) (com o aparelho fechado, o app usa o espaço à esquerda da barra de status e da câmera; aberto, tem um tamanho e uma proporção familiares). Um app que adotou o SDK do iOS 27 “will extend to the left of the status bar area on the inner display.” (0:58) (se estende até a esquerda da área da barra de status na tela interna). E então: “When you build your app with the iOS 27.1 SDK, your app extends to the edge of the screen. Standard navigation and toolbar buttons now lay out vertically under the status bar.” (1:05) (compilado com o SDK do iOS 27.1, o app vai até a borda da tela, e os botões padrão de navegação e de barra de ferramentas passam a se organizar na vertical sob a barra de status).³

Esses níveis não são uma propriedade do seu código. São uma propriedade de um único número no seu binário, a versão do SDK que o linker registra no comando de carga LC_BUILD_VERSION, e o iOS lê esse número na inicialização. Para ver quanto depende dele, construí uma sonda pequena, um TabView com um NavigationStack que tem uma barra de ferramentas de cinco itens e um ArrangementView, três vezes a partir do mesmo arquivo-fonte. A única diferença entre os três binários é esse número: 26.0, 27.0, 27.1. Depois rodei os três no simulador do iPhone Duo em cada pose.¹²

Um arquivo-fonte, três carimbos de SDK, aberto e na vertical. Da esquerda para a direita: 26.0, 27.0, 27.1.

Os tamanhos de janela estão em pontos, como a janela de cada build os informou.¹²

Leia a coluna do meio duas vezes, porque é ela que a maioria dos apps está prestes a publicar. Um build do Xcode 27 recebe largura regular na tela interna e quase toda a tela, uma melhora real em relação ao celular dentro da caixa da primeira coluna. Ele para 80 pontos antes da borda final, onde fica o trilho de status, não recebe barras verticais e o sistema não diz nada a ele sobre a dobra nem sobre as câmeras: toda consulta de regiões reservadas voltou vazia, em todas as poses, não importa quantas vezes a sonda perguntasse.¹² Para ter certeza de que o carimbo era um substituto justo, também compilei uma versão simples da sonda com o próprio Xcode 27.0, contra o seu próprio SDK do iOS 27.0. Ela recebeu as mesmas janelas: 386 por 678 fechado, 871 por 669 aberto.¹²

O guia escrito da Apple é menos exato aqui do que a palestra, e a redação dele mudou. Em 17 de setembro, a visão geral dizia “Build your app with Xcode 27.1 or later to use all of the available screen space on iPhone Duo. In earlier versions, your app doesn’t extend under the status bar and camera.” (compile com o Xcode 27.1 ou posterior para usar todo o espaço de tela; em versões anteriores o app não se estende sob a barra de status e a câmera). Em 19 de setembro passou a dizer, como diz em 2 de outubro, “Build your app with the latest version of Xcode to use all of the available screen space on iPhone Duo. When you build with Xcode 26 and earlier, your app doesn’t extend under the status bar and camera.” (compile com a versão mais recente do Xcode; compilando com o Xcode 26 ou anterior, o app não se estende sob a barra de status e a câmera).² A frase nova só aponta o Xcode 26 e anteriores como insuficientes, e “latest version” não diz se um beta conta, então um leitor poderia concluir que um build do Xcode 27.0 recebe a tela inteira. No simulador deste beta, não recebe. Recebe o nível intermediário da palestra, e a redação anterior batia com o que eu medi. Até o hardware dizer outra coisa, planeje pela tabela.

Então, antes de qualquer outra coisa, confira o carimbo do build que você está testando:

otool -l Build/Products/Debug-iphonesimulator/YourApp.app/YourApp | grep -A4 LC_BUILD_VERSION

Um build de debug do Xcode guarda o código em YourApp.debug.dylib ao lado de um pequeno inicializador, e os dois carregam o comando. O que você procura é sdk 27.1 ou posterior; a sonda carimbada com 27.2, que é o que o SDK do Xcode 27.2 beta gravaria, recebeu o mesmo tratamento que a de 27.1.¹² O do Kiradex mostra minos 27.0 e sdk 27.1: ele instala no iOS 27.0 e recebe o comportamento do 27.1 num Duo.¹³

Insisto nisso porque errei em público. Meu primeiro relato sobre este simulador, de 21 de setembro, dizia que a barra de ferramentas nunca ficava vertical e que as regiões reservadas estavam vazias em todas as poses. O beta estava certo. Eu tinha compilado aquela sonda chamando swiftc -sdk diretamente, a etapa de link usou como raiz o SDK do macOS dentro do mesmo Xcode e o binário saiu carimbado com 27.0: tudo o que medi naquele dia era a coluna do meio. Aquele post agora traz a correção.¹² Se o seu layout do Duo parecer adotado pela metade no simulador, com barras no topo e uma faixa preta morta na lateral, confira o carimbo antes de conferir o código.

O app na bancada

O Kiradex é um app para colecionadores de cartas colecionáveis que temos no TestFlight: cada coleção, as cartas que você tem e as que quer, quanto elas valem ao longo do tempo e cada carta como um objeto 3D que você pode virar. É gratuito, só para iPhone, roda no iOS 27.0 e posteriores e guarda as listas de cada colecionador no iCloud dele, sem nenhum servidor nosso no meio.¹³ Não está pronto. O scanner nunca viu uma câmera de verdade e, até esta semana, ninguém tinha olhado o app num Duo aberto: ao lado do layout da tela interna, o roadmap dele trazia a linha “Seen on the open Duo’s inner display only by the column maths; the simulator was folded shut.” (na tela interna do Duo aberto, visto só pela conta das colunas; o simulador estava fechado).¹³ Isso faz dele um teste justo. O trabalho para o Duo que ele contém foi escrito a partir da documentação da Apple e nunca conferido numa tela.

O que ele faz para o Duo é pouco, e vale listar justamente por quão pouco disso é código do Duo:

• A navegação é do sistema. Um TabView com cinco abas, uma delas com o papel de busca, e um NavigationStack em quatro delas; o scanner é uma visão de câmera sem barra própria. Os itens da barra de ferramentas são Labels com título e símbolo, anexados com .toolbar. Não há barra personalizada em lugar nenhum.
• O layout segue a classe de tamanho. A largura compacta recebe uma página de fichário de três colunas e empurra o inspetor de uma carta para a pilha. A largura regular, que num app só para iPhone quase sempre significa a tela interna do Duo, recebe uma parede de cartas num número par de colunas; ao escolher uma, a tela se divide entre a página e o inspetor.
• Duas chamadas do SDK 27.1. A divisão é um ArrangementView no estilo .split, com um HStack como alternativa abaixo do iOS 27.1. E onHingeChange reproduz de novo a animação de abertura do app, um aparelho vermelho se abrindo, quando o celular passa de fechado para qualquer outro estado.
• Sem trava de orientação, e com tela de lançamento. O Info.plist lista retrato e as duas paisagens e declara UILaunchScreen.¹³

Essa é a lista inteira: duas verificações de disponibilidade em dois arquivos. Todo o resto que o celular faz com o app, ele faz com qualquer app construído desse jeito.

As imagens deste post mostram o app em funcionamento, com imagens de cartas do catálogo público que ele consulta. O Kiradex é uma ferramenta independente para colecionadores, sem afiliação nem endosso da Nintendo, da Creatures Inc., da GAME FREAK inc. ou da The Pokémon Company, e as imagens das cartas pertencem aos seus donos.

Passo dois: percorra cada pose

O guia da Apple apresenta o percurso como quatro verificações:²

• “Confirm your views resize well in each supported orientation and pose.” (confirme que suas views se redimensionam bem em cada orientação e pose suportadas).
• “Inspect how the system presents your app’s navigation bars, toolbars, and tab bars vertically on the side of the display.” (examine como o sistema apresenta na vertical, na lateral da tela, as barras de navegação, de ferramentas e de abas do seu app).
• “Identify any views, sheets, or popovers that position awkwardly when you fold or open iPhone Duo.” (identifique views, sheets ou popovers que ficam mal posicionados quando você dobra ou abre o iPhone Duo).
• “Identify elements or controls in your views that appear in the fold, and are difficult to see or interact with.” (identifique elementos ou controles que caem na dobra e ficam difíceis de ver ou de usar).

As diretrizes de design dizem quantos layouts isso deveria exigir: “A compact width layout for the outer display and a regular width layout for the inner display give you the fundamentals for every pose.” (um layout de largura compacta para a tela externa e um de largura regular para a interna te dão o essencial para todas as poses).⁷

As poses são botões no Device Hub: Closed, Book, Open e Rotate Right, e cada combinação é uma tela diferente. O guia do SwiftLee acrescenta um controle mais fino de que não precisei: “Holding Option ⌥ reveals a slider that you can use to control the hinge angle of the device with precision” (segurar a tecla Option ⌥ revela um controle deslizante para ajustar com precisão o ângulo da dobradiça).¹⁷ Antes de olhar o app, ajuda saber o que o sistema entrega a qualquer app em cada uma. Estas são as leituras da sonda com o carimbo 27.1:¹²

Três coisas nessa tabela moldaram tudo o que veio depois.

A janela não muda quando o celular dobra. Book e Open informam o mesmo tamanho. A única diferença que o app consegue ver é que a divisão da dobra passa de inativa para ativa, e que a dobradiça informa parcialmente aberta a 127 graus onde antes informava totalmente aberta a 180. Um app que lê só o próprio tamanho nunca descobre que o celular foi dobrado.

A dobra está sempre lá, e é pequena. Ela é informada aberta ou dobrada, bem no meio, e o frame que a API devolve tem 40 pontos de largura nos dois estados, com 20 pontos de margem de cada lado. A palestra da Apple diz sobre a região da dobra: “When flat, it’s inactive and has a width of zero.” (7:32) (na posição plana, ela está inativa e tem largura zero). O simulador não devolve um frame de largura zero. As notas de campo de Artem Novichkov descrevem a mesma leitura como “40 pt wide, with 20 pt margins on each side of a zero-width fold line,” (40 pt de largura, com margens de 20 pt de cada lado de uma linha de dobra de largura zero)¹⁷ e eu leio o zero da palestra do mesmo jeito, como a linha entre as margens; isso é uma leitura minha, não algo que o texto da Apple diga. A palestra também dá a dica prática: “By default, only active ones will be returned, but you can query for inactive ones” (por padrão só as ativas são devolvidas, mas você pode consultar as inativas) e “in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state.” (em layouts de grade, vale preferir um número par de colunas quando há uma região de divisão, esteja ela ativa ou não) (7:16, 7:41)⁵

As regiões chegam atrasadas. Em toda inicialização, as primeiras avaliações da sonda não leram nenhuma região, e todas as avaliações seguintes leram o conjunto completo. Uma view que pergunta uma única vez, na primeira passada de layout, guarda em cache um array vazio. Leia as regiões no body da view, a cada avaliação; a sonda se reavaliava num timer de um segundo, e as notas de Artem Novichkov dão a regra sem rodeios: “Read them in the GeometryReader body so the view updates when they arrive. Don’t cache them.” (leia-as no body do GeometryReader para que a view se atualize quando elas chegarem; não as guarde em cache).¹²¹⁷

Uma observação prática antes do app. O runtime do simulador do iOS 27.1 neste beta suporta exatamente um tipo de dispositivo, o iPhone Duo; pedir um iPhone 18 Pro Max a ele falha com “Incompatible device”. Por isso a comparação abaixo, o mesmo build num iPhone comum, rodou no runtime do iOS 27.0, o que também é um jeito rápido de confirmar que as alternativas do #available funcionam.¹²

Um build do Kiradex num iPhone de 6,9 polegadas, no Duo fechado e no Duo aberto. Nada no código do app coloca as barras na lateral.

O que o percurso encontrou

Um teste de UI percorreu o build 5 por oito tipos de tela em cada uma de seis poses (sete com o celular fechado e girado, onde o botão de Ajustes tinha passado para o menu de mais opções), enquanto um script capturava as duas telas em cada parada: 1398 por 2034 pixels por fora, 2853 por 2007 por dentro, os tamanhos que o App Store Connect lista.¹³ Comparado às quatro verificações da Apple, o app passou em mais do que eu esperava e falhou em lugares que nenhuma leitura do código tinha apontado.

O que veio de graça

As barras. Fechado, a barra de ferramentas e as cinco abas ficam no trilho sob o relógio; aberto, a mesma coisa; aberto e girado, elas voltam para cima e para baixo. Nada no app pede nada disso. A segunda palestra explica por que barras feitas à mão ficam para trás: “When used to build custom bars, content from sub-components like UIToolbar, UINavigationBar, or UITabBar won’t be considered.” (2:52) (quando usados para construir barras personalizadas, o conteúdo de subcomponentes como UIToolbar, UINavigationBar ou UITabBar não é levado em conta).⁴ E como todo item da barra de ferramentas nas telas principais é um Label, cada um tem um símbolo para o trilho e um título para o menu de mais opções, que é a outra condição do guia: “If your item has a title and doesn’t have an icon, the system doesn’t present it vertically.” (se o item tem título e não tem ícone, o sistema não o apresenta na vertical).²

A dobra. Aberto, as cartas de uma coleção ficam seis por linha, um número par, então nenhuma carta fica no meio da tela. Escolha uma e a tela se divide entre a página e o inspetor da carta no meio da área de conteúdo do app, x 433. Isso fica 42 pontos à esquerda da dobra, porque o trilho tira 84 pontos do lado direito, e enquanto o celular está plano isso não importa. Na pose Book, a visão de arranjo leva o divisor para a dobra e deixa vazia a faixa de 40 pontos: o inspetor que começava em x 433 agora começa em 495. O app não tem código nenhum para a pose Book; isso é o ArrangementView fazendo o que a palestra descreve, “moving, resizing, or reorganizing what’s already there.” (6:04) (movendo, redimensionando ou reorganizando o que já está lá).⁵¹³

Aberto e plano, depois na pose Book. O vão da segunda imagem é a dobra, e não foi o app que o colocou ali.

As sheets, com o celular aberto. Na tela interna, uma sheet aparece centralizada e o botão Done dela continua horizontal; na pose Book, a sheet da sonda se moveu sozinha para o lado inicial da dobra.¹²

A dobradiça, como evento. Desdobre o celular com o app rodando e a abertura dele toca de novo na tela interna: o aparelho vermelho, fechado, depois se abrindo até virar o app. Isso é um único handler onHingeChange que dispara quando o estado deixa de ser closed, e é exatamente a divisão de tarefas que a quarta palestra pede: “Hinge data is observed live, and is ideal for driving interactions or effects. For layout, use the arrangement and region APIs.” (2:34) (os dados da dobradiça são observados ao vivo e são ideais para conduzir interações ou efeitos; para layout, use as APIs de arranjo e de regiões).⁶

Desdobrando com o app rodando: a abertura é o próprio aparelho do app, desenhado pelo app e reproduzido pela dobradiça.

O que passou batido

Uma sheet com um único botão de texto reserva o trilho e o deixa vazio. Fechado, a sheet de Ajustes cede uma faixa ao longo da borda final para uma barra vertical e depois não coloca nada nela: o único item da barra de ferramentas é um “Done” com título e sem símbolo, e um item só de texto fica na horizontal. O formulário é espremido no que sobra. A sonda mediu o custo: 374 pontos de largura de conteúdo com o trilho reservado, 450 com a barra vertical desligada.¹² A palestra da Apple cita esse caso: “if a sheet is control-heavy with only one item, like the close button here, consider disabling a vertical bar so it doesn’t reduce available space.” (14:37) (se uma sheet é cheia de controles e tem um só item, como o botão de fechar aqui, considere desativar a barra vertical para que ela não reduza o espaço disponível).⁴ Há dois consertos, e a sonda testou os dois. Dê um símbolo ao botão, Button("Done", systemImage: "checkmark"), e ele vai para o trilho como um visto em destaque; ou acrescente .toolbarVerticalBehavior(.disabled) ao conteúdo da sheet e o trilho some, ao custo de uma sheet mais baixa.

Da esquerda para a direita: a sheet do app, depois a sonda com um Done só de texto, com um símbolo e com a barra vertical desativada.

A carta em tela cheia passa por baixo da câmera. A peça de destaque do app é uma carta num palco preto com as barras escondidas, e esse palco ignora a área segura em todas as bordas. Na tela externa, isso manda o canto superior da carta para baixo da câmera. O sistema informa essa câmera a qualquer view que pergunte, como uma oclusão ativa de 37 pontos de lado, e a posição dela bate com o recorte da própria moldura da Apple com diferença de um ponto e meio.¹¹¹² As diretrizes de design da Apple permitem o tratamento de largura total “as long as nothing conflicts with the Dynamic Island or the status bar.” (desde que nada entre em conflito com a Dynamic Island ou com a barra de status).⁷ O conserto é manter o sangramento total para o fundo preto e trazer a carta em si para dentro: ou deixar o palco respeitar a área segura superior e final nessa tela, ou ler reservedRegions(kind: .occlusion) e enquadrar a carta longe do que voltar.

A captura do visualizador dentro da moldura da Apple para a tela externa. A captura do simulador não tem buraco nenhum; o celular tem.

Girado, os dois painéis empilham. Aberta e girada para retrato, a tela tem 669 pontos de largura e continua com largura regular, então o app continua dividindo. Só que uma visão de arranjo que preenche um espaço mais alto do que largo divide em cima e embaixo, segundo o guia da Apple: “it places the primary view on top and the secondary view below it when the containing view is taller than it is wide.” (ela coloca a view primária em cima e a secundária embaixo quando o contêiner é mais alto do que largo).² O resultado é uma faixa que mostra uma fileira de cartas e o começo de uma segunda, acima de um inspetor. O próprio comentário do app nessa linha diz que o par “is only useful side by side,” (só é útil lado a lado) e nada garantia isso. Limitar o estilo com .split.axes(.horizontal) é o controle documentado,¹⁶ com uma pegadinha que a palestra deixa explícita: “If the split arrangement cannot split among an axis, and it’s the primary axis, the arrangement view chooses to only show a single view.” (12:44) (se o arranjo dividido não consegue dividir ao longo de um eixo, e esse é o eixo principal, a visão de arranjo mostra uma única view).⁵ A sonda confirma as duas metades: preenchendo a tela girada, uma divisão simples empilhou, e a divisão só horizontal mostrou o painel primário e mais nada.¹² Neste app isso esconderia o inspetor, então o conserto honesto é uma decisão, não um modificador: quando o espaço for mais alto do que largo, empurre o inspetor como faz o layout compacto.

Girado: barras horizontais, como dizem as diretrizes da Apple, e uma divisão que foi para o lado errado para este par de views.

Uma carta aberta no momento em que o celular se desdobra não cai em nenhum dos dois layouts. Fechado, escolher uma carta empurra o inspetor dela para a pilha de navegação. Desdobre com esse inspetor na tela e a carta continua lá, que é a parte fácil de errar. Mas ela ainda é uma tela empurrada, agora com 951 pontos de largura: o palco à esquerda, os detalhes numa caixa branca à deriva sobre o preto, um botão Back no trilho. O design do app para essa tela é a parede com a carta ao lado, e o único jeito de chegar a ele é voltar e escolher a carta de novo. Uma única seleção comanda os dois layouts; um único caminho de navegação, não. O conserto é perceber a mudança de largura compacta para regular com uma carta selecionada e tirar a tela empurrada da pilha, para que a divisão assuma.

A mesma carta antes e depois de desdobrar. O estado sobreviveu; o layout é o compacto, esticado.

Largura regular não é “o Duo”. O app trata largura regular como a tela interna: parede, colunas pares, divisão. Um iPhone de 6,9 polegadas deitado também tem largura regular, com altura compacta, e o app não trava a orientação. Ali, o mesmo ramo produz uma página recuada da borda esquerda, um inspetor cuja coluna de detalhes é estreita demais para o nome da carta e botões de ação cortados na borda inferior da tela. Nada disso é novo no iOS 27, e não apareceu em nenhuma pose do Duo que eu rodei; o trabalho para o Duo encontrou isso porque foi a primeira vez que alguém percorreu o layout de largura regular em todas as telas que a informam. A verificação que separa os dois casos é a outra classe de tamanho: a tela interna é regular nas duas, e a palestra da Apple dá a tela externa deitada como compacta nas duas.³ Um layout que precisa de espaço em duas direções deveria pedir as duas.

O layout de largura regular num celular que não é um Duo: um iPhone de 6,9 polegadas deitado, iOS 27.0.

O teclado cobre o trilho. Com o teclado aberto na tela externa, as abas da parte de baixo do trilho ficam atrás dele. Esse é o layout do sistema, não um defeito; a palestra diz que a barra pode precisar transbordar “as other competing UI appears, like the keyboard” (à medida que aparece outra interface concorrente, como o teclado) (11:50).⁴ Está nesta lista porque quebrou as ferramentas: meu primeiro percurso tocou em “Collection” com o teclado de busca aberto, e o toque caiu na letra P. Testes de UI que presumem que uma barra de abas está sempre ao alcance falham aqui primeiro.

Duas coisas menores. O app escolhe colunas pares a partir da classe de tamanho de largura, quando a sugestão da palestra é a própria região da dobra, presente ou não. E uma que não tem nada a ver com dobrar: aberto quatro vezes seguidas no simulador de 6,9 polegadas, o visualizador em tela cheia mostrou a carta na primeira vez e uma tela preta vazia nas três seguintes. Nenhuma das duas impede um build de TestFlight. As duas estavam invisíveis até o app estar numa tela e alguma coisa apertar os botões dele em ordem.

O que o simulador não conseguia mostrar

O scanner. Ele abre a câmera grande-angular traseira e já usa um coordenador de rotação, que é o que a palestra sobre câmera pede: “On iPhone Duo, the rotation coordinator will update when your app moves displays.” (8:19) (no iPhone Duo, o coordenador de rotação se atualiza quando o app muda de tela).⁶ Se a sessão sobrevive à passagem de uma tela para a outra é uma pergunta para o hardware; o simulador não tem câmera nenhuma. As notas de versão da Apple acrescentam o StandBy e a maioria das extensões de app ao que este runtime não consegue rodar, e as notas do Xcode 27.2 beta 2 acrescentam uma para quem automatiza capturas: “Screenshots and recordings in iPhone Duo may be black for up to a few minutes after booting the device.” (capturas e gravações no iPhone Duo podem sair pretas por até alguns minutos depois de iniciar o aparelho).²⁰

Uma árvore de código, dois Xcode

O calendário cria um problema. O build que a loja aceita sai do Xcode 27 e do SDK 27.0; o build que se comporta direito no iPhone Duo sai do SDK 27.1. Até a Apple abrir a loja para o segundo, um app que queira publicar uma atualização e continuar trabalhando no layout do Duo tem que compilar com os dois.

if #available(iOS 27.1, *) não resolve. Disponibilidade é uma pergunta de tempo de execução; o compilador ainda precisa encontrar o símbolo. O Kiradex envolve as suas duas chamadas do Duo exatamente desse jeito, e o deployment target dele é 27.0, então o build instala num celular que não foi atualizado. Com o SDK 27.1, isso compila. Com o Xcode 27.0, um arquivo que faz a mesma coisa para em error: cannot find 'ArrangementView' in scope, porque o SDK 27.0 não tem esse tipo.¹⁴ O Kiradex ainda não está na loja, então pode simplesmente ficar na toolchain beta; um app com clientes não pode.

As condições documentadas do Swift também não separam os dois SDKs. #if compiler(>=6.4) é verdadeiro nos dois: Xcode 27.0, Xcode 27.1 beta e Xcode 27.2 beta imprimem todos o mesmo Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).¹⁴ Sobram duas cercas, e testei as duas.

Uma condição de compilação definida por você. Este é o caminho documentado. Defina uma flag só na configuração que você compila com o beta (no Xcode, SWIFT_ACTIVE_COMPILATION_CONDITIONS = DUO_SDK; na linha de comando, -D DUO_SDK) e cerque com ela o código exclusivo do 27.1:

struct Pair<Primary: View, Secondary: View>: View {
    @ViewBuilder var primary: Primary
    @ViewBuilder var secondary: Secondary

    var body: some View {
        #if DUO_SDK
        if #available(iOS 27.1, *) {
            ArrangementView { primary } secondary: { secondary }
                .arrangementViewStyle(.split)
        } else {
            HStack(spacing: 0) { primary; secondary }
        }
        #else
        HStack(spacing: 0) { primary; secondary }
        #endif
    }
}

Sem a flag, esse arquivo passa na checagem de tipos no Xcode 27.0 e no beta 27.1. Com a flag, passa no beta e falha no 27.0 com o mesmo erro de símbolo ausente: a combinação errada não compila.¹⁴

A versão do próprio SDK, lida pelo compilador. canImport aceita um segundo argumento com sublinhado que compara com a versão de um módulo, e a versão do módulo SwiftUI muda de um SDK para outro: 8.0.84.1.104 no SDK 27.0, 8.0.85.27 no SDK 27.1, 8.1.6.1.101 no SDK do beta 27.2.¹⁴ Então isto não precisa de nenhum ajuste de build:

#if canImport(SwiftUI, _version: 8.0.85)
// ArrangementView, reservedRegions, onHingeChange, toolbarVerticalBehavior
#else
// what the app did before
#endif

Coloquei um #warning em cada ramo e compilei com os três Xcode: o 27.0 pegou o segundo ramo, e o beta 27.1 e o beta 27.2 pegaram o primeiro.¹⁴ O cuidado está no sublinhado. A gramática dessa condição no livro do Swift é canImport(import-path) e mais nada, então _version: é um recurso do compilador sem contrato documentado, e o número 8.0.85 é algo que eu li de dois SDKs, não algo que a Apple publicou.¹⁴ Use-o enquanto a loja estiver fechada para o 27.1, se um ajuste de build for incômodo no seu projeto; use a flag se quiser algo que dê para defender.

Seja como for, a cerca é temporária. No dia em que o App Store Connect aceitar builds de um Xcode que traga o SDK 27.1, apague-a e mantenha as verificações #available, que são o que protege um celular ainda no iOS 27.0.

Envio: o que o App Store Connect aceita hoje

O TestFlight aceita o build 27.1. As notas de versão do App Store Connect de 18 de setembro: “You can now submit apps built with Xcode 27.1 beta using the SDK for iOS 27.1 beta or iPadOS 27.1 beta for internal and external testing.” (você já pode enviar apps compilados com o Xcode 27.1 beta usando o SDK do iOS 27.1 beta ou do iPadOS 27.1 beta para testes internos e externos). As entradas de 16 e de 28 de setembro dizem o mesmo para o Xcode 27.2 beta e o beta 2.⁸ O Kiradex sobe por esse caminho; o quinto build dele, o que este post testa, foi enviado em 2 de outubro e o App Store Connect o lista como válido.¹³

A App Store, ainda não. A entrada mais recente que abre a loja é a de 14 de setembro: “You can now upload apps built with Xcode 27 using the SDK for iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, and watchOS 27.0 for the App Store, and for internal and external testing through TestFlight.” (você já pode enviar apps compilados com o Xcode 27 e os SDKs 27.0 para a App Store e para testes internos e externos pelo TestFlight).⁸ Nada depois dela menciona o 27.1 e a loja na mesma frase, e o feed de lançamentos da Apple, cujos itens mais recentes são de 28 de setembro, lista um único build do Xcode 27.1, o beta de 18 de setembro.⁸ A Apple não disse quando isso muda. O aparelho chega às lojas em 23 de outubro.¹

A menos que a Apple abra a loja para o SDK 27.1 antes de 23 de outubro, o build da loja que os seus clientes terão no dia do lançamento será, na melhor das hipóteses, um build com o SDK 27.0, e a comparação acima diz o que ele recebe no simulador, com a palestra da Apple descrevendo o mesmo nível intermediário: a tela ao lado do trilho de status, barras horizontais, sem dobra. Isso é um app utilizável se ele se redimensiona bem, e esse é o argumento para publicar agora, com o Xcode 27, o trabalho de redimensionamento.

A tela de lançamento agora é obrigatória. Não é uma regra do Duo, mas chega com o mesmo SDK e falha no upload, não na revisão. A nota técnica da Apple: “Starting in iOS 27 and iPadOS 27, App Store Connect requires your app to include a launch screen configuration in its Info.plist,” (a partir do iOS 27 e do iPadOS 27, o App Store Connect exige que o app inclua uma configuração de tela de lançamento no Info.plist) e, sem uma de UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen ou UILaunchScreens, o upload é rejeitado com “ITMS-90870: Missing launch screen.”¹⁰ O Kiradex declara UILaunchScreen com uma cor, o vermelho da capa dele, então a inicialização emenda direto na animação de abertura.¹³

Os espaços para capturas existem no papel. As especificações de capturas de tela do App Store Connect listam o iPhone Duo desde 9 de setembro, em dois pares: 1398 por 2034 ou 2034 por 1398 pixels para a tela externa, e 2007 por 2853 ou 2853 por 2007 para a interna, com a observação “Support for uploading assets for this device in App Store Connect will be available later this year.” (o suporte ao upload de materiais para este aparelho no App Store Connect ficará disponível ainda este ano).⁹ Valem as regras de sempre: “You can upload one to 10 screenshots in .jpeg, .jpg, and .png formats,” (você pode enviar de uma a 10 capturas nos formatos .jpeg, .jpg e .png) e “Images can’t include alpha channels or transparencies.” (as imagens não podem ter canais alfa nem transparências).⁹

Uma frase da página de upload decide como planejar em torno disso: “Once your app is submitted for review and approved, you must create a new version to update the screenshots.” (depois que o app é enviado para revisão e aprovado, é preciso criar uma nova versão para atualizar as capturas).⁹ As capturas do Duo não podem entrar depois por conta própria; quando os espaços abrirem, elas vão junto com uma versão.

Juntando tudo, a sequência que eu seguiria, e que estou seguindo com o Kiradex:

1. O build 27.1 no TestFlight agora, com os achados do percurso corrigidos conforme aparecem.
2. Para um app que já está na loja: uma atualização compilada com o Xcode 27 que traga todo conserto que não precise do SDK 27.1. Classes de tamanho em vez de verificações de idiom e de orientação, áreas seguras por borda, barras pertencentes a contêineres do sistema, um título e um símbolo em cada item da barra de ferramentas.
3. Capturas feitas agora nos tamanhos do Duo, a partir do simulador, e guardadas.
4. Uma versão pronta para o dia em que duas coisas forem verdade: a loja aceitar um Xcode com o SDK 27.1 e os espaços do Duo aceitarem uploads. Até agora a Apple publicou cada mudança desse tipo nas notas de versão do App Store Connect, entre elas a entrada de 14 de setembro que abriu a loja para o Xcode 27 e a de 9 de setembro que acrescentou as especificações de capturas do Duo, então essa é a página a acompanhar, com a página de notícias para desenvolvedores ao lado.⁸

Há mais um requisito, mais adiante. A partir de abril de 2027, “iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later” (apps de iOS e iPadOS precisam ser compilados com o SDK do iOS 27 e do iPadOS 27 ou posterior) para poderem ser enviados.¹⁸ Um app ainda compilado com um SDK do iOS 26 recebe num Duo a menor das três imagens acima e, a partir de abril de 2027, não consegue enviar uma atualização até migrar para o SDK do iOS 27.

Capturas para duas telas

O percurso já produziu a matéria-prima: cada parada foi capturada em 1398 por 2034 e 2853 por 2007 pixels e, girada, em 2034 por 1398 e 2007 por 2853, os quatro tamanhos da linha do iPhone Duo no App Store Connect.⁹¹³ O que falta é decidir o que vai em volta delas, e é aí que um celular dobrável convida ao erro.

A imagem que todo mundo quer é o celular meio aberto, em ângulo, com o app se derramando pela dobra. As diretrizes de marketing da Apple vetam isso linha por linha. Sobre as imagens de aparelhos da própria Apple: “Use Apple product images ‘as is’ and without modification. Modifications include adding reflections, shadows, highlights, or graphic elements that appear to enter or come out of the product screen; cropping, tilting, or obstructing any part of the images; animating, flipping, or spinning the images” (use as imagens de produtos da Apple como estão, sem modificação: nada de reflexos, sombras, brilhos ou elementos que pareçam entrar ou sair da tela, nada de cortar, inclinar, obstruir, animar, espelhar ou girar as imagens). Sobre imagens que você mesmo produz: “Straight-on product shots are preferred. Don’t use extreme angles or alter an Apple product in any way.” (fotos frontais do produto são preferíveis; não use ângulos extremos nem altere um produto da Apple de forma alguma). E em Unauthorized Uses, a primeira da lista: “Rendering in 3D or creating any simulation of an Apple product” (renderizar em 3D ou criar qualquer simulação de um produto da Apple).¹¹ Meu post sobre capturas de tela mostra como os vencedores de prêmios lidam com essas regras e como fica um conjunto que as respeita; nada numa dobradiça muda isso.

O que a Apple oferece em troca é um pacote de molduras (bezels) para este celular, em dois acabamentos e cinco vistas: o celular fechado em retrato e em paisagem, a tela interna aberta em paisagem e em retrato, e o celular aberto visto de trás, com a tela externa ao lado das câmeras. As aberturas desses arquivos têm exatamente os tamanhos das capturas, então uma captura do simulador encaixa sem redimensionar.¹¹ Não existe vista meio dobrada nem vista em ângulo.

Por isso os quadros abaixo são feitos de três partes: um fundo nas cores do próprio app, uma linha curta de texto e a captura dentro da moldura da Apple, inteira e reta, sem nada por cima. A variedade vem do fundo, do tamanho do aparelho e de um quadro por conjunto sem aparelho nenhum: a carta em tela cheia do app sobre preto, que é o 3D do próprio app e não o hardware de ninguém.

Três conjuntos montados por script a partir das capturas do percurso, em 1320 por 2868, 1398 por 2034 e 2853 por 2007 pixels. Eles mostram o método, não a página da loja: estas capturas trazem cartas do catálogo, e o que o conjunto da loja vai mostrar é a pergunta em aberto da terceira observação abaixo.

Três observações práticas de quem montou.

Monte por script. Os conjuntos acima saem de um único arquivo Python que recebe uma captura, uma manchete e um fundo e grava um PNG no tamanho exato, sem canal alfa. Quando o app muda, e este mudou duas vezes no dia em que o capturei, o percurso roda de novo e os quadros se refazem.

Capture o que o celular acrescenta. A página de upload da Apple diz que um conjunto de 6,9 polegadas basta quando a interface é igual em todos os tamanhos: “provide only the highest resolution screenshots required. They automatically scale down to smaller device sizes.” (forneça só as capturas de maior resolução exigidas; elas são reduzidas automaticamente para aparelhos menores).⁹ Neste celular ela não é igual: a parede de cartas e o inspetor dividido só existem na tela interna. Esses são os dois quadros que abrem o conjunto interno.

Cuidado com o que está na tela. As mesmas diretrizes dizem “You are responsible for securing the rights to all materials used in screen content within your app.” (você é responsável por garantir os direitos de todo o material que aparece na tela do seu app).¹¹ Um app para colecionadores mostra, por natureza, a arte de outras pessoas, e uma página da loja é marketing, que é algo diferente do que o app exibe no uso. Ainda não tomamos essa decisão para o Kiradex, e os quadros acima não serão enviados como estão. Por isso o percurso tem um segundo modo, que roda com seis cartas inventadas; elas ainda não têm arte, então um conjunto enviado significa desenhar substitutos ou resolver os direitos.

O Kiradex ainda não tem página na loja. Quando tiver, vai começar com um conjunto de 6,9 polegadas, e os conjuntos do Duo vão esperar, com uma versão própria, pelo dia em que o App Store Connect os aceitar.

Entregando o trabalho a um agente de programação

A maior parte deste trabalho é do tipo que um agente faz bem, desde que consiga ver o app. São duas metades, e a Apple entrega uma delas.

A metade estática é da Apple. A primeira Tech Talk termina nela: “During the talk, Modernize Your UIKit App, we introduced a new app modernization skill. With Xcode 27.1, this skill has a new name: App Resizability. It now supports SwiftUI and iPhone Duo.” (9:19) (na palestra Modernize Your UIKit App apresentamos uma nova skill de modernização de apps; com o Xcode 27.1 ela ganha um novo nome, App Resizability, e passa a suportar SwiftUI e o iPhone Duo).³ A skill é um conjunto de arquivos de texto puro dentro do beta: no Xcode 27.1 beta, Contents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/app-resizability.idechatprompttemplate e cinco arquivos de referência ao lado.¹⁵ As instruções dela dizem o quanto abrir a rede: “Treat a request about the foldable iPhone Duo as a request for every task in the Task Registry, because a screen that changes size exposes all of them at once.” (trate um pedido sobre o iPhone Duo dobrável como um pedido de todas as tarefas do Task Registry, porque uma tela que muda de tamanho expõe todas de uma vez).¹⁵

Vale ler mesmo que você nunca a rode, porque é o checklist de revisão da Apple posto no papel. Ela verifica três configurações do projeto e não muda nenhuma (uma chave de tela de lançamento, a declaração de orientação do iPad, UIRequiresFullScreen), e depois caça cinco padrões: UIScreen.main, layout decidido pela orientação da interface, layout decidido por userInterfaceIdiom, ciclo de vida de aplicação onde cabe o ciclo de vida de cena, e código de área segura que presume que os dois lados são iguais. O arquivo de área segura tem a linha que explica metade do que dá errado neste celular: “Asymmetric horizontal insets are the normal case. Where a vertical bar is present, one horizontal edge usually carries the whole inset and the other carries zero.” (insets horizontais assimétricos são o caso normal; onde há uma barra vertical, uma borda horizontal costuma levar todo o inset e a outra, zero).¹⁵

O Kiradex é um app SwiftUI escrito este ano, e essas cinco buscas não encontram nada nele.¹³ Cada achado acima veio de rodá-lo. Esse é o limite da metade estática: ela lê o código-fonte, e a dobra, o trilho e o teclado só são visíveis numa tela.

A outra metade é um percurso que o agente consegue rodar e olhar. O que tornou possível a auditoria acima foram três peças pequenas, e nenhuma delas é específica deste app:

1. Um teste de UI que visita cada tipo de tela e para em cada uma. Sem asserções; um roteiro. O nosso abre o Dex, uma coleção, uma carta, uma sheet, a lista da coleção, uma carta da coleção, o visualizador em tela cheia e a busca com o teclado aberto: oito paradas.¹³
2. Uma captura que acontece no Mac, não no teste. A captura feita pelo próprio teste de UI é de uma tela só. O simctl alcança as duas:

xcrun simctl io "$UDID" screenshot --type=png --display=primary   outer.png
xcrun simctl io "$UDID" screenshot --type=png --display=primary-1 inner.png

O teste grava um arquivo vazio com o nome da parada; um loop de shell no Mac o vê, captura as duas telas e responde com um segundo arquivo; o teste espera por ele e segue em frente. A captura externa tem 1398 por 2034 pixels com o celular fechado e a interna 2853 por 2007 com ele aberto, então as imagens da auditoria e as capturas da loja saem da mesma execução.⁹¹³ 3. Um jeito de mudar a pose sem pôr a mão no mouse. O simctl não tem comando de pose e os frameworks de teste de UI deste beta não têm nenhuma chamada de dobradiça que eu tenha encontrado, então o script aperta os botões Closed, Book, Open e Rotate Right do Device Hub pela API de acessibilidade, o que funciona com o Device Hub em segundo plano.¹³

Com isso, conferir o app em cada pose deixa de ser um pedido de opinião ao agente e vira uma pasta de imagens por pose que ele, e você, podem ler. O briefing abaixo é o que eu entregaria; ele está em inglês porque foi escrito para ser colado direto num agente de programação.

Goal: make this app correct on iPhone Duo in every pose, without device checks.

0. Toolchain. Build with Xcode 27.1 beta. Confirm the binary is stamped with the 27.1 SDK:
   otool -l <App>.app/<App> | grep -A4 LC_BUILD_VERSION      (debug builds: <App>.debug.dylib)
   If "sdk" is lower than 27.1, stop: nothing below will reproduce.

1. Static pass. Report every use, with file and line, of:
   UIScreen.main / UIScreen.mainScreen; userInterfaceIdiom; interface orientation used for layout;
   a UIApplicationDelegate doing scene work; one safe-area inset applied to both sides;
   a bare ignoresSafeArea() on anything a person reads or taps; fixed widths tied to a phone size;
   toolbars or tab bars built by hand instead of owned by NavigationStack, NavigationSplitView or TabView;
   toolbar items with a title and no symbol, or a symbol and no title.
   Confirm Info.plist has a launch screen key and no orientation lock the design does not need.

2. Walk. Run the screenshot tour in each pose and capture BOTH displays at every stop:
   closed; closed and turned; open; open and turned; partly folded; partly folded and turned.
   If no tour exists, write a UI test that stops at each kind of screen and signals a host script, and have
   the script capture with:  xcrun simctl io <udid> screenshot --display=primary     (outer)
                             xcrun simctl io <udid> screenshot --display=primary-1   (inner)
   Poses are buttons in Device Hub (Closed, Book, Open, Rotate Right); simctl has no pose command.

3. Read every capture and answer, per pose:
   - Are the bars where the system puts them (down the side closed and in open landscape, across the top
     and bottom in open portrait)? Is any toolbar item missing from the bar and from the overflow menu?
   - Does any sheet reserve the side rail and leave it empty?
   - With the keyboard up, what is covered? Can every tab still be reached once it is dismissed?
   - Does anything sit under the outer camera corner or the status column?
   - Open: does a grid have an even number of columns? Does any control or line of text cross the middle?
   - Partly folded: does content move off the fold? Do sheets and alerts land on one side?
   - Turned: did a two-pane layout stack when it should have stayed side by side, or the reverse?
   - Is the same selection, scroll position and navigation path still there after the pose changed?

4. Fix with, in this order: a system container that already adapts; size classes; ArrangementView for a
   custom two-pane layout; reservedRegions for hand-placed content. Never branch on the device model,
   the idiom, the orientation, or the raw hinge angle to decide layout.

5. Guard everything from the 27.1 SDK with `if #available(iOS 27.1, *)` and a fallback that keeps both
   panes reachable. If the same source must also build with Xcode 27.0, fence it at compile time.

6. Report what could not be checked in the simulator: cameras, StandBy, extensions, haptics, real reach.

O material da Apple, na ordem em que eu usaria

Tudo o que a Apple publicou para este aparelho sai de uma única página, Get ready for iPhone Duo.¹⁹ Em ordem de trabalho:

Não li o resumo de perguntas e respostas dos Group Labs nem os tópicos do fórum: as páginas do fórum da Apple respondem a uma busca automatizada com uma página de verificação humana, e eu não a contornei.

Pontos principais

• Se você já publica um app: solte agora o trabalho de redimensionamento, compilado com o Xcode 27. É o que os seus clientes terão num Duo em 23 de outubro se a loja ainda estiver fechada para o SDK 27.1 nesse dia, e nada disso precisa do beta.
• Se você está adotando as APIs do Duo: compile com o Xcode 27.1 beta, confirme sdk 27.1 ou posterior com o otool, mantenha o build no TestFlight e cerque as chamadas exclusivas do 27.1 se o mesmo código ainda precisar compilar para a loja.
• Se você está testando: não leia o código, rode as poses. Fechado, aberto, parcialmente dobrado, cada um deles girado, uma sheet, o teclado, uma view em tela cheia e uma tela aberta no momento em que o celular se desdobra. Capture as duas telas toda vez.
• Se você está montando a página da loja: capture agora nos tamanhos do Duo, monte por script, use as molduras da Apple de frente e mantenha uma versão pronta para o dia em que os espaços abrirem.
• Se você vai entregar isto a um agente: dê a ele o percurso, não só os arquivos. A skill App Resizability da Apple cobre o que dá para encontrar lendo; tudo nos achados acima foi encontrado olhando.

Perguntas frequentes

Meu app atual roda no iPhone Duo sem mudanças?

Sim. A palestra da Apple promete isso para qualquer SDK, e o simulador confirma: um build carimbado com o SDK do iOS 26 rodou como uma janela de 375 por 667 pontos, e um carimbado com 27.0 preencheu a tela ao lado do trilho de status, com barras horizontais. Nenhum dos dois recebe barras verticais nem regiões reservadas.³¹²

De qual Xcode eu preciso para o layout completo do iPhone Duo?

O Xcode 27.1 beta (27A9269), que traz o SDK do iOS 27.1 e o único simulador do iPhone Duo. O runtime de simulador 27.1 dele suporta só o tipo de dispositivo iPhone Duo, então os outros iPhones são testados no runtime 27.0. O SDK do Xcode 27.2 beta tem as mesmas APIs, e uma sonda carimbada com 27.2 se comportou como 27.1 no simulador, mas esse Xcode não tem um Duo para rodá-la.⁸¹²¹⁴

Posso enviar hoje um build para o iPhone Duo à App Store?

Não um compilado com o SDK 27.1, em 2 de outubro de 2026. O App Store Connect aceita builds dos betas do Xcode 27.1 e 27.2 para testes internos e externos no TestFlight, e builds do Xcode 27 para a loja. A Apple não pôs data na mudança.⁸

Quais tamanhos de captura de tela o App Store Connect pede para o iPhone Duo?

1398 por 2034 ou 2034 por 1398 pixels para a tela externa, e 2007 por 2853 ou 2853 por 2007 para a tela interna, de uma a dez imagens sem canal alfa. O upload aparece como previsto para “later this year” (ainda este ano).⁹

Como capturo as duas telas do simulador do iPhone Duo?

xcrun simctl io <udid> screenshot --display=primary para a tela externa e --display=primary-1 para a interna. A captura feita pelo próprio teste de UI cobre uma tela só.¹³

Por que as barras do meu app continuam horizontais no simulador do iPhone Duo?

Três causas, na ordem em que vale conferir. O binário não está carimbado com o SDK 27.1. As barras são feitas à mão em vez de pertencerem a um TabView, NavigationStack ou NavigationSplitView. Ou a tela interna está em retrato, onde a Apple mantém as barras horizontais de propósito.²⁷¹²

Preciso de um layout para cada pose?

Não. A orientação da Apple são dois layouts, largura compacta e largura regular, mais uma resposta à dobra onde o conteúdo a cruzaria. O Kiradex tem esses dois e uma visão de arranjo; a pose Book não precisou de código.⁷¹³

Relacionados neste site: o post sobre o simulador tem os passos de instalação, o perfil do aparelho e as medições por pose corrigidas; design para o iPhone Duo lê as diretrizes de design da Apple como regras; o post sobre o Duo para desenvolvedores tem os números do hardware e o histórico com datas; o post sobre capturas de tela defende o que um conjunto deve dizer; o checklist do iPhone redimensionável é o trabalho do Xcode 27 que este post manda publicar primeiro; e o hub do Xcode 27 acompanha a toolchain.

Fontes