Designing for Foldables: Poses, Not Orientations

Android had foldables for years before Apple's iPhone Duo made the rest of the industry pay attention. That timing tells you something useful: this isn't a problem you can wait out. Foldables are a real, permanent category now, and the design pattern for handling them is different enough from standard mobile design that it's worth learning properly rather than improvising per-project.

Retire "orientation" from your vocabulary

Portrait and landscape describe a rectangle rotated 90 degrees. That's the entire model. It works because a standard phone only ever has two stable states. A foldable has far more: closed, fully open, held at a hinge angle anywhere between the two, propped in tent mode, propped in tabletop mode. None of those map cleanly onto "portrait" or "landscape," and trying to force them to is where most early foldable designs go wrong.

The replacement concept is a pose: a specific physical configuration of the device that implies a specific use context. A phone standing in tent mode on a desk implies hands-free viewing, most likely video or a call. The same phone held flat and fully open implies two-handed, close-range interaction. Same device, same screen real estate in some cases, completely different design requirements.

The framework: two size classes, three regions

The practical guidance that's emerged, and the one Apple is now pushing developers toward for the Duo, is simpler than the pose concept makes it sound: design for two size classes, compact and regular, rather than inventing a bespoke layout for every physical pose. Layer on top of that three reserved regions on the display: content that must always be visible regardless of fold state, content that can shift position across the hinge, and content that should hide entirely in constrained poses.

This does two things. It stops you from designing an unmanageable number of one-off layouts, and it forces an earlier, more useful conversation: which three or four things in this screen actually matter no matter how the device is held, and which are secondary.

Where this breaks down: framework gaps

If you're not designing native, know this before you commit a sprint to it: cross-platform frameworks are behind on foldable support. Flutter's fold-detection API currently returns nothing useful on some foldables regardless of hinge angle. React Native has no official API for it at all. Native SwiftUI and native Android both have dedicated, working APIs for this today. That gap won't last forever, but it's real right now, and it means "we support foldables" needs a follow-up question about which platform before anyone commits to a timeline.

The interaction pattern that actually matters

Static layout gets most of the attention in foldable design conversations, but the transition between poses is where users form their actual opinion of the experience. A layout that's technically correct in every pose but transitions jarringly between them will feel broken even when nothing is wrong. A layout that's slightly imperfect in an edge-case pose but transitions smoothly will feel considered. If you only have time to polish one thing, polish the transition, not the edge-case layout.

A short checklist before you ship anything foldable-aware

• Identify your three or four must-always-be-visible elements per screen, independent of pose.
• Design the compact and regular size classes as their own complete layouts, not scaled versions of each other.
• Prototype the transition between poses, not just the static end states.
• Confirm with engineering which platform APIs are actually available before you promise fold-aware behavior in a spec.
• Test the closed/outer-screen state as a real interface, not an afterthought. On the Duo it's larger than most current phone screens on their own.

Foldables reward the same instinct that good responsive web design always has: define what's non-negotiable first, then let everything else adapt around it. The device categories keep changing. That discipline doesn't.