El iPhone Duo cambia la rutina de pruebas porque una misma app puede aparecer en la pantalla exterior compacta, en la pantalla interior amplia, en posiciones parcialmente plegadas y en diseños de multitarea. Sin embargo, hay una limitación importante para los equipos que empiezan ahora: a 17 de septiembre de 2026, Apple indica que el soporte de desarrollo para iPhone Duo llegará con Xcode 27.1, con SDK actualizados y un simulador capaz de reproducir las nuevas posiciones y orientaciones, y que la beta estará disponible más adelante este mes. El dispositivo llegará al mercado el 23 de octubre con iOS 27.1.
Eso divide el trabajo en dos etapas. Antes de la beta, conviene corregir todo lo que ya impide que la app cambie de tamaño correctamente. Cuando Xcode 27.1 con soporte para Duo esté disponible, llegará el momento de validar aspectos específicos como el pliegue, las regiones reservadas, la multitarea, las escenas y las transiciones entre tamaños. Apple centraliza el material de preparación en Get ready for iPhone Duo y detalla la disponibilidad de Xcode en su actualización del 16 de septiembre de 2026.
Qué añade Xcode 27.1 a las pruebas del iPhone Duo
Según Apple, Xcode 27.1 añadirá los SDK y el simulador necesarios para ejecutar y probar apps para iPhone Duo. Lo importante no es simplemente disponer de otro tamaño de pantalla. El simulador debe representar distintas posiciones y orientaciones porque el sistema reorganiza barras, áreas seguras, contenido y posibilidades de multitarea según el dispositivo esté cerrado, abierto o parcialmente plegado.
En la práctica, el simulador debe formar parte de una matriz de pruebas, no de una única captura del diseño. Apple recomienda tratar la interfaz como redimensionable y adaptativa. En Design for iPhone Duo, Apple aconseja evitar anchos fijos, breakpoints ligados a una resolución concreta y diseños separados para cada posición. El foco principal debe estar en dos clases de tamaño: ancho compacto en la pantalla exterior y ancho regular en la pantalla interior.
Qué se puede revisar antes de la beta de Xcode 27.1
El mejor uso del tiempo antes de que llegue el simulador específico es eliminar dependencias de dimensiones rígidas. Una app que ya responde bien al redimensionamiento en iPad, iPhone Mirroring y ventanas variables parte de una base más sólida para Duo.
- Elimina anchos y altos fijos cuando no sean esenciales. Los componentes deben reaccionar al espacio disponible y no a un modelo de dispositivo codificado en el diseño.
- Revisa las clases de tamaño. En SwiftUI, UserInterfaceSizeClass y los valores de entorno de ancho y alto ayudan a tomar decisiones a partir del espacio disponible. En UIKit, el equivalente pasa por traits y size classes.
- Prefiere la navegación estándar. Apple destaca que componentes como NavigationSplitView, UISplitViewController, TabView y UITabBarController se adaptan entre posiciones y tamaños.
- Prueba el contenido en espacios estrechos y anchos. Una pantalla que funciona solo con el dispositivo totalmente abierto todavía no está lista. El mismo flujo debe seguir siendo comprensible cuando el ancho pase a la clase compacta.
- Evita posicionar controles con coordenadas absolutas. Barras, botones y elementos interactivos deben acompañar márgenes, safe areas y cambios de eje.
Matriz de pruebas para ejecutar cuando llegue el simulador del Duo
| Escenario | Qué observar | Fallos típicos que buscar |
|---|---|---|
| Pantalla exterior, dispositivo cerrado | Clase compacta, navegación, barras verticales, cámara y safe area | Contenido oculto, controles recortados, texto comprimido, barras superpuestas |
| Pantalla interior totalmente abierta | Clase regular, uso del espacio adicional, dos columnas o sidebar cuando tenga sentido | Contenido demasiado estirado, grandes espacios vacíos, jerarquía visual perdida |
| Parcialmente plegado como un libro | Región central del pliegue, desplazamiento de contenido y controles | Botones en el pliegue, texto o imágenes difíciles de leer en el centro, gestos que cruzan el pliegue |
| Parcialmente plegado en orientación vertical | Distribución vertical, alcance de controles y adaptación al espacio útil | Acciones importantes en la mitad menos accesible, elementos sobre la zona del pliegue |
| Split View lado a lado | Redimensionamiento continuo, clases de tamaño, geometría de la escena | Diseños dependientes de un ancho mínimo rígido, modales o menús fuera del área disponible |
| Vídeo fijado con la app redimensionada | Cambios de altura en tiempo real | Contenido recortado, desplazamiento roto, controles fuera de pantalla |
| Rotación y cambios de posición | Reflujo del diseño sin perder contexto | Reinicio de navegación, parpadeos del diseño, estado visual incoherente |
| Múltiples escenas | Creación y restauración de ventanas donde estén permitidas | Errores no gestionados, estado compartido de forma incorrecta, acciones disponibles en la pantalla equivocada |
El pliegue no debe convertirse en un breakpoint manual
Uno de los errores más fáciles es convertir el ángulo de la bisagra en una regla de diseño. Apple separa dos necesidades. Para efectos e interacciones, SwiftUI ofrece onHingeChange y UIKit ofrece UIHingeInteraction, que informan del estado y del ángulo de la bisagra. Para el layout, sin embargo, Apple recomienda usar las API de regiones y arrangements en lugar del ángulo bruto de la bisagra. Esta diferencia se explica en Leverage multiple displays and scenes on iPhone Duo.
Así se evita crear decenas de condiciones como “si el dispositivo está a 70 grados, mueve el botón”. El diseño debe responder al espacio utilizable y a las regiones proporcionadas por el sistema. El ángulo puede controlar una animación, un efecto de juego u otra interacción continua, pero no debe sustituir la geometría de la interfaz.
Safe areas y ReservedRegion: dónde afecta realmente el pliegue
Duo incluye áreas que no siempre deben contener contenido interactivo. Apple las llama reserved regions. Incluyen la región de división creada por el pliegue cuando el dispositivo está parcialmente abierto y regiones de oclusión como la cámara. En Strike a pose with adaptive layouts on iPhone Duo, Apple explica que la región del pliegue está activa cuando el dispositivo está parcialmente plegado. Cuando está completamente plano, esa región queda inactiva y su ancho es cero.
Para interfaces habituales, la opción más segura sigue siendo usar componentes y barras del sistema, que ya respetan las safe areas y evitan el pliegue. Para interfaces personalizadas y edge to edge, iOS 27.1 introduce ReservedRegion en SwiftUI y UIViewReservedRegion en UIKit. Estas API permiten consultar regiones que dividen u ocultan el área de contenido y colocar elementos sin chocar con hardware o interfaz del sistema.
Tampoco hay que asumir márgenes simétricos. Apple pide probar las safe areas y los layout margins de cada lado, también en Split View. Los fondos y las imágenes decorativas pueden extenderse más allá de la safe area cuando sea intencional, pero el texto, los botones y otros elementos interactivos deben permanecer en zonas legibles y fáciles de tocar.
Breakpoints: usa el espacio disponible, no el nombre del dispositivo
Para Duo, la regla práctica es sencilla: no crees una ruta separada llamada “iPhone Duo” si el mismo resultado puede lograrse adaptándose al tamaño disponible. La pantalla exterior es un caso compacto. La interior es un caso regular. Dentro de esas dos familias, la app todavía puede perder ancho o alto por multitarea, vídeo fijado, barras y cambios de orientación.
Un diseño robusto debe responder a esos cambios sin depender de una lista de resoluciones. En una pantalla de catálogo, por ejemplo, la interfaz puede pasar de una columna a dos cuando haya espacio. En una app con mucha jerarquía, una sidebar puede tener sentido en la pantalla interior. Una pantalla simple puede mantener una sola columna y aprovechar mejor los márgenes y el espacio adicional. El criterio debe ser la claridad de la interfaz, no simplemente si el dispositivo está abierto.
Estado de la app: redimensionar no puede significar empezar de nuevo
Apple destaca que iPhone Duo admite multitarea y múltiples instancias de interfaz. Es el primer iPhone en el que una app puede tener varias escenas de UI, un comportamiento ya conocido en iPad. Sin embargo, existe una diferencia importante: se pueden crear nuevas ventanas en la pantalla interior, pero no en la exterior. Apple recomienda gestionar los fallos al solicitar nuevas escenas y señala UIWindowSceneActivationAction, que se oculta automáticamente cuando no está disponible la creación de nuevas ventanas.
Además del requisito oficial de escenas, conviene incluir pruebas de continuidad de estado en el checklist del producto. Al cambiar entre las pantallas exterior e interior, rotar, entrar en Split View o modificar la posición, comprueba que la app conserva lo que estaba haciendo el usuario. Esto incluye navegación, texto aún no enviado, selección actual, reproducción multimedia, filtros y otra información de contexto relevante. Es una prueba de calidad de la app, no una garantía automática del sistema.
- Abre una pantalla profunda, cambia la posición y confirma que la navegación sigue en el mismo punto.
- Escribe contenido en un formulario, redimensiona la ventana y verifica que no se pierda nada.
- Inicia contenido multimedia o una tarea larga y prueba cambios de tamaño y orientación.
- Abre una segunda escena en la pantalla interior, cuando esté permitido, y confirma que cada ventana mantenga el estado correcto.
- Intenta solicitar una nueva escena en un contexto donde no esté disponible y confirma que la app lo gestione sin un error visible.
Qué todavía depende de la beta y de la documentación final
A 17 de septiembre todavía no es posible cerrar todos los detalles del flujo de pruebas porque Apple no ha publicado la beta de Xcode 27.1 con soporte para iPhone Duo. Hasta que llegue esa versión, deben confirmarse en la práctica los presets exactos del simulador, los controles para alternar posiciones y orientaciones, posibles known issues del SDK y cualquier cambio de API antes del lanzamiento.
Por eso, los vídeos de presentación no deben tratarse como el contrato final de implementación. Usa ahora los principios ya publicados para corregir redimensionamiento, navegación y safe areas. Después, valida el comportamiento en el simulador de Xcode 27.1, vuelve a leer las release notes correspondientes y realiza una ronda final en hardware real en cuanto tengas acceso. El simulador es ideal para geometría, layout y muchos flujos de estado, pero no puede sustituir por completo la validación física de ergonomía, cámaras, comportamiento del pliegue y rendimiento.
Checklist de adaptación antes del lanzamiento
- Eliminar dimensiones rígidas que impidan el redimensionamiento.
- Revisar diseños en clases de tamaño compacta y regular.
- Adoptar componentes de navegación y barras adaptativos siempre que sea posible.
- Garantizar que el contenido interactivo respete safe areas asimétricas.
- Planificar ReservedRegion o UIViewReservedRegion solo donde la UI personalizada lo requiera.
- No usar el ángulo de la bisagra como sustituto de las API de layout.
- Probar pantalla exterior, pantalla interior, posiciones parcialmente plegadas, rotación y cambios de altura.
- Probar Split View y redimensionamiento con vídeo fijado.
- Validar la conservación del estado durante redimensionamientos y transiciones.
- Revisar el soporte de múltiples escenas y gestionar la indisponibilidad de nuevas ventanas.
- Ejecutar la matriz otra vez cuando se publique la beta de Xcode 27.1 con el simulador del Duo.
- Repetir las pruebas tras las release notes finales y, cuando sea posible, en un iPhone Duo físico.
En resumen
Preparar una app para iPhone Duo no significa crear una interfaz diferente para cada ángulo de pliegue. El trabajo principal es hacer que la UI sea realmente redimensionable, respetar clases de tamaño, safe areas y regiones reservadas, y conservar el contexto del usuario cuando cambia la geometría. A 17 de septiembre de 2026, esa preparación ya puede empezar, pero la validación específica en el simulador depende de la beta de Xcode 27.1 que Apple anuncia para más adelante este mes. La mejor estrategia es llegar a esa beta con los problemas de redimensionamiento ya resueltos y usar el simulador para probar lo que introduce específicamente el nuevo hardware.
