How to design for foldable screens without stretching the interface

With the arrival of the iPhone Duo, foldable screens stop being an Android niche and UX Collective proposes a standard: think in terms of available space, not device model.

The decision that got harder to ignore

Since 2019, with the Galaxy Fold, foldable screens were a product problem that was easy to postpone: few people used them, the audience was almost entirely Android, and the return on the design/engineering investment for such a specific form factor never added up. Designer Allie Paschal sums it up well in UX Collective: "it's hard to get design and engineering buy-in when so few people will use the app in such a specific format".

What changes this equation is Apple entering the game with the iPhone Duo. According to the source, which cites a Yahoo Finance projection, the device should take 25% of the foldable market by the end of 2026, with a tendency to grow from there. That means the product decision of treating foldables as an edge case loses its footing, including outside the US: with Apple joining the dispute, the trend is for the foldable user base to grow in markets outside American territory as well.

The mistake the source calls "stretching"

The most common temptation, when the team finally decides to deal with foldables, is to simply let the mobile layout grow to fill the larger screen when the device opens. Paschal uses a direct example: the notification settings in United's app take up the entire screen of an open Google Pixel Pro Fold, with buttons and text stretched with no need.

Android is explicit about this in its adaptive layout guidelines: the recommendation is to use panes and maximum content widths, not to let the component grow until it fills the space. In practice, that means:

• Defining maximum content widths and larger gutters between elements
• Using multiple columns and supporting panes
• Avoiding long lines of text (the reference is around 50 characters per line)
• Avoiding cards, modals, bottom sheets and images that are too large
• Avoiding full-width buttons on a tablet screen

The central point for whoever designs product: the problem isn't the screen getting bigger, it's the information hierarchy not changing when the space changes. A button that takes up the full width of a phone makes sense because it's the only action possible on that screen; the same button stretched on a tablet screen doesn't gain importance, it only gains empty space around it.

Think in available window, not device model

The right question, according to the source, is not "how does this look on the Galaxy Z Fold or the iPhone Duo", but "what does this experience need to do when the available window gets wider, narrower, taller or split". It's a mindset shift: instead of designing for a specific device, you design for size classes.

On iOS, Apple defines this with size classes: Compact (narrow horizontal, short vertical) and Regular (wide horizontal, tall vertical), documented in Apple's new foldable guidelines. On Android, the equivalent concept is window size classes: Compact (narrow phone), Medium (larger phone or open foldable) and Expanded (tablet or large foldable), described in the Android documentation for adaptive windows.

Add to that the concept of reserved regions (iOS) and window insets (Android): physical areas of the device, such as the hinge and the internal/external cameras, that reduce the space actually usable. Ignoring these areas is the reason why buttons, form fields, dialogs and menus shouldn't be positioned over the hinge: besides the physical crease being visible on many models (the source cites the Galaxy Z Fold 4 hinge as documented by The Verge), placing a critical control there creates touch friction.

Panes replace full screen: the "panes" model

The mental model the source proposes to organize all of this is to think in panes: a traditional phone has one primary pane; an open foldable or a tablet accommodates two or more related panes. The most common patterns:

• List → detail: search results, messages, settings. That's the case of Slack on the open iPhone Duo, shown in Apple's own images: closed, the app follows the list pattern with a tap to open the detail; open, list and detail appear side by side, with no need to navigate.
• Navigation → content: when persistent navigation starts to be worth it on a larger screen.
• Primary content → supporting content/controls: useful for media, maps or forms.

Spotify and Airbnb appear in the source as examples of apps that adapt across formats: Spotify's navigation and bottom sheet change position and width between the closed and open Pixel Pro Fold, without resetting the user's state. That last point is what separates a good adaptive redesign from a bad one: the transition from folded to open needs to preserve context, with no full-screen reload, no loss of scroll position and no form field reset.

Device state, not just screen size

The part that usually escapes those who only think about "big and small screens" is that a foldable has different states of use, called poses on iOS and postures on Android, that go beyond open/closed:

• Closed: regular phone behavior, with compact navigation and one-handed interaction.
• Open (flat): use of the book/shell format, with two panes.
• Half-open on a table (tabletop): folded in portrait, with an upper region for content (video, for example) and a lower one for controls. The source cites Netflix as a plausible case: video on top, playback controls below.
• Half-open in book mode (book): folded in landscape, creating two regions side by side, good for reading or for running two simultaneous experiences.

The practical point here is about product, not just UI: not every experience needs to support every state. The source is clear that tabletop mode is a bonus, not an obligation, more relevant for those who have video or games at the core of the product. That spares the team from trying to cover a state that adds no real value to the flow.

What this changes for those designing product in Brazil

The question worth taking to your own roadmap is not "does our app work on a foldable", but: how many of our components today assume a fixed screen width, instead of reacting to a size class? Bottom sheets, bottom navigation and full-width cards are the first suspects, because they are the most common mobile patterns and the ones that suffer the most when simply stretched.

The checklist the source suggests pressing on before closing the design is direct: does the content have a defined maximum width? Do buttons and dialogs avoid the hinge? Does the navigation preserve the user's position when folding or unfolding? None of these questions requires buying a physical foldable: Android Studio itself has a Virtual Device Manager with Pixel devices in different formats to simulate this still at the prototyping stage.

With Apple entering this market and the projection of 25% of the foldable market by 2026 cited by the source, the argument that "few users use this" loses force faster than most roadmaps are prepared to admit.

Source 1: UX Collective (https://uxdesign.cc/please-dont-stretch-your-app-for-foldables-a62f1f8230ac?source=rss----138adf9c44c---4)

Title: Please don’t stretch your app for foldables

URL Source: https://uxdesign.cc/please-dont-stretch-your-app-for-foldables-a62f1f8230ac?source=rss----138adf9c44c---4

Published Time: 2026-09-17T21:34:11Z