Diseñar para el iPhone Duo: qué se mueve, qué se divide y qué se queda

¿Qué exige diseñar para el iPhone Duo? Dos diseños, no un diseño por postura: “Un diseño en compact width para la pantalla externa y un diseño en regular width para la pantalla interna te dan los fundamentos para cada postura”, y el consejo de Apple es “diseñar tu app para que cambie de tamaño libremente”. (4:32)¹² Sobre esa base se apoyan cuatro patrones que describen la guía y sus tres Tech Talks acompañantes: los controles se van al costado de la pantalla y conservan un orden de arriba abajo; el contenido se separa de esos controles salvo que ocupe todo el ancho de forma deliberada; los elementos interactivos se reubican lejos del pliegue, mientras que el contenido con desplazamiento no lo hace; y un contenedor nuevo, el arrangement, divide o superpone dos vistas siguiendo reglas. Los Tech Talks explican las API detrás de los dos últimos puntos, y los arrangements llegan con iOS 27.1.³

Apple publicó Designing for iPhone Duo en las Human Interface Guidelines la tarde del keynote, junto con tres Tech Talks orientados al diseño: “Design for iPhone Duo”, “Strike a pose with adaptive layouts on iPhone Duo” y “Raise the bar with iPhone Duo”.¹²³⁴ El artículo para desarrolladores de este sitio trabaja la aritmética de los puntos y las reglas del SDK. Este otro trata las decisiones de diseño que pide la guía, citadas con las palabras del propio Apple y con la marca de tiempo de cada Tech Talk, además de lo que pienso hacer con ellas en mis propias apps.

TL;DR: Diseña para dos clases de tamaño y deja que el sistema se ocupe de las posturas. Las barras pasan a vertical en el costado de la pantalla externa y en la pantalla interna en horizontal; solo la pantalla interna en vertical conserva barras horizontales.⁴ Los elementos con icono pasan a vertical, los que son solo texto se quedan horizontales, y la parte superior de la barra vertical es para Back o Close, seguidos de una acción destacada como Done.⁴ El contenido se separa de la barra a través del área segura horizontal, salvo que sea inmersivo y no tenga desplazamiento.² En el pliegue, “elementos como las alertas se mueven al lado trailing” (4:09) en la postura de libro, y sobre una mesa los controles interactivos bajan a la mitad inferior, mientras que “el contenido de desplazamiento continuo, como artículos, feeds, documentos y listas, no se reubica” (3:46).³ Los arrangements son el nuevo contenedor de diseño, de tipo split u overlay, y la regla de Apple para elegir es la que ya usas: una pila horizontal o vertical se convierte en split, y un ZStack en overlay.³

Una regla antes que los patrones

Dos de los Tech Talks y la guía repiten una misma frase, y es la frase desde la que conviene diseñar. Vince, del equipo de diseño de Apple: “La gente usará el iPhone Duo en muchas posturas distintas, y querrás que tu app se vea genial en todas ellas. Pero eso no significa diseñar un layout a medida para cada postura. En vez de eso, concéntrate en dos clases de tamaño: compact width en la pantalla externa y regular width en la pantalla interna. Evita anchos fijos, breakpoints o cualquier medida atada a una pantalla concreta” (3:50).² La guía dice lo mismo en su sección sobre las posturas.¹ Vince añade un diseño opcional, para el dispositivo apoyado en una mesa como una laptop, donde “los contenidos multimedia pueden ir arriba, mientras que los controles táctiles descansan sobre una base estable abajo” (4:48), siempre que “tenga exactamente los mismos controles y la misma jerarquía general que las demás posturas” (4:57).²

Fotograma de la transmisión del evento de Apple del 9 de septiembre de 2026, 11:05 a. m. PT: la postura de pie. La lista de la guía es “parcialmente plegado como un libro, apoyado sobre una superficie o de pie sobre sus cantos”.

Todo lo que sigue asume esa base, la misma que audita la lista de verificación del iPhone redimensionable y que explica el artículo sobre el redimensionamiento del iPad. Si un diseño está construido a partir de clases de tamaño, márgenes de diseño e insets del área segura, la promesa de Vince es que “tu app ya debería adaptarse al iPhone Duo” (4:27).²

El costado: qué se muda ahí y qué se queda

En la pantalla externa, los controles que vivían arriba y abajo “se mueven al lado derecho de la pantalla para maximizar el espacio vertical y hacerlos más fáciles de alcanzar con el pulgar derecho” (1:18).² El costado alberga la barra de pestañas, las barras de herramientas, controles de navegación como Back, la barra de estado y la Dynamic Island, “que se expande verticalmente a medida que llegan las Live Activities” (1:48).² En la pantalla interna las barras siguen verticales en horizontal y vuelven a ser horizontales en vertical, “la única postura en la que hemos mantenido barras horizontales” (5:27), porque “hay espacio vertical de sobra para el contenido de la app” (5:32).² En Split View, “cuando una app está en el lado izquierdo, los controles también se mueven al borde izquierdo de la pantalla” (3:11).² Y la barra se alinea con el hardware, así que “se mantiene en el mismo lado del dispositivo en los idiomas que se escriben de derecha a izquierda” (4:21).⁴

Fotograma de la transmisión del evento de Apple del 9 de septiembre de 2026, 10:59 a. m. PT: el dispositivo a medio plegar con la pantalla interna de frente y los controles laterales en su borde derecho.

Dos cosas deciden si un control determinado pasa a vertical. La primera es su contenedor. Anna, de UI Frameworks: “asegúrate de estar usando las barras que proporcionan contenedores de navegación como TabView o NavigationStack” (2:19), porque el contenido de instancias personalizadas de UIToolbar, UINavigationBar o UITabBar “no se tendrá en cuenta” (2:58).⁴ En las vistas divididas “solo participa la columna de detalle” (3:43), y los inspectores “no reciben una propia” (3:53).⁴ La segunda es el contenido del elemento. Las barras verticales tienen “altura de elemento flexible y ancho fijo” (6:10), lo que “las hace más adecuadas para representaciones de elementos que solo llevan símbolo” (6:13).⁴ Por eso “los elementos con icono, como los botones back y share, cambian su eje a vertical. Y los elementos de solo texto, como el botón edit, siguen en el eje horizontal” (7:06).⁴ La versión de Vince es la del diseñador: “Los elementos de barra de herramientas demasiado anchos para el espacio de la derecha, como un botón de texto o un control segmentado, deberían quedarse en la barra de navegación en el iPhone Duo” (6:22).²

La regla de orden es breve. “Reserva la parte superior para los controles de navegación principales, como back o close, seguidos de acciones destacadas, como done” (4:47).⁴ En SwiftUI, un Back o Close personalizado usa la ubicación cancellationAction (5:02) y una acción destacada usa topBarPinnedTrailing (5:24); en UIKit, un elemento leading con leftItemSupplementsBackButton en su valor predeterminado, false (5:06), y pinnedTrailingGroup para la acción destacada (5:27).⁴ Todo lo demás conserva su agrupación original, con “un espaciador vertical que separa visualmente las ubicaciones superior e inferior” (5:34).⁴

Las reglas del Tech Talk sobre barras para elementos individuales, cada una con su pista:⁴

• La prueba para un elemento personalizado: “¿simplemente refuerza el símbolo, o aporta información autónoma?” (9:36)
• Una cuenta va en un distintivo, lo que convierte un elemento de texto y símbolo en uno de solo símbolo que “se siente en casa en una barra vertical” (9:23); “un botón de carrito que muestra un importe” se queda horizontal (9:52).
• Un elemento que alterna entre símbolo y texto, como Edit, se queda horizontal; el botón Edit del sistema ya lo hace, y uno personalizado adopta el AxisBehavior exclusivamente horizontal (8:11, 8:32).
• Una vista personalizada o compleja se queda horizontal de forma predeterminada (8:40); si “sí admite una representación vertical” (8:48), el axis behavior con preferencia vertical le abre la puerta a la barra (8:54).
• Dale un título a cada elemento incluso cuando muestre un símbolo, porque “el sistema lo usa cada vez que un elemento pasa a un menú de desbordamiento o a una forma expandida” (7:44).
• Las barras de accesorios de teclado “deberían permanecer unidas al teclado en lugar de pasar al eje vertical” (10:00).
• Las vistas personalizadas leen la propiedad de entorno toolbarVerticalEdge, o el trait equivalente en UIKit, para saber si hay una barra vertical presente (10:35).

El desbordamiento es donde se expresan las preferencias de diseño, y el Tech Talk da cinco reglas:⁴

• “De forma predeterminada, los elementos se desbordan de abajo hacia arriba” (13:23); cada elemento puede llevar una prioridad de visibilidad alta, baja o personalizada, asignada primero “por grupos” (13:36) y después dentro de cada grupo. Las API de prioridad y desbordamiento son las incorporaciones de la WWDC26 a las barras de herramientas, tratadas en el artículo de este sitio sobre SwiftUI en iOS 27; en 13:49 el Tech Talk te remite a la sesión de la WWDC26 de Apple sobre las novedades de SwiftUI.
• Decide qué se comprime primero: en vistas centradas en la navegación “la barra de herramientas se comprime primero, de modo que los destinos principales sigan accesibles” (12:07), que es el comportamiento predeterminado; en vistas orientadas a tareas “la barra de pestañas se comprime primero para preservar las acciones de uso frecuente” (12:18), lo que se configura con toolbarCompressionBehavior (12:22).
• Integra el menú de desbordamiento propio de la app dentro del del sistema, con ToolbarOverflowMenu en SwiftUI o additionalOverflowItems en UIKit (12:36, 12:43), y reserva los puntos suspensivos únicamente para el desbordamiento (12:53).
• “Las acciones de uso frecuente, como Compose en Mail o New Note en Notes, deberían estar entre las últimas en pasar al desbordamiento” (13:59).
• Los elementos con distintivo “deberían permanecer visibles más tiempo para preservar su legibilidad de un vistazo” (14:11).

Las barras verticales no son obligatorias. Un diseño de una sola página con el peso abajo, como Calculator, o una hoja con un único elemento de barra de herramientas como Close, pueden desactivar la barra con toolbarVerticalBehavior o preferredVerticalBarBehavior (14:28, 14:37, 14:47).⁴

Centrado, o desplazado hacia un lado

Con la barra en un costado, “ahora muchas capas son asimétricas” (6:33).² Vince da tres posiciones. La mayor parte del contenido se separa para no quedar oculto tras los controles, y “si tu app se alinea con los insets horizontales del área segura, esa separación ocurre automáticamente” (6:58).² Parte de la interfaz sigue centrándose en la pantalla completa sin separación, algo que “funciona bien para interfaces inmersivas y muy visuales que no se desplazan, siempre que estés seguro de que los elementos interactivos no quedarán bloqueados por los controles de la derecha” (7:10).² Y ambas cosas se mezclan: “una imagen de fondo o un encabezado a todo el ancho con contenido en primer plano desplazable y con margen” (7:22), siempre que “cada elemento interactivo viva dentro de esa área desplazable para que nada quede tapado” (7:28).² La nota de la guía sobre el área segura añade el caso de Split View: el borde opuesto puede llevar los controles de la otra app, así que el área segura importa en ambos bordes.¹

El pliegue: la reubicación

Fotograma de la transmisión del evento de Apple del 9 de septiembre de 2026, 11:08 a. m. PT: las capas de la pantalla. Parcialmente plegada, la curva que atraviesa el centro es la “folding region” de la guía.

Maria, Human Interface Designer en el sistema de diseño de Apple, abre con el principio: “Un gran diseño para el iPhone Duo depende de saber cuándo adaptarse” (2:25).³ Muchas interfaces “pueden fluir con naturalidad alrededor de las reserved regions” (2:30), y el resto recurre a la reubicación, “que ajusta el marco de los elementos existentes en función del espacio disponible, manteniendo el contenido importante visible, alcanzable y sin obstrucciones incluso cuando el dispositivo está parcialmente plegado” (2:39).³ El patrón tiene un alcance, “desde un botón hasta un contenedor entero o partes más grandes de un diseño” (3:03), con dos reglas: “Si un elemento puede adaptarse de forma independiente, muévelo por su cuenta. Y cuando varios elementos funcionan juntos, muévelos juntos para preservar su relación” (3:17), y “ten cuidado con el movimiento excesivo” (3:26), porque “alejar un elemento de su origen debilita su relación visual” (3:29).³ Su ejemplo es un menú contextual sobre una foto seleccionada: en lugar de centrar el menú en la región trailing, “ambos elementos se mueven juntos y se alinean alrededor del pliegue” (3:39).³

La excepción es aquella en la que más se apoyarán quienes diseñan: “El contenido de desplazamiento continuo, como artículos, feeds, documentos y listas, no se reubica. Estas experiencias ya se adaptan mediante el desplazamiento, así que moverlas entre las regiones disponibles puede interrumpir la continuidad” (3:46).³ Vince lo dice desde el otro lado: el sistema empuja los elementos interactivos fuera de la curva porque “los botones son difíciles de tocar cuando caen justo en el pliegue” (9:28); el comportamiento está integrado en “hojas, alertas, menús, botones de barra de herramientas y más” (9:40), y “el contenido desplazable no necesita evitar esta región” (9:57).²

La orientación del pliegue define las regiones: en la postura de libro corre en vertical y las regiones son izquierda y derecha; sobre una mesa, o en orientación vertical, corre en horizontal y las regiones son arriba y abajo.²³ Adónde va un elemento reubicado depende de la postura, y las razones de Maria son la parte útil. En la postura de libro, “elementos como las alertas se mueven al lado trailing. Esto las mantiene más cerca de donde aparecerán cuando el dispositivo se cierre y la experiencia continúe en la pantalla externa” (4:09).³ Apoyado en una mesa, “la región superior funciona bien para contenido que se beneficia de verse a distancia” (4:29), y “la región inferior funciona bien para controles interactivos” (4:39), donde “elementos táctiles como los controles multimedia pueden moverse aquí y ofrecer una superficie más estable para el toque” (4:43).³ El Tech Talk sobre principios coincide: en vertical y parcialmente plegado, “los elementos interactivos se mueven a la mitad inferior de la pantalla, lo que hace que sean más fáciles de alcanzar mientras el dispositivo permanece estable sobre la superficie” (2:33).² Cuando varias regiones servirían, mantén el criterio contextual: un campo de búsqueda “aprovecha el espacio adicional” (5:00) cuando el dispositivo está abierto y, a medida que se pliega, su “ancho y su posición se adaptan para seguir sobre la vista que está buscando” (5:04).³

El sistema hace casi todo esto. “Las hojas de acciones, las alertas, los menús y los popovers son experiencias contextuales ligeras que pueden aparecer sobre una reserved region” (5:23), y el sistema “reposiciona automáticamente los componentes alrededor de la reserved region” (5:34).³ Una vista dividida “mantiene ambas columnas visibles ajustando su ancho y colocándolas en una división pareja de 50/50” (5:40).³ La cuadrícula es el caso que te toca a ti: en el diseño de Fitness de Maria, “puedo preservar los márgenes exteriores mientras aumento el espaciado alrededor de la bisagra, manteniendo cada contenedor dentro de su región” (5:56).³ Su resumen de todos los ejemplos es el encargo de diseño: “estamos moviendo, redimensionando o reorganizando lo que ya está ahí. Mantén el contenido, la funcionalidad y los diseños disponibles para que la gente pueda acceder a la experiencia completa sin importar cómo esté usando el iPhone Duo” (6:04).³

Reserved regions, la maquinaria bajo la reubicación

Maria introduce el término en el Tech Talk sobre diseños adaptativos: “Las nuevas características de hardware también influyen en la forma del espacio disponible. Entre ellas están la bisagra y las dos cámaras repartidas entre la pantalla externa y la interna. A esto lo llamamos reserved regions” (0:37), y aconseja tratarlas “igual que cualquier otra área a la que tu diseño ya se adapta” (0:53), con los controles de ventana de iPadOS como ejemplo.³ Hay tres: la cámara externa, la cámara interna mientras está activa, y el pliegue (1:00, 1:18, 1:32).³ El artículo para desarrolladores recoge las definiciones de la guía para cada una y deja constancia de mi comprobación de que la guía no enlaza documentación alguna para estas API, así que esta sección se queda con la maquinaria.¹ Harry, ingeniero de UI Frameworks, describe la API. “En SwiftUI consultas las reserved regions usando un GeometryProxy obtenido de un GeometryReader o del modificador onGeometryChange. Usa el nuevo método reservedRegion en el geometry proxy para obtener las regiones disponibles en tu vista.” (6:38) En UIKit, “usarás el método reservedRegion disponible en UIView” (7:03), y “puedes consultar la propiedad frame de una reserved region para incorporarla a tu propio diseño” (7:07).³

Hay dos tipos. El pliegue “está respaldado por una división reserved region, porque divide un área mayor en varias áreas más pequeñas” (6:55), y “solo está activa cuando alguien ha plegado el dispositivo. Cuando está plano, permanece inactiva y su ancho es cero” (7:26).³ La cámara es una occlusion region: estas “no dividen áreas, sino que las ocluyen” (7:54), y la región “está activa cuando la cámara está activa e inactiva cuando la cámara está inactiva” (8:12).³ Las regiones inactivas se pueden consultar con la opción includeInactive, y la razón de Harry para fijarse en ellas es una decisión de diseño: “en diseños tipo cuadrícula podrías preferir un número par de columnas cuando hay una división region presente, independientemente de su estado de actividad” (7:41).³ La guía repite eso como regla.¹ A las 4:15 p. m. PT del día del keynote, la guía no enlazaba ninguna página de documentación para estas API, y la página para desarrolladores de Apple fecha la beta de Xcode 27.1 “más adelante este mes”.¹⁵

Arrangements: split u overlay

Fotograma de la transmisión del evento de Apple del 9 de septiembre de 2026, 11:00 a. m. PT: la pantalla interna que Apple describe como un 80 por ciento más grande, el lienzo al que apuntan los arrangements.

La definición de Harry: “Un contenedor de diseño se sitúa entre estos contenedores de navegación y de contenido. Estos contenedores de diseño organizan dos vistas según un conjunto de reglas. Se llaman arrangements” (9:20).³ Las reglas toman entradas, “la clase de tamaño horizontal y vertical de la vista, la relación de aspecto entre el ancho y el alto de la vista, y si hay alguna división region activa” (10:37), y producen salidas: “si debería mostrar la vista siquiera” (10:52) y, en tal caso, “cuál es su marco” (10:54).³ Luego, la fecha: “en iOS 27.1 puedes usar arrangements proporcionados por el sistema en tus propias apps” (11:02).³

En SwiftUI, un ArrangementView toma una vista primaria y una secundaria (11:25) y un estilo definido con arrangementViewStyle (11:57); en UIKit, un UIArrangementViewController toma controladores de vista primario y secundario (11:39).³ El estilo split, el predeterminado, “divide horizontalmente cuando la vista es más ancha que alta” (12:13) y verticalmente cuando es más alta, y puede restringirse a un solo eje; si no puede dividir en su eje principal, “opta por mostrar una sola vista” (12:49).³ El estilo overlay “prefiere colocar el contenido uno encima o debajo del otro” (13:31), y cuando el dispositivo se pliega “prefiere colocar las vistas primaria y secundaria una al lado de la otra” (13:51), algo que una vista puede detectar mediante la propiedad de entorno overlayArrangementZIndex para alternar entre una forma contraída y otra expandida (14:01).³

Elegir entre ambos es el consejo más claro del Tech Talk, y la guía lo adopta. “Si ya estás implementando un diseño tipo split en partes de tu app con componentes como un HStack o un VStack, considera usar el split arrangement. Si ya estás implementando un diseño tipo overlay en partes de tu app con componentes como un ZStack, considera usar el overlay arrangement” (14:44).³ Sin un patrón previo, usa un overlay “cuando hay una relación clara de primer plano y fondo entre tus vistas” (15:10), como los controles sobre contenido legible en Accessibility Reader, y un split “cuando se trata más bien de una relación principal-detalle” (15:32), como un podcast y su transcripción, donde “es importante que ninguno de los dos quede nunca oculto” (15:43).³ Los dos límites, contenedores de navegación alrededor de un arrangement y no dentro de él, y ningún arrangement dentro de una List o una ScrollView, están en 16:15 y 16:26 del Tech Talk; la guía solo enuncia el primero, en la frase que cita el artículo para desarrolladores.¹³

La pantalla interna: tres diseños honestos

“No quieres simplemente una app de iPhone estirada” (7:39).² Vince ofrece tres formas. Una vista dividida, que saca a la superficie “varios niveles de la jerarquía de tu app al mismo tiempo” (7:46), con la condición de que la jerarquía “no cambie entre la pantalla externa y la interna” (7:51), porque la gente “puede abrir y cerrar el dispositivo con frecuencia mientras usa tu app, así que debe ser predecible y consistente por dentro y por fuera” (7:59).² Un reflujo, siguiendo a Music, donde “un diseño apilado verticalmente” (8:15) se convierte en “un diseño de dos columnas cuando hay más espacio horizontal” (8:18).² O una barra de pestañas presentada “como barra lateral en la pantalla interna” (8:26), que “funciona mejor para apps con mucha densidad de información, como este ejemplo de Health” (8:33).² El ejemplo de Mail en la guía es el caso de la vista dividida: una lista o un mensaje cuando está cerrado, ambos lado a lado cuando está abierto.¹

Las hojas tienen sus propias reglas. En la pantalla externa “los controles de la hoja también se mueven al costado” (8:46), algo que puedes desactivar para una hoja con un solo botón de barra de herramientas, en cuyo caso “las hojas se detienen justo antes de la cámara frontal y la barra de estado se reposiciona sola” (9:04).² En la pantalla interna, las hojas “usan barras horizontales estándar” (9:13) de forma predeterminada, y cuando el dispositivo está parcialmente plegado “se deslizan a un lado para no quedar apoyadas en el pliegue” (9:20).² El Tech Talk sobre barras añade la excepción de ubicación: las hojas de la pantalla interna están “centradas de forma predeterminada, y sus elementos siguen horizontales” (4:03), pero con la API preferredPlacement, “las hojas colocadas a la izquierda se quedan sin barra vertical, mientras que las colocadas a la derecha reciben una” (4:11).⁴

La auditoría

El Tech Talk sobre barras y el de diseños adaptativos terminan cada uno con una lista de auditoría, así que aquí van como una sola. La lista final del Tech Talk sobre barras (15:10): compilar con los SDK más recientes, porque las barras verticales se activan según el SDK (2:06); auditar las barras y su orden (4:41), y actualizar los elementos personalizados para que puedan disponerse en vertical; y asignar prioridades de visibilidad “para que el sistema pueda adaptarse” (15:26).⁴ Después, del Tech Talk sobre diseños adaptativos (16:40): “empieza auditando los diseños centrados de tu app. Plantéate si puedes convertirlo en un diseño de dos columnas, o qué patrón de reubicación tiene sentido en ese caso de uso”; usar contenedores y presentaciones estándar para obtener el comportamiento gratis (16:49); recurrir a ArrangementView para diseños split u overlay personalizados; e “identificar en tus vistas los controles dispuestos manualmente de mayor prioridad y considerar adoptar la API ReservedRegions para implementar tu propia reubicación donde haga falta” (17:06).³

Qué pienso hacer con esto

Tres de mis apps son apps de iPhone, y la guía las ordena con nitidez. La clasificación es mi lectura, no la de Apple.

• Get Bananas es una lista. Las listas no se reubican, la barra de pestañas y la barra de herramientas se mueven solas al costado si sigo usando los contenedores del sistema, y la única decisión de diseño es la prioridad de visibilidad: la acción de añadir un artículo es mi Compose, así que debería ser lo último en desbordarse.
• Reps registra cada serie como una fila con peso, repeticiones y una acción de registro, en una cuadrícula durante el entrenamiento, que es justo el ejemplo de Fitness de Maria. La decisión: en la postura de libro, una fila de tres columnas deja la columna del medio sobre la bisagra, así que la cuadrícula pasa a dos columnas emparejadas. En la postura de mesa, la acción de registro se sitúa en la mitad inferior. La contrapartida es un toque más por serie a cambio de un objetivo que nunca cae en el pliegue, donde, según Vince, “los botones son difíciles de tocar” (9:28).² El temporizador de descanso se queda arriba, la región que, según Maria, funciona bien para “contenido que se beneficia de verse a distancia” (4:29).³
• Return dibuja gráficos de salud, que son contenido con desplazamiento. Donde hoy un gráfico y su selector de rango conviven en una pila vertical, la regla de Harry asigna esa pila a un split arrangement, que mantiene ambos visibles mientras el dispositivo se pliega; el gráfico en sí nunca debería reubicarse.

Puntos clave

Para quienes diseñan: - Dos clases de tamaño, no posturas: compact width fuera, regular width dentro.¹ El único extra opcional que sugieren los diseñadores de Apple es un diseño de mesa que conserve los mismos controles.² - Los iconos pasan a vertical, el texto se queda horizontal; arriba en la barra lateral van Back o Close, luego Done; las acciones frecuentes y los elementos con distintivo se desbordan al final.⁴ - El contenido con desplazamiento nunca se reubica; las alertas, los menús, las hojas y los controles sí, y el destino sigue al propósito: las alertas al lado trailing en la postura de libro y a la región superior sobre una mesa, y los controles táctiles a la mitad inferior.²³

Para quienes hacen ingeniería de diseño: - El pliegue es una división region que solo está activa cuando el dispositivo está plegado y tiene ancho cero cuando está plano; la cámara interna es una occlusion region activa solo mientras la cámara lo está; ambas se consultan desde un GeometryProxy o una UIView.³ - Los arrangements llegan con iOS 27.1: una pila se convierte en split, un ZStack en overlay, y los contenedores de navegación se quedan fuera.³ - Usa las barras del sistema que vienen de los contenedores de navegación, o el diseño vertical no ocurrirá nunca.⁴

Preguntas frecuentes

¿Necesito un diseño para cada postura?

No. Apple dice que hay que diseñar para dos clases de tamaño, compact width en la pantalla externa y regular width en la interna, y evitar anchos fijos, breakpoints o medidas atadas a una pantalla.¹² El único extra opcional, según el Tech Talk de diseño, es un diseño para la postura de mesa con los mismos controles y la misma jerarquía.²

¿Qué controles siguen horizontales en el iPhone Duo?

Los elementos de solo texto, los demasiado anchos para la barra lateral como los controles segmentados, los que alternan entre símbolo y texto como Edit, las barras de accesorios de teclado y, si así lo eliges, la barra entera en una app de una sola página con el peso abajo o en una hoja con un único elemento de barra de herramientas.²⁴

¿Qué es la reubicación?

Es el patrón de Apple para mover, redimensionar o reorganizar elementos existentes de modo que sigan visibles y alcanzables cuando el dispositivo está parcialmente plegado. Las alertas, los menús, los popovers, las hojas y los botones de barra de herramientas lo reciben del sistema; el contenido con desplazamiento queda exento.²³

¿Cuándo llegan las arrangement views y las API de reserved region?

El Tech Talk sobre diseños adaptativos dice que los arrangements proporcionados por el sistema se pueden usar en tus propias apps a partir de iOS 27.1, y la página para desarrolladores de Apple sitúa la beta de Xcode 27.1 más adelante en septiembre. La guía de diseño todavía no enlaza documentación para ninguna de las dos API.¹³⁵

¿El contenido con desplazamiento tiene que evitar el pliegue?

No. Tanto el Tech Talk de diseño como el de diseños adaptativos eximen al contenido con desplazamiento; ya se adapta mediante el desplazamiento.²³

Fuentes