iPhone Duo: un bug que el responsive arrastra hace años

El iPhone Duo sale el 23 de octubre de 2026 y casi toda la conversación web sobre él es sobre algo que Safari no expone: dónde está el pliegue. Abajo hay una pregunta más básica. El Duo no pone a prueba si tu sitio tiene breakpoints, los anchos donde el layout cambia. Pone a prueba si tu sitio sigue siendo responsive después de que ya cargó.

Casi todos construimos como si responsive fueran tres pasos: carga la página, algo detecta el tamaño, se renderiza el layout. Un aparato que cambia de tamaño en la mano pide otra forma. El tamaño puede cambiar en cualquier momento y la interfaz se adapta cuando pasa. No son el mismo producto, y el segundo es más raro de lo que a la industria le gusta admitir.

Por qué este aparato hace esa pregunta y no otra

Apple publica las dos pantallas. La externa es de 5,4 pulgadas a 1398 por 2034 píxeles, la interna de 7,6 a 1878 por 2670, y la página de producto habla de una relación de aspecto consistente entre las dos pantallas. El contenido que abriste en la pantalla chica y después desplegaste no necesita convertirse en otra cosa. Sobre todo, recibe más espacio.

Eso es lo que vuelve simple la prueba interesante. La pantalla pasa de 1398 a 1878 píxeles de ancho cuando el equipo se abre. Si el viewport, el área que la página tiene para dibujar, acompaña ese cambio con la página todavía abierta y no en una recarga, es justo lo que habrá que probar cuando llegue el aparato.

Acá va un reparo, y va acá y no al final. Apple todavía no publicó qué hace Safari con una página abierta en cada pose, y su documentación escrita, "Preparing your app for iPhone Duo", figura en la página para desarrolladores como que llega más adelante este mes. El comportamiento exacto todavía no se puede saber desde una fuente primaria, y esta nota no lo va a fingir. La forma del riesgo no depende de ese detalle.

Dónde un layout deja de ser responsive

Las fallas son aburridas, y por eso sobreviven. Un componente lee window.innerWidth una vez y se guarda el número. Un carrusel calcula sus dimensiones al inicializarse y nunca más. Un canvas o una superficie WebGL nunca redimensiona su buffer de dibujo. Un header define su estado según el breakpoint que resultó verdadero al cargar. Un script pregunta matchMedia() una vez y guarda la respuesta en lugar de reaccionar a ella.

Ese último caso tiene forma documentada. Mozilla describe a MediaQueryList como algo que soporta comparación inmediata y también por eventos, y la mitad por eventos es la que se saltea. matches es un booleano sobre un instante; change es cómo el navegador te avisa que se movió. Safari dispara ese evento desde la versión 14.

Eso apunta a un lugar más útil. Las principales herramientas para construir layouts que reaccionan a cambios de tamaño están disponibles hace años. ResizeObserver, que informa los cambios de dimensión de un elemento en vez de obligarte a medirlos, llegó en Safari 13.1. Las container queries, que estilan un elemento según el tamaño de su contenedor y no el del viewport, están en Safari desde la versión 16. En muchos casos el problema no es la plataforma sino una decisión de layout que quedó fijada en JavaScript al cargar, donde el CSS la habría reevaluado gratis.

Apple le está diciendo exactamente esto a los devs nativos

El consejo que Apple le da a sus propios desarrolladores es el argumento de esta nota, con sus palabras. Su tech talk sobre preparar una app dice que los mejores layouts son adaptativos a lo largo de un continuo de dispositivos y que los buenos evitan suponer tamaños de pantalla. La charla de diseño es más directa: evitá anchos fijos, breakpoints o cualquier métrica atada a una pantalla puntual, y diseñá tu app para que sea libremente redimensionable.

El pliegue en sí no es cosmético, y conviene corregir la versión perezosa de esa afirmación. Apple documenta consecuencias espaciales reales, incluido un comportamiento que corre los elementos interactivos a un costado cuando el equipo está parcialmente plegado, más reserved regions que cubren la bisagra y las cámaras y que un layout nativo puede consultar. La web no recibe nada de eso. La Viewport Segments API existe para responder cómo evitar que el pliegue físico esconda contenido, y los datos de compatibilidad la ponen en Chrome desde la versión 138, con Firefox y Safari sin soporte. La posición pública de WebKit sobre la propuesta está abierta desde el 6 de marzo de 2024. Su único comentario, de abril de 2025, pregunta si hay novedades. Nadie contestó.

Esta prueba la podés hacer hoy

Nada de esto necesita un teléfono de 1.999 dólares. Abrí tu propio producto en un navegador de escritorio y movele el ancho a la ventana, con violencia, sin refrescar. Después buscá:

• Todo lo que se midió una vez al cargar y quedó cacheado.
• Decisiones de layout viviendo en JavaScript que el CSS podría reevaluar solo.
• Estado fijado por el breakpoint que resultó verdadero primero.
• Componentes dimensionados por el dispositivo cuando deberían serlo por su contenedor.

Lo que se rompa durante esa prueba no es un problema de plegables. Es una suposición que siempre estuvo ahí, y un aparato que cambia de forma en la mano simplemente la vuelve mucho más difícil de ignorar. Responsive nunca debió significar que una página se vea bien en varios tamaños. Significa que la página puede moverse entre esos tamaños sin romperse, y nuestra lectura es que buena parte de la web viene fallando esa segunda mitad hace una década.

Fuentes

• Apple, páginas de producto y especificaciones del iPhone Duo, y la página para desarrolladores Get ready for iPhone Duo, consultadas el 17 de septiembre de 2026.
• Apple tech talks, "Design for iPhone Duo", "Prepare your app for iPhone Duo" y "Strike a pose with adaptive layouts on iPhone Duo", transcripciones consultadas el 17 de septiembre de 2026.
• MDN Web Docs: Viewport Segments API, MediaQueryList, ResizeObserver y container queries, consultadas el 17 de septiembre de 2026.
• WebKit, issue 327 de standards-positions, abierta desde el 6 de marzo de 2024.