This page provides guidance on optimizing your app to improve its behavior on large screens.

Flutter, like Android, defineslarge screens as tablets, foldables, and ChromeOS devices running Android. Flutteralso defines large screen devices as web, desktop, and iPads.

Consider the following screenshots of an app. The app displays its UI in aListView. The image on the left shows the app running on a mobile device. The image on the right shows the app running on a large screen devicebefore the advice on this page was applied.

This is not optimal.

TheAndroid Large Screen App Quality Guidelines and theiOS equivalent say that neither text nor boxes should take up the full screen width. How to solve this in an adaptive way?

A common solution usesGridView, as shown in the next section.

You can use theGridView widget to transform your existingListView into more reasonably-sized items.

GridView is similar to theListView widget, but instead of handling only a list of widgets arranged linearly,GridView can arrange widgets in a two-dimensional array.

GridView also has constructors that are similar toListView. TheListView default constructor maps toGridView.count, andListView.builder is similar toGridView.builder.

GridView has some additional constructors for more custom layouts. To learn more, visit theGridView API page.

For example, if your original app used aListView.builder, swap that out for aGridView.builder. If your app has a large number of items, it's recommended to use this builder constructor to only build the item widgets that are actually visible.

Most of the parameters in the constructor are the same between the two widgets, so it's a straightforward swap. However, you need to figure out what to set for thegridDelegate.

Flutter provides powerful premadegridDelegates that you can use, namely:

SliverGridDelegateWithFixedCrossAxisCount

Lets you assign a specific number of columns to your grid.

SliverGridDelegateWithMaxCrossAxisExtent

Lets you define a max item width.

Another way to approach these situations is to use themaxWidth property ofBoxConstraints. This involves the following:

• Wrap theGridViewin aConstrainedBox and give it aBoxConstraints with a maximum width set.
• Use aContainer instead of aConstrainedBox if you want other functionality like setting the background color.

For choosing the maximum width value, consider using the values recommended by Material 3 in theApplying layout guide.

As mentioned previously, Android and Flutter both recommend in their design guidancenot to lock screen orientation, but some apps lock screen orientation anyway. Be aware that this can cause problems when running your app on a foldable device.

When running on a foldable, the app might look ok when the device is folded. But when unfolding, you might find the app letterboxed.

As described in theSafeArea & MediaQuery page, letterboxing means that the app's window is locked to the center of the screen while the window is surrounded with black.

Why can this happen?

This can happen when usingMediaQuery to figure out the window size for your app. When the device is folded, orientation is restricted to portrait mode. Under the hood,setPreferredOrientations causes Android to use a portrait compatibility mode and the app is displayed in a letterboxed state. In the letterboxed state,MediaQuery never receives the larger window size that allows the UI to expand.

You can solve this in one of two ways:

• Support all orientations.
• Use the dimensions of thephysical display. In fact, this is one of thefew situations where you would use the physical display dimensions andnot the window dimensions.

How to obtain the physical screen dimensions?

You can use theDisplay API, introduced in Flutter 3.13, which contains the size, pixel ratio, and the refresh rate of the physical device.

The following sample code retrieves aDisplay object:

/// AppState object.ui.FlutterView?_view;​@overridevoiddidChangeDependencies(){super.didChangeDependencies();_view=View.maybeOf(context);}​voiddidChangeMetrics(){finalui.Display?display=_view?.display;}

The important thing is to find the display of the view that you care about. This creates a forward-looking API that should handle currentand future multi-display and multi-view devices.

Adding support for more screens, also means expanding input controls.

Android guidelines describe three tiers of large format device support.

Tier 3, the lowest level of support, includes support for mouse and stylus input (Material 3 guidelines,Apple guidelines).

If your app uses Material 3 and its buttons and selectors, then your app already has built-in support for various additional input states.

But what if you have a custom widget? Check out theUser input page for guidance on addinginput support for widgets.

Navigation can create unique challenges when working with a variety of differently-sized devices. Generally, you want to switch between aBottomNavigationBar and aNavigationRail depending on available screen space.

For more information (and corresponding example code), check outProblem: Navigation rail, a section in theDeveloping Flutter apps for Large screens article.