Adaptive layout is a design approach in which an interface switches between distinct, purpose-built layouts depending on the available screen space, orientation, device posture and input method. In mobile UX it determines how one app presents itself on a compact phone, a large phone in landscape, a foldable that opens mid-session and a tablet in a split-screen window.
Unlike a single layout that simply stretches, an adaptive layout changes structure at defined thresholds: navigation may move from a bottom bar to a side rail, a list may gain a detail pane, and content may reflow into columns. The goal is that each form factor receives an arrangement that genuinely suits it rather than a scaled copy of the phone design.
How adaptive layout selects a layout
An adaptive layout works by measuring the app’s current window and mapping it to a small set of size classes or breakpoints, each linked to a prepared layout. The decisive input is the window size, not the physical screen size, because apps on modern phones and tablets run in split-screen, slide-over, freeform windows and pop-up views.
The system re-evaluates the size class whenever a configuration change occurs, such as rotation, unfolding a foldable, resizing a window or connecting an external display. The app then swaps the relevant parts of the layout while preserving user state, such as the scroll position, the selected item and any text being typed.
The main platform mechanisms that express these categories are shown below.
| Platform concept | Categories | Typical thresholds |
|---|---|---|
| Android window size classes | Compact, medium, expanded, large, extra-large | Width below 600 dp, 600-839 dp, 840 dp and above |
| Apple size classes | Compact and regular | Defined per width and height, not in points |
| CSS media and container queries | Custom breakpoints | Commonly near 600, 900 and 1200 CSS pixels |
| Foldable posture APIs | Flat, tabletop, book | Based on hinge angle and fold orientation |
Adaptive layout compared with responsive design
Adaptive layout and responsive design are related but not identical: responsive design reflows content fluidly across a continuous range of widths, whereas adaptive layout switches between discrete layouts at chosen thresholds. In practice most mobile apps combine both, using fluid sizing inside each layout and adaptive switches between them.
| Strategy | Core behavior | Strength | Weakness |
|---|---|---|---|
| Adaptive layout | Distinct layouts per size class | Optimal structure per device | More layouts to design and test |
| Responsive design | Fluid reflow on a continuous scale | Smooth behavior at any width | Structure may stay phone-like on tablets |
| Fixed layout | One size, letterboxed or scaled | Simple to build | Wasted space and poor ergonomics |
| Scaling layout | Proportional enlargement | Visual consistency | Oversized controls and sparse content |
The distinction matters for planning. A responsive approach answers how elements resize, while an adaptive approach answers which elements appear and where, which is why adaptive decisions belong in early UX work rather than late visual polish.
Canonical adaptive layout patterns
Most adaptive mobile interfaces rely on a few canonical patterns that reorganize content predictably as space grows. Reusing these patterns keeps behavior familiar to users across apps and reduces design effort.
| Pattern | Compact width | Expanded width |
|---|---|---|
| List-detail | List and detail on separate screens | List and detail side by side |
| Supporting pane | Secondary content in a sheet | Secondary content in a permanent side pane |
| Feed | Single column of cards | Multi-column grid of cards |
| Navigation | Bottom navigation bar | Navigation rail or persistent drawer |
The navigation switch is the most visible example. Bottom navigation suits one-handed use on a phone, but on a wide tablet it pushes controls far from the hands holding the device, so a side navigation rail is the usual expanded-width choice. Safe area insets and gesture navigation zones still apply in every layout and must be respected after each switch.
Designing and implementing adaptive layouts
Effective adaptive layouts begin with content priorities rather than devices. Designers identify which content must always be visible, which can move to a secondary pane and which can be hidden behind an action, then define layouts for the compact, medium and expanded classes.
- Base decisions on window size, never on device model or a phone-versus-tablet flag.
- Limit line length to roughly 45-75 characters for body text in wide layouts.
- Keep touch targets at least 44 points on iOS or 48 dp on Android in every layout.
- Preserve state across switches, including selection, scroll position and form input.
- Support keyboard, mouse and stylus on larger layouts, where these inputs are common.
Implementation relies on platform tools such as Jetpack Compose window size classes, SwiftUI size class environment values, Auto Layout trait collections and CSS container queries. Container queries are especially useful because they let a component adapt to the space of its own container rather than the whole viewport.
Common mistakes in adaptive layout
Most adaptive layout failures come from testing only on standard phones and assuming the window equals the screen. The following symptoms are typical in review and quality testing.
| Symptom | Likely cause | Fix |
|---|---|---|
| Stretched phone layout on tablets | Only one layout defined | Add medium and expanded layouts |
| Lost input after rotation or unfolding | State tied to destroyed views | Store state in a lifecycle-aware model |
| Wrong layout in split-screen | Logic based on device type | Use current window size classes |
| Controls under camera cutout or hinge | Insets and fold area ignored | Apply safe area and posture data |
| App locked to portrait on large screens | Forced orientation setting | Allow rotation and resizing |
Recent Android versions increasingly ignore orientation and resizability restrictions on large screens, so apps that relied on a locked portrait layout now need a genuine adaptive design.
The idea in brief
An adaptive layout means an app rearranges itself to fit the screen it is on. On a small phone it shows one thing at a time. On a tablet or an opened foldable it may show a list on the left and the details on the right, because there is room for both.
Think of a restaurant that seats people differently depending on the group. A couple gets a small table, a large family gets a long table, and nobody is asked to squeeze or spread out awkwardly. The content stays the same, but the arrangement changes so that each screen is comfortable to use.
A practical scenario
A regional bank’s mobile team notices that a growing share of customers open its app on tablets and foldables, where the phone layout appears as a stretched single column with the bottom navigation bar spread across a wide screen. Statements and transaction details require constant back-and-forth navigation.
The team defines three layouts based on Android window size classes. Compact windows keep the existing phone design. Medium windows show the account list with a larger detail sheet. Expanded windows use a navigation rail and a list-detail layout, so selecting a transaction shows its details beside the list. Unfolding a foldable during a session switches layout without losing the selected account.
After release, the number of navigation steps to review a transaction drops, and accessibility testing confirms that touch targets and text sizes remain consistent in every layout.