Adaptive UI for Tablets and Foldable Devices

A phone layout stretched across a 12-inch tablet shows lines of text 80 characters wide, a lonely list, and a bottom bar far from the user's thumbs. Many Android users are on tablets, foldables and Chromebooks, and multi-window means even phone apps can be resized. Adaptive layouts fix this by responding to available window space.

Core principles

• Design for window size, not device. A foldable's inner screen, a tablet in split-screen and a Chromebook window are all just "a window of size X".
• Don't lock orientation or resizability unless absolutely necessary. Recent Android versions increasingly ignore such restrictions on large screens.
• Keep state across resizes. Unfolding or rotating triggers a configuration change, and the user's place must survive it.

Window size classes

Window size classes are breakpoints that bucket the window into compact, medium and expanded (with further large and extra-large buckets in recent versions) for width and height:

@Composable
fun AppRoot() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
    val showTwoPanes = windowSizeClass.isWidthAtLeastBreakpoint(WindowSizeClass.WIDTH_DP_EXPANDED_LOWER_BOUND)
    InboxScreen(twoPane = showTwoPanes)
}

The exact helper names in the Material 3 adaptive library have changed between versions, so check the current API reference when you add the dependency.

Adaptive navigation with NavigationSuiteScaffold

enum class TopLevel(val label: String, val icon: ImageVector) {
    HOME("Home", Icons.Default.Home), SEARCH("Search", Icons.Default.Search), PROFILE("Profile", Icons.Default.Person)
}

@Composable
fun AppScaffold() {
    var current by rememberSaveable { mutableStateOf(TopLevel.HOME) }
    // Bottom bar on compact, navigation rail on medium/expanded: chosen automatically.
    NavigationSuiteScaffold(
        navigationSuiteItems = {
            TopLevel.entries.forEach { dest ->
                item(
                    selected = dest == current,
                    onClick = { current = dest },
                    icon = { Icon(dest.icon, contentDescription = null) },
                    label = { Text(dest.label) },
                )
            }
        },
    ) {
        when (current) {
            TopLevel.HOME -> HomeScreen()
            TopLevel.SEARCH -> SearchScreen()
            TopLevel.PROFILE -> ProfileScreen()
        }
    }
}

Canonical layout: list-detail

On a phone, tapping an email opens it full screen. On a tablet, the list stays on the left and the email shows on the right. Material 3 adaptive provides ListDetailPaneScaffold and a navigator that handles single-pane versus two-pane behaviour and back navigation for you:

@OptIn(ExperimentalMaterial3AdaptiveApi::class)
@Composable
fun InboxListDetail(messages: List<Message>) {
    val navigator = rememberListDetailPaneScaffoldNavigator<String>()   // content key: message id
    val scope = rememberCoroutineScope()

    BackHandler(navigator.canNavigateBack()) { scope.launch { navigator.navigateBack() } }

    ListDetailPaneScaffold(
        directive = navigator.scaffoldDirective,
        value = navigator.scaffoldValue,
        listPane = {
            AnimatedPane {
                MessageList(messages, onOpen = { id ->
                    scope.launch { navigator.navigateTo(ListDetailPaneScaffoldRole.Detail, id) }
                })
            }
        },
        detailPane = {
            AnimatedPane {
                navigator.currentDestination?.contentKey?.let { id -> MessageDetail(id) }
                    ?: EmptyDetailPlaceholder()
            }
        },
    )
}

Some navigator functions are suspend in recent versions, hence the coroutine scope. Follow the API reference for your version.

Adapting content, not just structure

• Constrain reading width: limit text columns, for example Modifier.widthIn(max = 640.dp), so long lines stay readable.
• Grids: LazyVerticalGrid(GridCells.Adaptive(minSize = 180.dp)) adds columns as width grows.
• Input: support keyboard, mouse hover and stylus on tablets and Chromebooks, such as keyboard shortcuts and hover states.
• Foldables: Jetpack WindowManager reports fold position and posture (for example tabletop), so you can avoid placing content across the hinge.

Testing adaptive UI

• Use resizable emulators and the foldable and tablet emulator profiles.
• Add previews for different device sizes (@Preview(device = Devices.TABLET)) and screenshot-test them.
• Test fold and unfold and multi-window transitions to confirm state is preserved.

Real-world examples

Common mistakes

• Checking "is tablet" from device characteristics instead of window size.
• Locking portrait orientation for the whole app.
• Losing selection or scroll state on fold or unfold.
• Stretching phone layouts edge to edge on wide screens.

Frequently asked questions

Conclusion

Adaptive UI is about window size, not device type: read the window size class, switch navigation with NavigationSuiteScaffold, use canonical layouts like list-detail, constrain content width, and preserve state through resizes and folds.

Next step: structure the app behind those screens with MVVM Architecture in Android.