Beyond Phone-Only Design
The era of designing for a single phone screen size is over. In 2026, your app must work across small phones (iPhone SE, compact Android), large phones (iPhone 16 Pro Max, Galaxy S26 Ultra), foldables in folded and unfolded states, tablets (iPad, Android tablets), and desktop modes (Stage Manager, Samsung DeX).
Users expect your app to use the available space intelligently, not just stretch a phone layout onto a 12-inch screen. This requires understanding responsive and adaptive design.
Responsive vs Adaptive
Responsive layout adjusts fluidly to any screen width. Elements reflow, resize, and reposition based on available space. A responsive text block gets wider or narrower as the window changes.
Adaptive layout switches between distinct configurations at specific breakpoints. Below 600dp shows a phone layout. Above 600dp shows a different tablet layout. The layouts are different designs, not scaled versions of each other.
Modern mobile apps use both. Content areas are responsive (text reflows, images resize), while structural layouts are adaptive (list-detail split appears on wider screens).
Window Size Classes
Both Apple and Google have adopted window size classes as the standard for categorizing screen widths:
| Size Class | Width | Typical Devices | Layout Strategy |
|---|---|---|---|
| Compact | < 600dp | Phones (portrait) | Single column, stack navigation |
| Medium | 600-840dp | Foldables, small tablets | Optional two-pane, navigation rail |
| Expanded | > 840dp | Tablets, desktop, foldables unfolded | Multi-pane, permanent navigation |
iOS: UIKit uses horizontal/vertical size classes. SwiftUI provides horizontalSizeClass and verticalSizeClass environment values.
Android: Jetpack Compose offers WindowSizeClass through material3-window-size-class. XML layouts use resource qualifiers like -w600dp.
Layout Patterns by Size Class
Compact (Phone): Single column layout, bottom tab bar, full-screen content, sheets and modals for secondary content, collapsing toolbars for maximum content area.
Medium (Foldable/Small Tablet): Optional list-detail split (30/70 or 40/60 ratio), navigation rail instead of bottom tabs, supporting panel alongside main content.
Expanded (Tablet/Desktop): Persistent navigation drawer or rail, list-detail as default, two or three pane layouts, full toolbar with text labels, hover states for pointer input.
Foldable-Specific Considerations
The physical fold creates a visible seam. On Galaxy Z Fold, the fold runs vertically in unfolded mode. Avoid placing critical interactive elements on the fold line. Jetpack WindowManager and Samsung Flex Mode API provide fold position, state, and hinge angle information.
When a user unfolds their device, the app should seamlessly transition to the larger layout without losing state. Folding should preserve context. Your layout system must handle runtime size changes without resetting navigation stacks or losing form input.
Building Responsive Layouts
iOS: Auto Layout uses constraints defining relationships between views. SwiftUI uses HStack, VStack, LazyVGrid, and GeometryReader with containerRelativeFrame for proportional sizing.
Android: Compose uses Row, Column, LazyVerticalGrid, BoxWithConstraints, and Modifier.weight(). XML uses ConstraintLayout with guidelines and barriers.
React Native: Flexbox handles responsive sizing. useWindowDimensions hook provides breakpoint detection.
Flutter: LayoutBuilder and MediaQuery provide screen information. The material library adaptive scaffold handles navigation switching.
Common Layout Mistakes
- Fixed pixel widths instead of proportional values
- Ignoring landscape mode on phones
- Letterboxing (centering a phone layout with bars on tablets)
- Assuming aspect ratio when foldables can be nearly square
- Not testing on real devices where fold transitions reveal edge cases