iPhone Duo con Xcode 27.1: los 6 APIs del foldable que salieron el 18 de septiembre

Este es el tercer post de la serie sobre novedades post-launch de iOS 27. Los dos anteriores cubrieron los Agent Skills de Xcode 27 y Device Hub. Este cubre lo más urgente para quien piense soportar el iPhone Duo desde el día 1.

Xcode 27.1 beta salió el 18 de septiembre (9to5Mac, MacRumors, AppleInsider) — cinco semanas antes del envío del hardware el 23 de octubre. Requiere Mac Apple silicon con macOS 26.6 o superior. Trae el iOS 27.1 SDK y un simulador que reproduce las poses del foldable: abrir, cerrar, rotar, plegado parcial.

El SDK expone 6 APIs específicas de foldable que resuelven los problemas concretos que aparecen cuando una app tiene que vivir con un hinge en medio. Vamos por ellas (ecorpit — iPhone Duo SDK, sunyazhou — Adapting Apps to iPhone Duo).

1. Hinge API — saber cómo está doblado el device

SwiftUI: onHingeChange. UIKit: UIHingeInteraction. Ambas dan dos cosas: un estado discreto (.closed, .partiallyOpen, .fullyOpen) y un ángulo continuo.

.onHingeChange { _, newContext in
    if let hinge = newContext.hinge, hinge.status == .partiallyOpen {
        bend = hinge.angle.degrees
    } else {
        bend = 0
    }
}

Nota: newContext.hinge es opcional. Si es nil, el device no tiene capacidad de plegado — así detectas iPhones normales vs Duo con el mismo código.

En UIKit, UIHingeInteraction toma un update handler que recibe un UIHinge. El estado incluye .unknown además de los tres de SwiftUI (Apple recomienda tratarlo como .fullyOpen de forma defensiva). El ángulo está en radianes, no grados.

Para qué NO usarlo: decisiones de layout. Apple es explícito: el hinge API es para “interacciones y efectos” — animaciones que responden al ángulo, feedback sutil cuando el usuario dobla el device. Para acomodar el layout usa Reserved Regions y Arrangement Views (siguientes secciones).

2. Reserved Regions — dónde NO puedes poner contenido

Ni el pliegue ni las cámaras frontales del Duo son transparentes. El pliegue divide una vista grande en dos áreas visualmente separadas; las cámaras frontales cubren zonas del display. Reserved Regions te dice dónde están esas zonas para que puedas evitarlas o adaptarte.

SwiftUI: GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:). UIKit: UIView.reservedRegions(kind:options:) devuelve UIView.ReservedRegion values.

Dos tipos:

.division — el pliegue divide una vista grande en dos.
.occlusion — hardware (cámaras frontales) tapa contenido.

Cada región tiene frame, margins, kind, identifier, y —crítico— isActive. La región del pliegue está isActive: true cuando el device está .partiallyOpen; false cuando está .fullyOpen. La región de la cámara interior está isActive: true solo cuando la cámara se está usando.

GeometryReader { proxy in
    let divisions = proxy.reservedRegions(kind: .division, options: .includeInactive)
    PhotoGrid(columns: divisions.isEmpty ? 3 : 4)
}

En ese ejemplo, si detecta que hay una región de división (o sea, la app corre en Duo con posibilidad de doblarse), pinta 4 columnas para que el layout tenga sentido a ambos lados del pliegue. En iPhone regular, divisions está vacío y usa 3.

Por qué includeInactive importa: si el usuario abre el Duo mientras tu app corre, quieres que el layout ya esté preparado para el pliegue — no que se reflowee de golpe cuando aparezca la región. Renderas asumiendo que la región puede activarse.

3. Arrangement Views — layouts que abarcan el pliegue

Cuando tu app corre con el Duo abierto, muchas veces tiene sentido mostrar dos vistas: master en un lado, detail en el otro. Antes usábamos NavigationSplitView para eso, pero se comportaba pobre en foldables. ArrangementView es la API dedicada.

ArrangementView { PrimaryView() } secondary: { SecondaryView() }
.arrangementViewStyle(.split.axes(.horizontal))

Dos estilos base: .split (side-by-side cuando el device es más ancho que alto, stacked con primary arriba cuando es más alto que ancho) y .overlay (primary sobre secondary cuando no hay división activa; se separa al pliegue cuando el device se abre parcialmente). El default .automatic resuelve a .split en la mayoría de casos.

UIKit: UIArrangementViewController con updateArrangement(_:animated:). Mismos estilos, ergonomía distinta.

El .axes(.horizontal) fuerza la división horizontal siempre, útil cuando semánticamente el layout solo tiene sentido side-by-side (una app de comparación, por ejemplo).

4. Vertical Toolbars & Tab Bars — cuando el device abre, los bars rotan

Cuando el Duo está abierto, la orientación efectiva cambia. Los toolbars y tab bars horizontales del layout compacto se sienten fuera de lugar. iOS 27.1 los rota automáticamente a verticales si no configuras lo contrario.

Opt-out (mantener horizontal siempre):

SwiftUI: .toolbarVerticalBehavior(.disabled)
UIKit: override preferredVerticalBarBehavior para retornar .disabled

Regla de iconos: los bars verticales requieren iconos; los horizontales prefieren iconos pero aceptan títulos. Los items solo-texto se mantienen horizontales aunque el resto rote. Detalle práctico: si tu app tiene toolbar items con solo texto, la migración a Duo se ve rara — vale la pena agregar SF Symbols.

Custom opt-in per item:

.toolbar {
    ToolbarItem { ZoomSlider() }
    .axisBehavior(.verticalPreferred)
}

Valores de axisBehavior: .automatic, .horizontalOnly, .verticalPreferred. Para leer en qué edge está el bar actualmente:

SwiftUI: environment toolbarVerticalEdge
UIKit: trait verticalBarEdge

5. Direction-Aware Cameras — dos frontales, dos APIs distintas

El Duo tiene dos cámaras frontales: una en el display exterior y otra bajo el display interior. Hay dos formas de manejarlo:

Modo compatible: cámara frontal virtual. Si tu código usa .builtInWideAngleCamera o .builtInUltraWideCamera en .front position, iOS automáticamente elige entre las dos físicas según qué display esté hacia el usuario. Cero cambios en tu app.

Modo explícito: cámaras individuales (nuevo).

.builtInOuterUltraWideCamera — hasta 4K, 120 fps.
.builtInInnerUltraWideCamera — 1080p, 60 fps. Es la primera cámara under-display de un iPhone.

Para saber cuál está apuntando adelante en cada momento, usa AVCaptureDeviceDirectionCoordinator:

let coordinator = AVCaptureDeviceDirectionCoordinator(
    view: previewView,
    deviceTypes: [.builtInOuterUltraWideCamera, .builtInInnerUltraWideCamera],
    changeHandler: { directions in
        updateCameraChoice(
            forward: directions.forwardFacingDeviceDescriptors,
            backward: directions.backwardFacingDeviceDescriptors
        )
    }
)

Actualiza cada vez que el device se abre, cierra o rota.

Cuidado con el mirroring: si estás manejando cámaras individuales, pon automaticallyAdjustsVideoMirroring = false y decide isVideoMirrored a partir del direction map, no del position del device. Si dejas el auto, el mirror va a cambiar cuando no debería.

6. Camera Capture Accessory — content en el display exterior

Es la más creativa de las 6. Cuando el device está abierto, puedes mostrar contenido en el display exterior (el que ve la persona que está siendo fotografiada) mientras el usuario captura desde el display interior (la vista de composición).

SwiftUI: sceneAccessory(content:) con CameraCaptureAccessory dentro. UIKit: UISceneAccessory.cameraCapture(sceneConfiguration:userInfo:), registrado en el view controller con registerSceneAccessory(_:).

El accessory tiene isAvailable (varía según si el device está abierto/cerrado) y isEnabled (opt-in de la app). Se desmonta solo cuando la captura para, la app pasa a background, o el usuario cierra el device.

Caso de uso obvio: apps de retrato o video-selfie donde la persona quiere ver cómo va a salir mientras la posan.

Limitación del simulador — un elefante en el cuarto

El simulador del Duo NO simula cámaras. Puedes probar layout con ArrangementView, adaptar a .reservedRegions, y comportamiento vertical de toolbars — todo eso funciona. Pero cualquier flow que involucre AVCaptureDeviceDirectionCoordinator, virtual front camera, individual cameras, o el CameraCaptureAccessory requiere hardware real.

Con el device saliendo el 23 de octubre a $1,999 USD, eso significa que el testing definitivo de features de cámara pasa por hardware que probablemente no tengas hasta noviembre. Planea el sprint pensando que la primera integración es “estructural” (todo lo demás) y la segunda es “cámara” (cuando llegue el device).

Timeline concreto

18 sep 2026 — Xcode 27.1 beta salió (hoy hace un día). Bájalo desde Apple Developer Downloads si vas a soportar Duo.
16 oct 2026 — preorders de iPhone Duo abren.
23 oct 2026 — envíos empiezan. Corriendo iOS 27.1 público.

Cinco semanas es tiempo cerrado pero suficiente para las primeras 4 APIs (layout, hinge, arrangement, toolbars). Camera queda para cuando llegue el hardware.

Qué priorizar antes del 23 de octubre

Si tu app no hace nada de cámara: enfócate en Reserved Regions y Arrangement Views. Con eso resuelves el 90% de “mi app se ve razonable en el Duo”. Hinge API es opcional — úsalo si tu app tiene componente animado que gana con reaccionar al ángulo.

Si tu app sí hace cámara: agrega AVCaptureDeviceDirectionCoordinator desde ya, aunque no puedas probarlo — el código va a estar listo cuando el hardware llegue. Y evalúa si tu app se beneficia del CameraCaptureAccessory (mostrar en el display exterior mientras capturas desde el interior).

Si tu app no planea soportar Duo activamente: al menos compila contra iOS 27 SDK. Sin cambios de código, tu app corre en el Duo — pero se ve como iPhone regular estirado al canvas grande, sin aprovecharlo. Es el mínimo aceptable. El post de lanzamiento cubrió el resto.

Cierre de la serie

Con este cerramos los tres posts post-launch:

Xcode 27 Agent Skills — cambia cómo escribes código hoy.
Device Hub — cambia cómo pruebas tu app en simulador y hardware.
Ahora: iPhone Duo con Xcode 27.1 — cambia qué APIs necesitas antes del 23 de octubre.

El patrón de fondo es el mismo: Apple está armando un stack donde tu app corre en más devices, con más superficies, y con más formas de interacción (voz, agentes, cámara). Los tres cambios de esta semana empujan en esa dirección.