Foldable & Dual-Screen Design

The full lesson

Foldable and dual-screen devices — like the Samsung Galaxy Z Fold series and the Microsoft Surface Duo — have moved from curiosity to a real share of the premium Android market. They don’t fit the standard mobile/tablet/desktop mental model. A single device can act as a compact phone, a small tablet, or a two-pane productivity tool — sometimes all in one session, sometimes in one gesture.

To design well for foldables, you need to learn four new ideas: postures, the hinge, the seam, and window continuity.

Why Foldables Break Conventional Responsive Design

The standard responsive toolkit — fixed breakpoints at 375, 768, and 1024 px, a 12-column grid, viewport-only media queries — was built for devices with static sizes. A foldable can jump between two very different viewport widths without the user ever touching the browser. The CSS viewport changes the instant the device unfolds, and the breakpoint it lands on may be in the middle of your tablet range, yet the experience is nothing like holding a tablet.

Three mismatches cause the most failures:

• The hinge / seam. Content near the fold axis may be physically hidden or visually split. A button centered across the seam lands right on the hinge — an interaction dead zone.
• Posture-driven intent. A person reading in book mode (both screens side by side) has different goals than the same person with the device flat on a table. Viewport width alone can’t capture this difference.
• Continuity between states. When someone unfolds mid-task, the interface should not feel like a hard reload. Scroll position, focus, and form state all need to survive the transition.

The Device Window Management API and CSS Spanning

The key CSS tool for foldable-aware layouts is the env() variable family, paired with the viewport segments specification from the W3C CSS Working Group.

These are the main environment variables:

Variable	Description
env(fold-top)	Distance from the top of the viewport to the top edge of the fold area
env(fold-left)	Distance from the left of the viewport to the left edge of the fold area
env(fold-width)	Width of the fold area itself (the hinge)
env(fold-height)	Height of the fold area

You use these with the @media (screen-spanning) query. As of 2026, stable syntax in Chromium-based browsers (including Samsung Internet and Edge on foldables) looks like this:

@media (screen-spanning: single-fold-vertical) {
  .app-layout {
    grid-template-columns:
      env(fold-left)
      env(fold-width)
      calc(100vw - env(fold-left) - env(fold-width));
    grid-template-areas: "primary hinge secondary";
  }

  .hinge-column {
    grid-area: hinge;
    /* visually empty — content avoids the seam */
  }
}

screen-spanning: single-fold-vertical targets a vertical fold (left pane / right pane, landscape book mode). single-fold-horizontal targets a horizontal fold (top pane / bottom pane, tent or clamshell tabletop mode).

JavaScript: The Window Segments API

For richer posture detection, the Window Segments API (also called the Visual Viewport Segments API) exposes each screen segment as a DOMRect. This lets you position React portals, floating panels, or tooltip anchors entirely within one physical screen:

if ("getWindowSegments" in window.visualViewport) {
  const segments = window.visualViewport.getWindowSegments();
  if (segments.length === 2) {
    const [left, right] = segments;
    // Position primary content in left.x / left.width
    // Position secondary panel in right.x / right.width
  }
}

Because this API reflects live device state, listen for the resize event on window.visualViewport and re-query segments after each fold or unfold.

Postures and Their Design Implications

Devices fold in more ways than a simple open/closed toggle. Here are the four postures that matter most for layout decisions:

Posture	Physical state	Typical intent
Closed / compact	Folded shut, single screen active	Quick tasks, glanceable content, notifications
Open book	Fully open, both screens active side by side	Multitasking, reading, compare views
Tent	Hinged at roughly 270°, standing on edges	Passive viewing, video, shared table use
Tabletop / flat	Fully flat on a surface, hinge horizontal	Input-heavy tasks, gaming, productivity

Designing for posture goes beyond layout. Consider each one:

• Closed state: This is effectively a compact phone. Your mobile-first layout must work flawlessly at the closed screen dimensions — often around 320–380 px wide, narrower than a typical phone.
• Open book: This is the main opportunity for a true two-pane experience. Follow a primary/companion pattern rather than simply widening a single column.
• Tent and tabletop: The top half sits above the fold axis; the bottom half sits below it. Controls should move to the bottom pane, and content to the top. Samsung calls this “Flex Mode.” Most apps ignore this posture entirely.

Designing the Two-Pane Experience

Opening a foldable should feel like gaining a second monitor, not stretching a phone screen. The most effective two-pane patterns are:

Primary / detail (list-detail) A list or navigation goes on the left pane; detail content goes on the right. This is well-supported by Android Jetpack’s SlidingPaneLayout and by iOS Split View semantics. On the web, a CSS Grid with the hinge column as a gap achieves the same result.

Companion / context The left pane shows the main task; the right pane shows persistent contextual information — a map alongside a restaurant list, a reference document alongside a note editor, a palette alongside a canvas. This pattern is unique to the form factor. You can’t replicate it on a single screen without hiding information.

Dual input / mirrored Both panes show the same content from different angles. This is mainly useful for games, shared productivity (two people at one device), or A/B design review. Use it sparingly.

Continuity: Surviving the Fold Transition

The fold/unfold event is an instantaneous viewport resize. Without explicit handling, apps re-render from scratch and lose scroll position, focused elements, and form state. Here is what continuity requires:

1. Preserve scroll position. Store the scroll offset in component state or a sessionStorage key before the viewport resizes, then restore it after. React’s useLayoutEffect fires synchronously after DOM mutations, making it the right hook for this.
2. Preserve focus. When a layout reflow moves a focused button off-screen or into a new grid column, document.activeElement loses focus. Explicitly re-focus the element by ref after the resize event settles.
3. Animate the transition. A 150–200 ms layout transition using CSS transition: grid-template-columns or the View Transitions API’s startViewTransition() prevents a jarring reflow snap. Use ease-out easing — the user already initiated the physical gesture, so the animation just needs to smooth the reflow.
4. Don’t reset state. Avoid routing changes triggered by viewport width alone. A user reading an article in compact mode should not be navigated to a different route when they unfold the device.

// View Transitions API for fold continuity
document.addEventListener("visibilitychange", () => {
  if (!document.hidden && "startViewTransition" in document) {
    document.startViewTransition(() => {
      applyFoldLayout();
    });
  }
});

Accessibility on Foldables

WCAG 2.2 does not yet have a criterion specific to foldables, but several existing criteria apply directly:

• 1.3.4 Orientation — Do not lock orientation. On a foldable, the user changes orientation by folding, not by rotating. Locking to portrait prevents the open-book layout entirely.
• 2.5.5 Target Size (AA: 24x24 px minimum; AAA: 44x44 px) — Touch targets near the hinge are harder to hit precisely. Increase minimum target size near the fold axis, or ensure no primary action sits within 12 px of the seam.
• 1.4.10 Reflow — Content must reflow at 400% zoom without horizontal scrolling. On a narrow closed screen, this threshold arrives quickly. Test reflow at closed-state dimensions.
• Focus management — Screen reader users navigating with a physical keyboard or switch access won’t receive any visual fold cue. When the layout changes, announce it via an aria-live region: “Layout updated to two-pane view.”

Testing Foldable Layouts

Testing on real hardware is ideal, but not always practical. Here are reliable alternatives:

Android Emulator foldable profiles — Android Studio ships with emulator profiles for the Galaxy Z Fold 6, Pixel Fold, and Surface Duo. These emulate the screen-spanning media feature accurately and let you simulate fold/unfold events via the virtual sensor panel.

Chrome DevTools device toolbar — Custom device dimensions can approximate closed and open states, but the DevTools toolbar does not emulate env(fold-*) variables. Use it for layout checks only, not for seam-aware feature testing.

Samsung Remote Test Lab — Samsung offers free access to real foldable devices via a browser-based remote session. Latency is noticeable, but the hardware behavior is accurate.

Container query stress tests — Write unit tests for your layout components at the exact dimensions of major foldable screens (closed: ~360 px, open: ~900 px, Surface Duo single: 540 px). Use the Storybook viewport add-on to cycle through these during design review.

The Outdated Approach: Just Add a Breakpoint

The outdated response to foldables is to add a breakpoint at the device’s unfolded width and serve a wider single-column layout. This fails in three ways: it ignores the hinge entirely (content falls across the seam), it doesn’t handle the closed state’s narrow dimensions, and it treats two distinct screens as one stretched display.

Rigid 12-column grids make hinge-aware layouts almost impossible to implement cleanly. The grid columns don’t align with the physical structure of the device. Intrinsic CSS Grid — where column widths are defined by content and environment variables rather than fixed fractions — handles foldable geometry far more naturally.