Prepara tu app para el iPhone Duo: un ejemplo práctico

¿Cómo se prepara una app para el iPhone Duo? Compílala con el SDK de iOS 27.1, recórrela por cada pose en el simulador, corrige lo que muestre ese recorrido y organiza el envío alrededor de dos fechas que Apple todavía no ha anunciado. El iPhone Duo sale a la venta el 23 de octubre con iOS 27.1.¹ Lo que una app recibe en él lo decide la versión del SDK sellada en su binario: un mismo archivo fuente enlazado como 26.0, 27.0 y 27.1 apareció como una caja del tamaño de un teléfono, como una ventana junto a la franja de estado y como la pantalla completa con sus barras en el costado y el pliegue reportado.¹² Al 2 de octubre solo las betas de Apple sellan 27.1 o posterior (Xcode 27.1 beta, que trae el simulador del Duo, y Xcode 27.2 beta), y App Store Connect acepta sus builds para TestFlight, no para la tienda.⁸ Este post hace el trabajo completo sobre Kiradex, una app para coleccionistas de cartas que tenemos en TestFlight: lo que vino gratis, lo que el recorrido detectó y la lectura del código no, las capturas para las dos pantallas y un brief que puedes pasarle a un agente de programación.

TL;DR

• El sello del SDK es el interruptor. iOS lee la versión del SDK en el LC_BUILD_VERSION del binario. Sellada con 27.1, la sonda recibió la pantalla completa, 466 por 678 puntos cerrada y 951 por 669 abierta, con barras verticales y regiones reservadas. Sellada con 27.0, se quedó 80 puntos antes del borde donde está la franja de estado, mantuvo las barras horizontales y el sistema no le dijo nada del pliegue. Sellada con 26.0, fue un teléfono de 375 por 667 dentro de una caja. Revisa la tuya con otool -l.¹²
• El calendario tiene dos fechas abiertas. TestFlight acepta builds con el SDK 27.1 desde el 18 de septiembre y builds de la beta 27.2 desde el 16 de septiembre; la App Store solo acepta builds con el SDK 27.0; los tamaños de captura del Duo están publicados y subirlas “will be available later this year” (estará disponible más adelante este año).⁸⁹ Ahora además se exige una clave de pantalla de lanzamiento al subir la build.¹⁰
• Los contenedores del sistema hicieron casi todo. Un TabView, un NavigationStack en cuatro de sus cinco pestañas y elementos de barra de herramientas con título y símbolo pusieron las barras de Kiradex en el costado sin una sola línea de código específica del Duo. Un único ArrangementView dividió la pantalla abierta y llevó su divisor al pliegue en la pose Book. Un único onHingeChange repite la apertura de la app cuando el teléfono se despliega.¹³
• El recorrido detectó lo que la lectura no. Una hoja cuyo único botón es un “Done” de texto reserva la franja lateral y la deja vacía. La carta a pantalla completa pasa por debajo de la cámara exterior. Girada a vertical, la división se apila. Una carta abierta mientras se despliega el teléfono cae en el diseño compacto, estirado. El diseño de ancho regular, escrito para la pantalla interior, se rompe en un iPhone de 6,9 pulgadas en horizontal.¹³
• Mientras la tienda no acepte 27.1, un mismo árbol de código necesita dos Xcode. #available no sirve; el SDK 27.0 no tiene ningún ArrangementView contra el que compilar. Una condición de compilación, o #if canImport(SwiftUI, _version: 8.0.85), encierra las llamadas nuevas.¹⁴
• Las capturas salen de la misma ejecución. Las capturas del simulador tienen exactamente los tamaños de App Store Connect, y también las aberturas de los marcos del Duo que publica Apple. Las reglas de Apple siguen pidiendo vista frontal, sin modificaciones y sin renders 3D del dispositivo.⁹¹¹

Dónde están las cosas al 2 de octubre

Tres de esas filas esperan a Apple, y ninguna bloquea el trabajo. El orden que se desprende de la tabla: llevar la app al SDK 27.1 y al simulador, recorrerla por cada pose, corregir lo que muestre el recorrido, poner esa build en TestFlight y tener listos el envío a la tienda y las capturas del Duo para el día en que se abra cada cosa.

El punto de partida de la propia Apple es la primera de sus seis Tech Talks, de diez minutos, y todo lo que sigue la da por vista:

Paso uno: el sello del SDK decide lo que te da el teléfono

La charla abre con una promesa de compatibilidad en tres niveles. Una app que no se compiló con el SDK de iOS 27 sigue 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) (con el dispositivo cerrado, la app usa el espacio a la izquierda de la barra de estado y la cámara; abierto, tiene un tamaño y una proporción conocidos). Una app que adoptó el SDK de iOS 27 “will extend to the left of the status bar area on the inner display.” (0:58) (se extiende hasta la izquierda del área de la barra de estado en la pantalla interior). Y luego: “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) (compilada con el SDK de iOS 27.1, la app llega hasta el borde de la pantalla y los botones estándar de navegación y de barra de herramientas se colocan en vertical bajo la barra de estado).³

Esos niveles no son una propiedad de tu código. Son una propiedad de un solo número en tu binario, la versión del SDK que el enlazador registra en el comando de carga LC_BUILD_VERSION, y iOS lo lee al iniciar la app. Para ver cuánto depende de él construí una sonda pequeña, un TabView con un NavigationStack que tiene una barra de herramientas de cinco elementos y un ArrangementView, tres veces a partir del mismo archivo fuente. La única diferencia entre los tres binarios es ese número: 26.0, 27.0, 27.1. Después ejecuté los tres en el simulador del iPhone Duo en cada pose.¹²

Un archivo fuente, tres sellos de SDK, abierto y en posición vertical. De izquierda a derecha: 26.0, 27.0, 27.1.

Los tamaños de ventana están en puntos, tal como los reportó la ventana de cada build.¹²

Lee la columna del medio dos veces, porque es la que la mayoría de las apps está a punto de publicar. Una build de Xcode 27 recibe ancho regular en la pantalla interior y casi toda la pantalla, una mejora real frente al teléfono dentro de una caja de la primera columna. Se queda 80 puntos antes del borde final, donde está la franja de estado, no recibe barras verticales y el sistema no le dice nada del pliegue ni de las cámaras: todas las consultas de regiones reservadas volvieron vacías, en cada pose, por muchas veces que preguntara la sonda.¹² Para asegurarme de que el sello era un sustituto justo, también compilé una versión simple de la sonda con el propio Xcode 27.0, contra su propio SDK de iOS 27.0. Recibió las mismas ventanas: 386 por 678 cerrada, 871 por 669 abierta.¹²

La guía escrita de Apple es menos precisa en este punto que la charla, y su redacción cambió. El 17 de septiembre su resumen decía “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.” (compila con Xcode 27.1 o posterior para usar todo el espacio de pantalla; en versiones anteriores la app no se extiende bajo la barra de estado y la cámara). Para el 19 de septiembre decía, como dice al 2 de octubre, “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.” (compila con la versión más reciente de Xcode; si compilas con Xcode 26 o anterior, la app no se extiende bajo la barra de estado y la cámara).² La frase nueva solo nombra Xcode 26 y anteriores como insuficientes, y “latest version” no aclara si una beta cuenta, así que un lector podría entender que una build de Xcode 27.0 recibe la pantalla completa. En el simulador de esta beta no la recibe. Recibe el nivel intermedio de la charla, y la redacción anterior coincidía con lo que medí. Hasta que el hardware diga otra cosa, planifica según la tabla.

Así que, antes que nada, revisa el sello de la build que estás probando:

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

Una build de depuración de Xcode guarda su código en YourApp.debug.dylib junto a un pequeño lanzador, y ambos llevan el comando. Lo que buscas es sdk 27.1 o posterior; la sonda sellada con 27.2, que es lo que escribiría el SDK de Xcode 27.2 beta, recibió el mismo trato que 27.1.¹² El de Kiradex dice minos 27.0 y sdk 27.1: se instala en iOS 27.0 y recibe el comportamiento de 27.1 en un Duo.¹³

Insisto en esto porque me equivoqué en público. Mi primer informe sobre este simulador, del 21 de septiembre, decía que la barra de herramientas nunca se ponía vertical y que las regiones reservadas estaban vacías en todas las poses. La beta estaba bien. Yo había compilado aquella sonda llamando a swiftc -sdk directamente, el paso de enlace tomó como raíz el SDK de macOS de ese mismo Xcode y el binario salió sellado con 27.0: todo lo que medí ese día era la columna del medio. Ese post ahora lleva la corrección.¹² Si tu diseño para el Duo se ve adoptado a medias en el simulador, con barras arriba y una franja negra muerta en el costado, revisa el sello antes de revisar tu código.

La app en el banco de pruebas

Kiradex es una app para coleccionistas de cartas coleccionables que tenemos en TestFlight: cada set, las cartas que tienes y las que quieres, cuánto valen a lo largo del tiempo y cada carta como un objeto 3D al que puedes darle la vuelta. Es gratis, solo para iPhone, funciona en iOS 27.0 y posterior, y guarda las listas de cada coleccionista en su propio iCloud, sin ningún servidor nuestro de por medio.¹³ No está terminada. El escáner nunca ha visto una cámara real y, hasta esta semana, nadie había mirado la app en un Duo abierto: junto al diseño de la pantalla interior, su hoja de ruta llevaba la línea “Seen on the open Duo’s inner display only by the column maths; the simulator was folded shut.” (en la pantalla interior del Duo abierto solo se había visto mediante el cálculo de columnas; el simulador estaba cerrado).¹³ Eso la convierte en una prueba justa. El trabajo para el Duo que contiene se escribió a partir de la documentación de Apple y nunca se contrastó con una pantalla.

Lo que hace para el Duo es poco, y vale la pena enumerarlo justamente por lo poco que es código del Duo:

• La navegación es la del sistema. Un TabView con cinco pestañas, una de ellas con el rol de búsqueda, y un NavigationStack en cuatro de ellas; el escáner es una vista de cámara sin barra propia. Los elementos de la barra de herramientas son Label con título y símbolo, agregados con .toolbar. No hay ninguna barra personalizada en ninguna parte.
• El diseño sigue a la clase de tamaño. El ancho compacto recibe una página de carpeta de tres columnas y empuja el inspector de una carta a la pila. El ancho regular, que en una app solo para iPhone significa casi siempre la pantalla interior del Duo, recibe un muro de cartas en un número par de columnas; al elegir una, la pantalla se divide entre la página y el inspector.
• Dos llamadas del SDK 27.1. La división es un ArrangementView con el estilo .split, con un HStack como alternativa por debajo de iOS 27.1. Y onHingeChange repite la animación de apertura de la app, un dispositivo rojo que se abre, cuando el teléfono pasa de cerrado a cualquier otra cosa.
• Sin bloqueo de orientación, y con pantalla de lanzamiento. Info.plist lista la orientación vertical y las dos horizontales y declara UILaunchScreen.¹³

Esa es la lista completa: dos comprobaciones de disponibilidad en dos archivos. Todo lo demás que el teléfono le hace a la app se lo hace a cualquier app construida de esta manera.

Las imágenes de este post muestran la app tal como funciona, con imágenes de cartas del catálogo público que consulta. Kiradex es una herramienta independiente para coleccionistas, sin afiliación ni respaldo de Nintendo, Creatures Inc., GAME FREAK inc. ni The Pokémon Company, y las imágenes de las cartas pertenecen a sus dueños.

Paso dos: recorre cada pose

La guía de Apple plantea el recorrido como cuatro comprobaciones:²

• “Confirm your views resize well in each supported orientation and pose.” (confirma que tus vistas se redimensionan bien en cada orientación y pose admitidas).
• “Inspect how the system presents your app’s navigation bars, toolbars, and tab bars vertically on the side of the display.” (revisa cómo presenta el sistema en vertical, en el costado de la pantalla, las barras de navegación, de herramientas y de pestañas de tu app).
• “Identify any views, sheets, or popovers that position awkwardly when you fold or open iPhone Duo.” (identifica vistas, hojas o popovers que quedan mal ubicados al plegar o abrir el iPhone Duo).
• “Identify elements or controls in your views that appear in the fold, and are difficult to see or interact with.” (identifica elementos o controles que caen en el pliegue y cuesta ver o usar).

Su guía de diseño dice cuántos diseños debería hacer falta: “A compact width layout for the outer display and a regular width layout for the inner display give you the fundamentals for every pose.” (un diseño de ancho compacto para la pantalla exterior y uno de ancho regular para la interior te dan lo fundamental para todas las poses).⁷

Las poses son botones en Device Hub: Closed, Book, Open y Rotate Right, y cada combinación es una pantalla distinta. La guía de SwiftLee agrega un control más fino que no necesité: “Holding Option ⌥ reveals a slider that you can use to control the hinge angle of the device with precision” (si mantienes presionada Opción ⌥ aparece un control deslizante para ajustar con precisión el ángulo de la bisagra).¹⁷ Antes de mirar la app, conviene saber qué le entrega el sistema a cualquier app en cada pose. Estas son las lecturas de la sonda con el sello 27.1:¹²

Tres cosas de esa tabla marcaron todo lo que vino después.

La ventana no cambia cuando el teléfono se pliega. Book y Open reportan el mismo tamaño. La única diferencia que la app puede ver es que la división del pliegue pasa de inactiva a activa, y que la bisagra reporta semiabierta a 127 grados donde antes reportaba totalmente abierta a 180. Una app que solo lee su tamaño nunca se entera de que el teléfono se plegó.

El pliegue siempre está ahí, y es pequeño. Se reporta abierto o plegado, justo en el centro, y el marco que devuelve la API mide 40 puntos de ancho en los dos estados, con 20 puntos de margen a cada lado. La charla de Apple dice sobre la región del pliegue: “When flat, it’s inactive and has a width of zero.” (7:32) (en plano está inactiva y tiene ancho cero). El simulador no devuelve un marco de ancho cero. Las notas de campo de Artem Novichkov describen la misma lectura como “40 pt wide, with 20 pt margins on each side of a zero-width fold line,” (40 pt de ancho, con márgenes de 20 pt a cada lado de una línea de pliegue de ancho cero)¹⁷ y yo interpreto el cero de la charla igual, como la línea entre los márgenes; eso es una lectura mía, no algo que diga el texto de Apple. La charla también hace el apunte práctico: “By default, only active ones will be returned, but you can query for inactive ones” (por defecto solo se devuelven las activas, pero puedes consultar las inactivas) y “in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state.” (en diseños tipo cuadrícula, conviene preferir un número par de columnas cuando hay una región de división, esté activa o no) (7:16, 7:41)⁵

Las regiones llegan tarde. En cada arranque, las primeras evaluaciones de la sonda no leyeron ninguna región, y todas las evaluaciones posteriores leyeron el conjunto completo. Una vista que pregunta una sola vez, en su primera pasada de diseño, guarda en caché un arreglo vacío. Léelas en el body de la vista, en cada evaluación; la sonda se reevaluaba con un temporizador de un segundo, y las notas de Artem Novichkov dan la regla sin rodeos: “Read them in the GeometryReader body so the view updates when they arrive. Don’t cache them.” (léelas en el body del GeometryReader para que la vista se actualice cuando lleguen; no las guardes en caché).¹²¹⁷

Un apunte práctico antes de pasar a la app. El runtime del simulador de iOS 27.1 de esta beta admite exactamente un tipo de dispositivo, el iPhone Duo; pedirle un iPhone 18 Pro Max falla con “Incompatible device”. Así que la comparación de abajo, la misma build en un iPhone común, se ejecutó en el runtime de iOS 27.0, que además es una forma rápida de confirmar que las alternativas de #available funcionan.¹²

Una build de Kiradex en un iPhone de 6,9 pulgadas, en el Duo cerrado y en el Duo abierto. Nada en el código de la app pone las barras en el costado.

Lo que encontró el recorrido

Una prueba de UI recorrió la build 5 por ocho tipos de pantalla en cada una de seis poses (siete con el teléfono cerrado y girado, donde el botón de Ajustes había pasado al menú de más opciones) mientras un script capturaba las dos pantallas en cada parada: 1398 por 2034 píxeles por fuera, 2853 por 2007 por dentro, los tamaños que lista App Store Connect.¹³ Contrastada con las cuatro comprobaciones de Apple, la app pasó más de lo que esperaba y falló en sitios que ninguna lectura del código había señalado.

Lo que vino gratis

Las barras. Cerrado, la barra de herramientas y las cinco pestañas se ubican en la franja bajo el reloj; abierto, igual; abierto y girado, vuelven arriba y abajo. Nada en la app pide nada de esto. La segunda charla explica por qué las barras hechas a mano se quedan atrás: “When used to build custom bars, content from sub-components like UIToolbar, UINavigationBar, or UITabBar won’t be considered.” (2:52) (si se usan para construir barras personalizadas, el contenido de subcomponentes como UIToolbar, UINavigationBar o UITabBar no se tiene en cuenta).⁴ Y como cada elemento de la barra de herramientas de las pantallas principales es un Label, cada uno tiene un símbolo para la franja y un título para el menú de más opciones, que es la otra condición de la guía: “If your item has a title and doesn’t have an icon, the system doesn’t present it vertically.” (si tu elemento tiene título y no tiene icono, el sistema no lo presenta en vertical).²

El pliegue. Abierto, las cartas de un set se muestran de seis en seis, un número par, así que ninguna carta queda en el centro de la pantalla. Elige una y la pantalla se divide entre la página y el inspector de la carta en el centro del área de contenido de la app, x 433. Eso está 42 puntos a la izquierda del pliegue, porque la franja le quita 84 puntos al lado derecho, y mientras el teléfono está plano no importa. En la pose Book, la vista de disposición lleva el divisor al pliegue y deja vacía la banda de 40 puntos: el inspector que empezaba en x 433 ahora empieza en 495. La app no tiene ningún código para la pose Book; esto es ArrangementView haciendo lo que describe la charla, “moving, resizing, or reorganizing what’s already there.” (6:04) (mover, redimensionar o reorganizar lo que ya está ahí).⁵¹³

Abierto y plano, y luego en la pose Book. El hueco de la segunda imagen es el pliegue, y no lo puso la app.

Las hojas, con el teléfono abierto. En la pantalla interior, una hoja aparece centrada y su botón Done se queda horizontal; en la pose Book, la hoja de la sonda se movió sola al lado inicial del pliegue.¹²

La bisagra, como evento. Despliega el teléfono con la app en marcha y su apertura vuelve a reproducirse en la pantalla interior: el dispositivo rojo, cerrado, y luego abriéndose hasta dar paso a la app. Eso es un solo manejador onHingeChange que se dispara cuando el estado deja de ser closed, y es justo el reparto de tareas que pide la cuarta charla: “Hinge data is observed live, and is ideal for driving interactions or effects. For layout, use the arrangement and region APIs.” (2:34) (los datos de la bisagra se observan en vivo y son ideales para interacciones o efectos; para el diseño, usa las API de disposición y de regiones).⁶

Desplegando con la app en marcha: la apertura es el propio dispositivo de la app, dibujado por la app y repetido por la bisagra.

Lo que se le escapó

Una hoja con un solo botón de texto reserva la franja y la deja vacía. Cerrado, la hoja de Ajustes cede una tira a lo largo de su borde final para una barra vertical y luego no pone nada en ella: el único elemento de la barra de herramientas es un “Done” con título y sin símbolo, y un elemento solo de texto se queda horizontal. El formulario se aprieta en lo que queda. La sonda midió el costo: 374 puntos de ancho de contenido con la franja reservada, 450 con la barra vertical desactivada.¹² La charla de Apple nombra este 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) (si una hoja está llena de controles y tiene un solo elemento, como el botón de cerrar, considera desactivar la barra vertical para no reducir el espacio disponible).⁴ Hay dos arreglos, y la sonda probó los dos. Dale un símbolo al botón, Button("Done", systemImage: "checkmark"), y pasa a la franja como una marca de verificación destacada; o agrega .toolbarVerticalBehavior(.disabled) al contenido de la hoja y la franja desaparece, a cambio de una hoja más baja.

De izquierda a derecha: la hoja de la app y luego la sonda con un Done solo de texto, con un símbolo y con la barra vertical desactivada.

La carta a pantalla completa pasa por debajo de la cámara. La pieza estrella de la app es una carta sobre un escenario negro con las barras ocultas, y ese escenario ignora el área segura en todos los bordes. En la pantalla exterior eso manda la esquina superior de la carta debajo de la cámara. El sistema le reporta esa cámara a cualquier vista que pregunte, como una oclusión activa de 37 puntos por lado, y su posición coincide con el recorte del propio marco de Apple con un margen de punto y medio.¹¹¹² La guía de diseño de Apple permite el tratamiento a todo lo ancho “as long as nothing conflicts with the Dynamic Island or the status bar.” (siempre que nada choque con la Dynamic Island ni con la barra de estado).⁷ El arreglo es mantener el sangrado completo para el fondo negro y meter la carta en sí hacia adentro: o dejar que el escenario respete el área segura superior y final en esta pantalla, o leer reservedRegions(kind: .occlusion) y encuadrar la carta lejos de lo que devuelva.

La captura del visor dentro del marco de Apple para la pantalla exterior. La captura del simulador no tiene ningún agujero; el teléfono sí.

Girada, los dos paneles se apilan. Abierta y girada a vertical, la pantalla mide 669 puntos de ancho y sigue siendo de ancho regular, así que la app sigue dividiéndose. Pero una vista de disposición que llena un espacio más alto que ancho se divide arriba y abajo, según la guía de Apple: “it places the primary view on top and the secondary view below it when the containing view is taller than it is wide.” (pone la vista primaria arriba y la secundaria debajo cuando el contenedor es más alto que ancho).² El resultado es una tira que muestra una fila de cartas y el comienzo de una segunda, encima de un inspector. El propio comentario de la app en esa línea dice que el par “is only useful side by side,” (solo sirve lado a lado) y nada lo hacía cumplir. Limitar el estilo con .split.axes(.horizontal) es el control documentado,¹⁶ con una trampa que la charla deja clara: “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) (si la disposición dividida no puede dividirse en un eje y ese es el eje principal, la vista de disposición muestra una sola vista).⁵ La sonda confirma las dos mitades: llenando la pantalla girada, una división simple se apiló, y la división solo horizontal mostró el panel primario y nada más.¹² Para esta app eso escondería el inspector, así que el arreglo honesto es una decisión, no un modificador: cuando el espacio sea más alto que ancho, empuja el inspector como lo hace el diseño compacto.

Girada: barras horizontales, como dice la guía de Apple, y una división que fue en la dirección equivocada para este par de vistas.

Una carta abierta mientras se despliega el teléfono no cae en ninguno de los dos diseños. Cerrado, elegir una carta empuja su inspector a la pila de navegación. Despliega con ese inspector a la vista y la carta sigue ahí, que es la parte fácil de hacer mal. Pero sigue siendo una pantalla empujada, ahora de 951 puntos de ancho: el escenario a la izquierda, los detalles en un recuadro blanco a la deriva sobre negro y un botón Back en la franja. El diseño de la app para esta pantalla es el muro con la carta al lado, y la única forma de llegar a él es volver atrás y elegir la carta otra vez. Una sola selección gobierna los dos diseños; un solo camino de navegación no. El arreglo es detectar el cambio de ancho compacto a regular con una carta seleccionada y sacar la pantalla empujada de la pila, para que tome el control la división.

La misma carta antes y después de desplegar. El estado sobrevivió; el diseño es el compacto, estirado.

Ancho regular no es “el Duo”. La app trata el ancho regular como la pantalla interior: muro, columnas pares, división. Un iPhone de 6,9 pulgadas de costado también es de ancho regular, con alto compacto, y la app no bloquea la orientación. Ahí, la misma rama produce una página separada del borde izquierdo, un inspector cuya columna de detalles es demasiado angosta para el nombre de la carta y botones de acción cortados en el borde inferior de la pantalla. Nada de eso es nuevo en iOS 27, y no apareció en ninguna pose del Duo que probé; el trabajo para el Duo lo encontró porque fue la primera vez que alguien recorrió el diseño de ancho regular en cada pantalla que lo reporta. La comprobación que separa los dos casos es la otra clase de tamaño: la pantalla interior es regular en ambas, y la charla de Apple da la pantalla exterior de costado como compacta en ambas.³ Un diseño que necesita espacio en dos direcciones debería pedir las dos.

El diseño de ancho regular en un teléfono que no es un Duo: un iPhone de 6,9 pulgadas de costado, iOS 27.0.

El teclado tapa la franja. Con el teclado arriba en la pantalla exterior, las pestañas de la parte baja de la franja quedan detrás de él. Es el diseño del sistema, no un defecto; la charla dice que la barra puede tener que desbordarse “as other competing UI appears, like the keyboard” (a medida que aparece otra interfaz que compite por el espacio, como el teclado) (11:50).⁴ Está en esta lista porque rompió las herramientas: mi primer recorrido tocó “Collection” con el teclado de búsqueda arriba y el toque cayó en la letra P. Las pruebas de UI que dan por hecho que siempre se puede alcanzar una barra de pestañas fallan aquí primero.

Dos cosas menores. La app elige columnas pares a partir de la clase de tamaño de ancho, cuando la sugerencia de la charla es la propia región del pliegue, esté presente o no. Y una que no tiene nada que ver con plegar: abierto cuatro veces seguidas en el simulador de 6,9 pulgadas, el visor a pantalla completa mostró la carta la primera vez y una pantalla negra vacía las tres siguientes. Ninguna de las dos frena una build de TestFlight. Las dos eran invisibles hasta que la app estuvo en una pantalla y algo fue presionando sus botones en orden.

Lo que el simulador no podía mostrar

El escáner. Abre la cámara gran angular trasera y ya usa un coordinador de rotación, que es lo que pide la charla sobre la cámara: “On iPhone Duo, the rotation coordinator will update when your app moves displays.” (8:19) (en el iPhone Duo, el coordinador de rotación se actualiza cuando la app cambia de pantalla).⁶ Si la sesión sobrevive al paso de una pantalla a la otra es una pregunta para el hardware; el simulador no tiene ninguna cámara. Las notas de la versión de Apple suman StandBy y la mayoría de las extensiones de app a lo que este runtime no puede ejecutar, y las notas de Xcode 27.2 beta 2 agregan una para quien automatice capturas: “Screenshots and recordings in iPhone Duo may be black for up to a few minutes after booting the device.” (las capturas y grabaciones del iPhone Duo pueden salir en negro durante unos minutos después de arrancar el dispositivo).²⁰

Un árbol de código, dos Xcode

El calendario crea un problema. La build que acepta la tienda sale de Xcode 27 y el SDK 27.0; la build que se comporta bien en el iPhone Duo sale del SDK 27.1. Hasta que Apple abra la tienda a la segunda, una app que quiera publicar una actualización y seguir trabajando en su diseño para el Duo tiene que compilar con los dos.

if #available(iOS 27.1, *) no te lleva hasta ahí. La disponibilidad es una pregunta de tiempo de ejecución; el compilador igual tiene que encontrar el símbolo. Kiradex envuelve sus dos llamadas del Duo exactamente así, y su destino de despliegue es 27.0, de modo que la build se instala en un teléfono que no se ha actualizado. Con el SDK 27.1 eso compila. Con Xcode 27.0, un archivo que hace lo mismo se detiene en error: cannot find 'ArrangementView' in scope, porque el SDK 27.0 no tiene ese tipo.¹⁴ Kiradex todavía no está en la tienda, así que puede quedarse sin más en la cadena de herramientas beta; una app con clientes no puede.

Las condiciones documentadas de Swift tampoco distinguen los dos SDK. #if compiler(>=6.4) es verdadero en los dos: Xcode 27.0, Xcode 27.1 beta y Xcode 27.2 beta imprimen todos el mismo Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1).¹⁴ Eso deja dos barreras, y probé las dos.

Una condición de compilación que defines tú. Esta es la vía documentada. Define una bandera solo en la configuración que compilas con la beta (en Xcode, SWIFT_ACTIVE_COMPILATION_CONDITIONS = DUO_SDK; en la línea de comandos, -D DUO_SDK) y encierra con ella el código exclusivo de 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
    }
}

Sin la bandera, ese archivo pasa la verificación de tipos con Xcode 27.0 y con la beta 27.1. Con la bandera la pasa con la beta y falla con 27.0 con el mismo error de símbolo faltante: la combinación equivocada no compila.¹⁴

La versión del propio SDK, leída por el compilador. canImport acepta un segundo argumento con guion bajo que compara contra la versión de un módulo, y la versión del módulo SwiftUI cambia de un SDK a otro: 8.0.84.1.104 en el SDK 27.0, 8.0.85.27 en el SDK 27.1, 8.1.6.1.101 en el SDK de la beta 27.2.¹⁴ Así que esto no necesita ningún ajuste de compilación:

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

Puse un #warning en cada rama y lo compilé con los tres Xcode: 27.0 tomó la segunda rama, y la beta 27.1 y la beta 27.2 tomaron la primera.¹⁴ La advertencia está en el guion bajo. La gramática de este condicional en el libro de Swift es canImport(import-path) y nada más, así que _version: es una función del compilador sin un contrato documentado, y el número 8.0.85 es algo que leí de dos SDK, no algo que Apple haya publicado.¹⁴ Úsalo mientras la tienda esté cerrada a 27.1 si un ajuste de compilación es incómodo en tu configuración; usa la bandera si quieres algo que puedas defender.

En cualquier caso, la barrera es temporal. El día que App Store Connect acepte builds de un Xcode que traiga el SDK 27.1, bórrala y quédate con las comprobaciones #available, que son las que protegen a un teléfono que sigue en iOS 27.0.

El envío: lo que App Store Connect acepta hoy

TestFlight acepta la build 27.1. Las notas de la versión de App Store Connect del 18 de septiembre: “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.” (ya puedes enviar apps compiladas con Xcode 27.1 beta usando el SDK de iOS 27.1 beta o de iPadOS 27.1 beta para pruebas internas y externas). Las entradas del 16 y del 28 de septiembre dicen lo mismo para Xcode 27.2 beta y beta 2.⁸ Kiradex sube por esta vía; su quinta build, la que prueba este post, se subió el 2 de octubre y App Store Connect la lista como válida.¹³

La App Store, todavía no. La entrada más reciente que abre la tienda es la del 14 de septiembre: “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.” (ya puedes subir apps compiladas con Xcode 27 y los SDK 27.0 para la App Store y para pruebas internas y externas en TestFlight).⁸ Nada posterior menciona 27.1 y la tienda en la misma frase, y el feed de lanzamientos de Apple, cuyos elementos más recientes tienen fecha del 28 de septiembre, lista una sola build de Xcode 27.1, la beta del 18 de septiembre.⁸ Apple no ha dicho cuándo cambia eso. El dispositivo sale a la venta el 23 de octubre.¹

Salvo que Apple abra la tienda al SDK 27.1 antes del 23 de octubre, la build de la tienda que tus clientes tendrán el día del lanzamiento será, como mucho, una build con el SDK 27.0, y la comparación de arriba dice lo que recibe en el simulador, con la charla de Apple describiendo el mismo nivel intermedio: la pantalla junto a la franja de estado, barras horizontales, sin pliegue. Eso es una app usable si se redimensiona bien, y ese es el argumento para publicar ya, con Xcode 27, el trabajo de redimensionamiento.

La pantalla de lanzamiento ahora es obligatoria. No es una regla del Duo, pero llega con el mismo SDK y falla al subir la build, no en la revisión. La nota técnica de 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 de iOS 27 y iPadOS 27, App Store Connect exige que la app incluya una configuración de pantalla de lanzamiento en su Info.plist) y sin una de UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen o UILaunchScreens la subida se rechaza con “ITMS-90870: Missing launch screen.”¹⁰ Kiradex declara UILaunchScreen con un color, el rojo de su portada, así que el arranque desemboca directamente en la animación de apertura.¹³

Los espacios para capturas existen en el papel. Las especificaciones de capturas de App Store Connect listan el iPhone Duo desde el 9 de septiembre, en dos pares: 1398 por 2034 o 2034 por 1398 píxeles para la pantalla exterior, y 2007 por 2853 o 2853 por 2007 para la interior, con la nota “Support for uploading assets for this device in App Store Connect will be available later this year.” (la posibilidad de subir recursos para este dispositivo en App Store Connect estará disponible más adelante este año).⁹ Rigen las reglas de siempre: “You can upload one to 10 screenshots in .jpeg, .jpg, and .png formats,” (puedes subir de una a 10 capturas en formato .jpeg, .jpg y .png) e “Images can’t include alpha channels or transparencies.” (las imágenes no pueden tener canales alfa ni transparencias).⁹

Una frase de la página de subida decide cómo planificar en torno a eso: “Once your app is submitted for review and approved, you must create a new version to update the screenshots.” (una vez que la app se envía a revisión y se aprueba, tienes que crear una versión nueva para actualizar las capturas).⁹ Las capturas del Duo no se pueden colar después por su cuenta; cuando se abran los espacios, viajarán con una versión.

Junto todo, esta es la secuencia que seguiría, y que estoy siguiendo con Kiradex:

1. La build 27.1 en TestFlight desde ya, con los hallazgos del recorrido corregidos a medida que aparecen.
2. Para una app que ya está en la tienda: una actualización compilada con Xcode 27 que incluya cada arreglo que no necesite el SDK 27.1. Clases de tamaño en lugar de comprobaciones de idiom y de orientación, áreas seguras por borde, barras gestionadas por contenedores del sistema, un título y un símbolo en cada elemento de la barra de herramientas.
3. Capturas tomadas desde ya a los tamaños del Duo, desde el simulador, y guardadas.
4. Una versión lista para el día en que se cumplan dos cosas: que la tienda acepte un Xcode con el SDK 27.1 y que los espacios del Duo acepten subidas. Hasta ahora Apple ha publicado cada cambio de este tipo en las notas de la versión de App Store Connect, entre ellos la entrada del 14 de septiembre que abrió la tienda a Xcode 27 y la del 9 de septiembre que agregó las especificaciones de capturas del Duo, así que esa es la página que hay que vigilar, con la página de noticias para desarrolladores al lado.⁸

Hay un requisito más, algo más lejos. A partir de abril de 2027, “iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later” (las apps de iOS y iPadOS deben compilarse con el SDK de iOS 27 y iPadOS 27 o posterior) para poder subirse siquiera.¹⁸ Una app que todavía se compile con un SDK de iOS 26 recibe en un Duo la más pequeña de las tres imágenes de arriba, y a partir de abril de 2027 no podrá subir una actualización hasta pasarse al SDK de iOS 27.

Capturas para dos pantallas

El recorrido ya produjo la materia prima: cada parada se capturó a 1398 por 2034 y 2853 por 2007 píxeles y, girada, a 2034 por 1398 y 2007 por 2853, los cuatro tamaños de la fila del iPhone Duo en App Store Connect.⁹¹³ Lo que queda es decidir qué va alrededor, y ahí es donde un teléfono plegable invita a equivocarse.

La imagen que todos quieren es el teléfono medio abierto, en ángulo, con la app derramándose sobre el pliegue. Las directrices de marketing de Apple la descartan línea por línea. Sobre sus propias imágenes de dispositivos: “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” (usa las imágenes de productos de Apple tal cual, sin modificar: nada de reflejos, sombras, brillos ni elementos que parezcan entrar o salir de la pantalla, nada de recortarlas, inclinarlas, taparlas, animarlas, voltearlas ni girarlas). Sobre las imágenes que hagas tú: “Straight-on product shots are preferred. Don’t use extreme angles or alter an Apple product in any way.” (se prefieren tomas frontales del producto; no uses ángulos extremos ni alteres un producto de Apple de ninguna forma). Y en Unauthorized Uses, la primera de la lista: “Rendering in 3D or creating any simulation of an Apple product” (renderizar en 3D o crear cualquier simulación de un producto de Apple).¹¹ Mi post sobre capturas repasa cómo tratan esas reglas los ganadores de premios y cómo se ve un set que las respeta; nada de una bisagra las cambia.

Lo que Apple te da a cambio es un paquete de marcos (bezels) para este teléfono, en dos acabados y cinco vistas: el teléfono cerrado en vertical y en horizontal, la pantalla interior abierta en horizontal y en vertical, y el teléfono abierto visto desde atrás con la pantalla exterior junto a las cámaras. Las aberturas de esos archivos tienen exactamente los tamaños de las capturas, así que una captura del simulador entra sin escalar.¹¹ No hay ninguna vista semiplegada ni ninguna en ángulo.

Así que los marcos de abajo se construyen con tres piezas: un fondo con los colores de la propia app, una línea corta de texto y la captura dentro del marco de Apple, entera y derecha, sin nada encima. La variedad sale del fondo, del tamaño del dispositivo y de un marco por set sin ningún dispositivo: la carta a pantalla completa de la app sobre negro, que es el 3D de la propia app y no el hardware de nadie.

Tres sets compuestos por script a partir de las capturas del recorrido, a 1320 por 2868, 1398 por 2034 y 2853 por 2007 píxeles. Muestran el método, no la ficha de la tienda: estas capturas llevan cartas del catálogo, y lo que muestre el set de la tienda es la pregunta abierta de la tercera nota de abajo.

Tres notas prácticas de haberlos construido.

Compón por script. Los sets de arriba salen de un solo archivo de Python que toma una captura, un titular y un fondo, y escribe un PNG al tamaño exacto sin canal alfa. Cuando la app cambia, y esta cambió dos veces el día que la capturé, el recorrido vuelve a correr y los marcos se reconstruyen.

Captura lo que agrega el teléfono. La página de subida de Apple dice que basta un set de 6,9 pulgadas cuando la interfaz es igual en todos los tamaños: “provide only the highest resolution screenshots required. They automatically scale down to smaller device sizes.” (entrega solo las capturas de mayor resolución que se piden; se reducen automáticamente para los dispositivos más pequeños).⁹ En este teléfono no es igual: el muro de cartas y el inspector dividido solo existen en la pantalla interior. Esos son los dos marcos con los que abre el set interior.

Cuida lo que hay en la pantalla. Las mismas directrices dicen “You are responsible for securing the rights to all materials used in screen content within your app.” (eres responsable de asegurar los derechos de todo el material que aparece en pantalla dentro de tu app).¹¹ Una app para coleccionistas muestra por naturaleza obras de otras personas, y una ficha de la tienda es marketing, que es algo distinto de lo que la app muestra mientras se usa. No hemos tomado esa decisión para Kiradex, y los marcos de arriba no se enviarán tal como están. Por esa razón, el recorrido tiene un segundo modo que corre con seis cartas inventadas; todavía no tienen ilustraciones, así que un set enviado implica diseñar sustitutos o resolver los derechos.

Kiradex todavía no tiene ficha. Cuando la tenga, empezará con un set de 6,9 pulgadas, y los sets del Duo esperarán, con una versión propia, al día en que App Store Connect los acepte.

Pasarle el trabajo a un agente de programación

La mayor parte de este trabajo es del tipo que un agente hace bien, siempre que pueda ver la app. Son dos mitades, y Apple entrega una de ellas.

La mitad estática es de Apple. La primera Tech Talk termina con ella: “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) (en la charla Modernize Your UIKit App presentamos una nueva skill de modernización de apps; con Xcode 27.1 pasa a llamarse App Resizability y ahora admite SwiftUI y el iPhone Duo).³ La skill es un conjunto de archivos de texto plano dentro de la beta: en Xcode 27.1 beta, Contents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/app-resizability.idechatprompttemplate y cinco archivos de referencia a su lado.¹⁵ Sus instrucciones dicen qué tan amplio debe ser el alcance: “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.” (trata una petición sobre el iPhone Duo plegable como una petición de todas las tareas del Task Registry, porque una pantalla que cambia de tamaño las expone todas a la vez).¹⁵

Vale la pena leerla aunque nunca la ejecutes, porque es la lista de revisión de Apple puesta por escrito. Comprueba tres ajustes del proyecto sin cambiar ninguno (una clave de pantalla de lanzamiento, la declaración de orientación de iPad, UIRequiresFullScreen) y luego busca cinco patrones: UIScreen.main, diseño decidido por la orientación de la interfaz, diseño decidido por userInterfaceIdiom, ciclo de vida de la aplicación donde corresponde el ciclo de vida de escenas, y código de área segura que da por hecho que los dos lados coinciden. El archivo de área segura tiene la línea que explica la mitad de lo que sale mal en este teléfono: “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.” (los márgenes horizontales asimétricos son lo normal; donde hay una barra vertical, un borde horizontal suele llevar todo el margen y el otro, cero).¹⁵

Kiradex es una app de SwiftUI escrita este año, y esas cinco búsquedas no encuentran nada en ella.¹³ Cada hallazgo de arriba salió de ejecutarla. Ese es el límite de la mitad estática: lee el código fuente, y el pliegue, la franja y el teclado solo se ven en una pantalla.

La otra mitad es un recorrido que el agente puede ejecutar y mirar. Lo que hizo posible la auditoría de arriba fueron tres piezas pequeñas, y ninguna es específica de esta app:

1. Una prueba de UI que visita cada tipo de pantalla y se detiene en cada una. Sin aserciones; un recorrido. El nuestro abre el Dex, un set, una carta, una hoja, la lista de la colección, una carta de la colección, el visor a pantalla completa y la búsqueda con el teclado arriba: ocho paradas.¹³
2. Una captura que ocurre en la Mac, no en la prueba. La captura propia de una prueba de UI es de una sola pantalla. simctl llega a las dos:

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

La prueba escribe un archivo vacío con el nombre de la parada; un bucle de shell en la Mac lo ve, captura las dos pantallas y responde con un segundo archivo; la prueba lo espera y sigue su camino. La captura exterior mide 1398 por 2034 píxeles con el teléfono cerrado y la interior 2853 por 2007 con el teléfono abierto, así que las imágenes de la auditoría y las capturas de la tienda salen de la misma ejecución.⁹¹³ 3. Una forma de cambiar la pose sin poner la mano en el mouse. simctl no tiene comando de poses y los frameworks de pruebas de UI de esta beta no tienen ninguna llamada de bisagra que yo haya encontrado, así que el script presiona los botones Closed, Book, Open y Rotate Right de Device Hub a través de la API de accesibilidad, lo que funciona con Device Hub en segundo plano.¹³

Con eso, revisar la app en cada pose deja de ser pedirle una opinión al agente y se convierte en una carpeta de imágenes por pose que el agente, y tú, pueden leer. El brief de abajo es el que yo le entregaría; está en inglés porque está pensado para pegarse tal cual en un agente de programación.

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.

El material de Apple, en el orden en que yo lo usaría

Todo lo que Apple ha publicado para este dispositivo cuelga de una sola página, Get ready for iPhone Duo.¹⁹ En orden de trabajo:

No he leído el resumen de preguntas y respuestas de los Group Lab ni los hilos del foro: las páginas del foro de Apple responden a una descarga automatizada con una página de verificación humana, y no la esquivé.

Puntos clave

• Si ya publicas una app: saca ya el trabajo de redimensionamiento, compilado con Xcode 27. Es lo que tus clientes tendrán en un Duo el 23 de octubre si ese día la tienda sigue cerrada al SDK 27.1, y nada de eso necesita la beta.
• Si estás adoptando las API del Duo: compila con Xcode 27.1 beta, confirma sdk 27.1 o posterior con otool, mantén la build en TestFlight y encierra las llamadas exclusivas de 27.1 si el mismo código todavía tiene que compilar para la tienda.
• Si estás probando: no leas el código, ejecuta las poses. Cerrado, abierto, semiplegado, cada uno de ellos girado, una hoja, el teclado, una vista a pantalla completa y una pantalla abierta mientras se despliega el teléfono. Captura las dos pantallas cada vez.
• Si estás armando la ficha de la tienda: captura desde ya a los tamaños del Duo, compón por script, usa los marcos de Apple de frente y ten una versión lista para el día en que se abran los espacios.
• Si le pasas esto a un agente: dale el recorrido, no solo los archivos. La skill App Resizability de Apple cubre lo que se puede encontrar leyendo; todo lo que aparece en los hallazgos de arriba se encontró mirando.

Preguntas frecuentes

¿Mi app actual funciona en el iPhone Duo sin cambios?

Sí. La charla de Apple lo promete para cualquier SDK, y el simulador lo confirma: una build sellada con el SDK de iOS 26 se ejecutó como una ventana de 375 por 667 puntos, y una sellada con 27.0 llenó la pantalla junto a la franja de estado, con barras horizontales. Ninguna de las dos recibe barras verticales ni regiones reservadas.³¹²

¿Qué Xcode necesito para el diseño completo del iPhone Duo?

Xcode 27.1 beta (27A9269), que trae el SDK de iOS 27.1 y el único simulador del iPhone Duo. Su runtime de simulador 27.1 solo admite el tipo de dispositivo iPhone Duo, así que los demás iPhone se prueban en el runtime 27.0. El SDK de Xcode 27.2 beta tiene las mismas API, y una sonda sellada con 27.2 se comportó como 27.1 en el simulador, pero ese Xcode no tiene ningún Duo en el que ejecutarla.⁸¹²¹⁴

¿Puedo enviar hoy una build para el iPhone Duo a la App Store?

No una compilada con el SDK 27.1, al 2 de octubre de 2026. App Store Connect acepta builds de las betas de Xcode 27.1 y 27.2 para pruebas internas y externas en TestFlight, y builds de Xcode 27 para la tienda. Apple no ha puesto fecha al cambio.⁸

¿Qué tamaños de captura pide App Store Connect para el iPhone Duo?

1398 por 2034 o 2034 por 1398 píxeles para la pantalla exterior, y 2007 por 2853 o 2853 por 2007 para la interior, de una a diez imágenes sin canal alfa. La subida figura como disponible “later this year” (más adelante este año).⁹

¿Cómo capturo las dos pantallas del simulador del iPhone Duo?

xcrun simctl io <udid> screenshot --display=primary para la pantalla exterior y --display=primary-1 para la interior. La captura propia de una prueba de UI cubre una sola pantalla.¹³

¿Por qué las barras de mi app siguen horizontales en el simulador del iPhone Duo?

Tres causas, en el orden en que conviene revisarlas. El binario no está sellado con el SDK 27.1. Las barras están hechas a mano en lugar de pertenecer a un TabView, un NavigationStack o un NavigationSplitView. O la pantalla interior está en vertical, donde Apple mantiene las barras horizontales por diseño.²⁷¹²

¿Necesito un diseño para cada pose?

No. La guía de Apple son dos diseños, ancho compacto y ancho regular, más una respuesta al pliegue donde el contenido lo cruzaría. Kiradex tiene esos dos y una vista de disposición; la pose Book no necesitó código.⁷¹³

Relacionado en este sitio: el post sobre el simulador tiene los pasos de instalación, el perfil del dispositivo y las mediciones por pose corregidas; diseñar para el iPhone Duo lee la guía de diseño de Apple como reglas; el post sobre el Duo para desarrolladores tiene las cifras del hardware y la historia con fechas; el post sobre capturas defiende qué debería decir un set; la lista de comprobación para el iPhone redimensionable es el trabajo de Xcode 27 que este post te dice que publiques primero; y el hub de Xcode 27 sigue la cadena de herramientas.

Fuentes