How to Build Apps for Foldable Devices: Adaptive UI Guide

Foldable phones have crossed the threshold from novelty to mainstream. Samsung has shipped over 50 million Galaxy Z Fold and Z Flip units since launch. Google's Pixel Fold brought foldable hardware into the Pixel ecosystem. Motorola, OnePlus, and Honor all have foldables on the market. The installed base is large enough that ignoring these devices means leaving real users with broken or suboptimal experiences.

The fundamental challenge is that foldable devices break a core assumption baked into mobile development: that a screen size is fixed for the lifetime of an app session. On a foldable, the display can change dimensions at any moment. A user unfolds their Galaxy Z Fold 6 mid-scroll, and the viewport jumps from 374dp to 768dp in under half a second. Your app either adapts gracefully or it renders a stretched phone layout on a tablet-sized screen with wasted space and broken touch targets.

Responsive design is a starting point, but it is not enough. Foldable UI demands awareness of physical hardware features like the hinge, the fold angle, and the device posture. It also requires continuity: the app must preserve user state, scroll position, and in-progress interactions across configuration changes. This guide covers the specific APIs, design patterns, and testing strategies you need to build apps that feel native on foldable hardware.

Before writing any layout code, you need a mental model of the physical states a foldable device can occupy. Each posture creates a distinct user context with different expectations for how the app should behave.

Folded (Cover Screen)

When the device is closed, the user interacts with the outer cover display. On the Galaxy Z Fold 6, that is a 6.3-inch, 968x2316 screen. On the Pixel Fold, it is 5.8 inches at 1080x2092. These are essentially standard phone screens, and your app should render a conventional single-column phone layout. The key consideration here is that the cover screen is often narrower than a typical phone, so layouts that assume a minimum width of 390dp may clip content.

Fully Unfolded (Flat)

When the device is fully open, the inner display activates. The Galaxy Z Fold 6 inner screen is 7.6 inches at 1856x2160, and the Pixel Fold inner screen is 7.6 inches at 2208x1840. This is tablet territory. Your app should transition to a multi-pane layout: a list-detail view, a navigation rail instead of a bottom bar, or a two-column content arrangement. Apps that simply stretch a phone layout to fill this space look amateurish and waste the screen real estate users specifically bought the device to get.

Half-Folded (Flex Mode / Table-Top Mode)

This is the posture that makes foldables genuinely unique. The device sits at an angle, typically between 60 and 120 degrees, with the hinge acting as a natural divider. The top half of the screen becomes a viewfinder or content area, and the bottom half becomes a control surface. Think of a laptop form factor. Camera apps use this naturally (viewfinder on top, shutter button on bottom), but the pattern works for video calls, media players, recipe apps, and anything where separating content from controls improves ergonomics.

Tent Mode and Other Postures

Some devices support tent mode (folded outward like an inverted V) and presentation mode. These are less common in real-world usage but matter for media consumption apps and kiosk-style experiences. The Samsung Flex Mode API exposes these states so you can respond accordingly.

Understanding these postures is not optional. Each one maps to a different layout strategy, and users switch between them fluidly throughout a session. Your app needs to handle every transition without losing context, crashing, or rendering a broken layout.

Google's Jetpack WindowManager library is the foundation for foldable-aware development on Android. It provides a hardware-abstracted API that lets your app respond to display features (the hinge, fold, and screen boundaries) without coupling to any specific device manufacturer's SDK.

Setting Up WindowManager

Add the dependency: implementation "androidx.window:window:1.3.0". The core class is WindowInfoTracker, which emits a flow of WindowLayoutInfo objects whenever the display configuration changes. Call WindowInfoTracker.getOrCreate(this).windowLayoutInfo(this) to get a Flow that emits on every fold state change, window size change, or posture transition. Each emission contains a list of DisplayFeature objects describing the physical characteristics of the current display.

Detecting the Hinge and Fold State

The FoldingFeature class (a subclass of DisplayFeature) tells you everything you need to know about the hinge. Key properties include state (FLAT or HALF_OPENED), orientation (HORIZONTAL or VERTICAL), isSeparating (whether the fold creates a visual separation), and bounds (the pixel coordinates of the fold line). When state is HALF_OPENED, the device is in flex mode. When it is FLAT, the device is fully unfolded. When you receive no FoldingFeature at all, the device is either folded to the cover screen or is not a foldable.

Window Size Classes

Jetpack WindowManager also introduced WindowSizeClass, which categorizes the current window into Compact, Medium, or Expanded width and height buckets. This is the replacement for the old sw600dp resource qualifier approach. A Compact width maps to a phone layout. Medium maps to a large phone or small tablet. Expanded maps to a tablet or fully unfolded foldable. You use these size classes to pick your layout strategy at a high level, then refine with FoldingFeature data for hinge-aware adjustments.

If you are working with Jetpack Compose, the window:window-core artifact provides composable-friendly APIs. The currentWindowAdaptiveInfo() function gives you size classes directly in your composition, and you can observe folding features with WindowInfoTracker collected as State. This makes it straightforward to build Compose layouts that dynamically switch between single-pane and multi-pane configurations.

Knowing the fold state is only half the problem. The real engineering challenge is building layouts that adapt smoothly and preserving user state across transitions. This is what separates apps that "support foldables" from apps that feel genuinely native on foldable hardware.

The List-Detail Pattern

The most common adaptive pattern for foldables is list-detail. On a compact screen, you show the list. When the user taps an item, you navigate to the detail view. On an expanded screen, you show both side by side. The ListDetailPaneScaffold in Material 3 Adaptive handles this out of the box. It reads window size classes and folding features, then automatically arranges panes. When a vertical fold (hinge) is present, it positions the list on one side and the detail on the other, aligned to the hinge boundary so content does not render across the fold line.

For custom implementations, the key principle is: never render interactive content across the hinge. The fold area on most devices is a 1-4 pixel physical gap where content is obscured or distorted. Use the FoldingFeature.bounds to calculate a keep-out zone and position your panes on either side.

Table-Top Mode Layouts

When the FoldingFeature reports HALF_OPENED with a HORIZONTAL orientation, the device is in table-top mode. Split your layout at the hinge line: content above, controls below. For a video player, the video renders in the top half and playback controls sit in the bottom half. For a camera app, the viewfinder fills the top and the shutter, gallery, and mode switches fill the bottom. This is not just a nice-to-have. Users physically set their device on a surface in this posture, and they expect the app to respond intelligently.

Continuity: Preserving State Across Fold Changes

When a user unfolds their device, the Activity may be destroyed and recreated (depending on your configuration). If your app loses the user's scroll position, form input, video playback timestamp, or navigation state, the experience feels broken. There are three strategies to handle this.

First, declare android:configChanges="screenSize|screenLayout|smallestScreenSize" in your manifest to prevent Activity recreation. Your app then receives onConfigurationChanged callbacks and can re-layout without losing state. This is the simplest approach but requires careful handling of resource reloading.

Second, use ViewModel and SavedStateHandle to persist state across recreation. ViewModels survive configuration changes, and SavedStateHandle persists across process death. Combined with Compose's rememberSaveable, this gives you durable state across every fold transition.

Third, for media apps, use MediaSession and MediaController from the Jetpack Media3 library. These decouple playback state from the UI lifecycle entirely, so folding and unfolding has zero impact on playback.

The ViewModel approach works best for most apps. It aligns with modern Android architecture patterns and covers the widest range of use cases. If you are weighing native versus cross-platform for your foldable app, our native vs. cross-platform comparison covers the tradeoffs in detail.

Foldable devices are not just about adaptive single-app layouts. They are productivity tools, and Android's multi-window capabilities take on new importance on a 7.6-inch inner display. Your app needs to function correctly alongside other apps in split-screen and freeform modes.

Multi-Window Support

Starting with Android 12, all apps are resizable by default. You cannot opt out on large screens. The minimum window size in split-screen on a Galaxy Z Fold is roughly 320dp wide. If your layouts assume 360dp or higher, elements will clip or overlap. Declare android:resizeableActivity="true" explicitly and set reasonable android:minWidth and android:minHeight values in your activity's layout attributes.

Drag and Drop Between Apps

On a foldable in multi-window mode, users expect to drag content between apps: photos from the gallery into a messaging app, text from a browser into notes, files into email. Implement this through Android's DragEvent system with View.OnDragListener on drop targets, or use Modifier.dragAndDropSource and Modifier.dragAndDropTarget in Compose. Most apps still skip drag and drop, so adding it makes your app feel premium on foldable hardware.

Multi-Resume

Since Android 10, all visible apps in multi-window mode remain in the RESUMED state simultaneously. Ensure your app does not assume that onPause means the app is no longer visible. Use lifecycle-aware components and check Lifecycle.State.STARTED rather than RESUMED for visibility logic.

Building robust multi-window support affects your overall project scope and timeline. For a realistic breakdown of mobile project costs, see our guide on how much it costs to build a mobile app.

Not every foldable app needs to be built natively. React Native and Flutter both offer paths to foldable support, though the maturity and approach differ significantly.

React Native Foldable Support

React Native does not have first-party foldable APIs, but the community has filled the gap. The react-native-jetpack-window-manager package wraps Google's Jetpack WindowManager and exposes fold state, hinge bounds, and window size classes to JavaScript. You collect fold state updates and conditionally render different layouts based on the posture.

React Native's Flexbox layout system handles width changes naturally during fold/unfold transitions. The main challenge is detecting the hinge position to avoid rendering content across it. With the New Architecture (Fabric and TurboModules), native module communication is synchronous through JSI, so fold state updates reach your JavaScript layout logic with minimal latency. If you are considering a React Native approach, our React Native New Architecture guide explains the performance benefits in depth.

Flutter Foldable Support

Flutter has stronger built-in foldable support. The framework's MediaQuery reports display features including hinge geometry through MediaQueryData.displayFeatures. You can query hinge bounds and fold state directly without any third-party dependency. Flutter's DisplayFeature class gives you the bounds, type (fold, hinge, or cutout), and state (half-opened, flat, or unknown) of each physical display feature.

The dual_screen plugin provides TwoPane widgets that handle the common list-detail pattern automatically, splitting content across the hinge boundary. Flutter's Impeller rendering engine draws every pixel directly, so it does not rely on platform UI components that might not understand foldable geometries. This is an advantage for custom layouts.

Which Cross-Platform Framework for Foldables?

If foldable support is a primary requirement, Flutter currently has the edge due to built-in display feature APIs and the dual_screen plugin maturity. React Native can achieve the same results but requires more native bridge work and community packages. Both frameworks handle the layout adaptation well once you have the fold state data flowing into your component tree. The deciding factor is usually your team's existing expertise and the rest of your app's requirements, not the foldable support specifically.

You cannot ship a foldable app with confidence unless you test across postures, transitions, and edge cases that do not exist on traditional devices. The good news: you do not need a drawer full of foldable hardware to test effectively.

Android Studio Emulators

Android Studio ships with foldable emulator profiles for the 7.6-inch Foldable and 8-inch Foldable configurations. These emulators simulate the hinge, fold angle, and posture transitions. In the Extended Controls panel, the Virtual Sensors tab lets you adjust the fold angle in real time, triggering HALF_OPENED and FLAT state changes in your app. This is sufficient for initial layout testing and verifying that your WindowManager integration works correctly.

Create emulator configurations at multiple API levels (Android 12L, 13, 14, 15) because foldable behavior and API support evolved across releases. Android 12L introduced specific optimizations for large screens and foldables that earlier versions lack.

Samsung Remote Test Lab

Samsung operates a free Remote Test Lab (RTL) that gives you access to real Galaxy Z Fold and Z Flip devices in the cloud. You install your APK and interact remotely, including physical fold and unfold operations. Use RTL for final validation before release. It catches issues that emulators miss: hinge sensor timing, cover-to-inner display handoff speed, and One UI-specific behaviors.

Automated UI Testing

The WindowLayoutInfoPublisherRule from the WindowManager testing artifact lets you simulate fold states in instrumented tests. Publish custom WindowLayoutInfo objects with specific FoldingFeature configurations, then combine with Espresso or Compose testing to assert that the correct panes are visible and the hinge keep-out zone is respected.

Write test cases for these scenarios: folded to unfolded transition during active form input, table-top mode during video playback, app launch in multi-window split screen, and rapid fold/unfold cycling. Cover the transitions, not just the static states.

Manual Testing Checklist

• Cover screen launch: App renders correctly on the narrow outer display with no clipped content or broken layouts.
• Unfold during use: Layout transitions smoothly to the expanded configuration. Scroll position, text input, and navigation state are preserved.
• Table-top mode: Content splits logically at the hinge line. Touch targets in the bottom half are reachable and appropriately sized.
• Fold during media playback: Audio or video continues without interruption. Controls adapt to the new screen size.
• Multi-window split: App renders correctly at minimum supported width. No overlapping elements or clipped text.
• App rotation in unfolded state: Landscape and portrait orientations on the inner display both produce usable layouts.
• Memory and performance: Configuration changes during fold transitions do not cause memory leaks from recreated Activities or orphaned Fragments.

Technical implementation is one half of the equation. The other half is designing interactions that feel intentional on foldable hardware rather than bolted on as an afterthought.

Use the Hinge as a Natural Divider

The physical hinge creates a visual and tactile boundary. Lean into it. Place related but distinct content on each side: email list and email body, map and location details, product grid and product info. Do not fight the hinge by rendering content that spans across it. Users perceive the two sides as separate zones, and your layout should respect that perception.

Progressive Disclosure with Screen Real Estate

When the screen expands from folded to unfolded, do not just scale up. Add information. On the folded cover screen, show a compact card list. When the user unfolds, reveal a detail pane alongside the list. When they enter table-top mode, move supplementary controls to the bottom panel. Each posture unlocks a new layer of information density that was not appropriate on the smaller display.

Consistent Navigation Across Postures

Follow Material Design 3 guidelines: bottom navigation bar on compact screens, navigation rail on medium screens, persistent navigation drawer on expanded screens. The transition should happen automatically based on window size class, and the current destination should remain selected across transitions.

Touch Target Sizing

Table-top mode introduces a unique ergonomic constraint: the bottom half of the screen is at a sharp angle, and the user is reaching from above. Touch targets in this zone should be at least 56dp (larger than the standard 48dp minimum) to account for less precise tapping. Group controls in the center of the bottom panel rather than at the edges, where they are harder to reach.

Camera and Media Patterns

Camera apps get the most dramatic benefit from table-top mode. The device stands upright on its own, creating a natural tripod. Place the viewfinder on the upper screen and controls (shutter, timer, filters) on the lower screen. For video calling apps, the same pattern works: remote video on top, self-view and controls on the bottom.

If you have an existing app, you do not need to rebuild from scratch. Foldable support is an incremental investment. Start with the highest-impact changes and expand from there.

Phase 1: Foundation (1-2 Weeks)

Add Jetpack WindowManager to your project. Integrate WindowSizeClass to switch between compact and expanded layouts at your top-level navigation. Ensure your app handles configuration changes without losing state (ViewModel + SavedStateHandle if you are not already using them). Test on the Android Studio foldable emulator. This alone puts you ahead of most apps on the Play Store.

Phase 2: Hinge Awareness (2-3 Weeks)

Implement FoldingFeature detection. Build table-top mode support for your most-used screens. Add the list-detail pattern using ListDetailPaneScaffold or a custom implementation. Avoid rendering content across the hinge. Test on Samsung Remote Test Lab devices.

Phase 3: Polish (2-4 Weeks)

Add multi-window drag and drop support. Optimize your cover screen layout for narrow widths. Implement progressive disclosure as the screen expands. Add automated UI tests for posture transitions. Run through the full manual testing checklist on real hardware.

The total investment for comprehensive foldable support on an existing, well-architected app is typically 5 to 9 weeks of engineering time. For new builds, factor foldable support into the initial architecture and the incremental cost drops significantly, often adding only 15-20% to the mobile development timeline.

Foldable devices are not going away. Samsung, Google, and Chinese OEMs are all investing heavily, and Apple is reportedly entering the market. Apps that support these devices well today build user loyalty and positive reviews that compound over time.

If you are planning a foldable-ready mobile app or adapting an existing one, we have built adaptive UIs across the Samsung, Google, and Motorola foldable ecosystem. Book a free strategy call and we will map out the right approach for your product, timeline, and budget.