Proposal: Built-in Split View (Dual-Pane) Support for Large Screens and Foldable Devices #189554

Use case

When running a Flutter app on large-screen devices (tablets, foldables, desktops), only one page is displayed at a time, leaving most of the screen unused. This is a significant gap compared to native platforms:

Android provides SlidingPaneLayout for master-detail two-pane UIs
iOS provides UISplitViewController
Web has CSS multi-column / grid layouts
Common apps like email clients, settings, file managers, and note-taking apps universally use a master-detail split layout on large screens. Flutter developers currently have no built-in way to achieve this that transparently works with existing Navigator/Router APIs.
To achieve a split view today, developers must write a significant amount of application code: manually detecting screen size with MediaQuery, conditionally composing Row/Column layouts, duplicating navigation logic for each screen, and managing state synchronization between panes. This adaptation must be repeated for every page in the app, and it breaks standard Navigator/Router semantics (back button, route transitions, deep linking). The result is high development cost, fragile code, and inconsistent behavior across platforms.

Proposal

Existing Alternatives and Their Limitations

Expected Effect

An app that currently looks like this:

┌─────────────────────────┐
│                         │
│      Single Page        │
│                         │
└─────────────────────────┘

Should automatically become this on wide screens, without modifying the app's navigation code:

┌───────────┬─────────────┐
│           │             │
│  Home     │  Detail     │
│           │             │
│           │             │
└───────────┴─────────────┘

Proof of Concept

We have completed a working proof of concept using the dual-overlay approach. The implementation supports all common Flutter routing patterns:

Supported Routing Patterns

How It Works (Overview)

1. Dual overlay: Replaces the Navigator's single Overlay with two side-by-side Overlays.
2. Route allocation: Assigns route overlay entries to the appropriate overlay, enabling two pages to be visible simultaneously.
3. Navigation interception: Intercepts push and pop operations to maintain split-view invariants (each overlay displays the expected page).
4. Popup handling: PopupRoutes are assigned to the correct overlay, with a mirror barrier placed on the opposite side to block interaction.
5. Dynamic split view visibility: Controls the visibility of left and right overlays to dynamically adjust whether the current page displays split view on screen orientation or size changes (landscape/portrait switch, fold/unfold), enabling seamless transitions.
6. Two-layer toggle design: The split-view feature is implemented as a two-layer toggle — the first layer is an explicit opt-in by the app; when not enabled, the original behavior is fully preserved with zero intrusion; the second layer, once enabled, dynamically decides whether the current page presents split view based on screen resolution and orientation (landscape/portrait).

Demo

Configuration

Our local implementation currently reads configuration items such as split mode from a specific JSON configuration file. This is merely an implementation choice for the proof-of-concept stage. The configuration approach (file format, programmatic API, or framework integration) can be entirely adjusted according to upstream recommendations.

What remains unchanged: no need to modify the app's Navigator.push(), Navigator.pop(), context.go(), or any other navigation code.

Comparison with Existing Solutions

• vs. adaptive_scaffold: Zero intrusion, no need to redesign the layout tree. The two have different positioning: adaptive_scaffold is a layout slot system, while our approach is split view at the navigation stack level.
• vs. flutter_split_view: No need to replace routing API, supports declarative routing; but requires modifying Navigator internals.
• vs. flow_nav: The right pane maintains a real navigation stack (supports back navigation), no need to configure callbacks for each routing pattern; but requires modifying Navigator internals.

Implementation Approach

The proof of concept adds SplitViewNavigatorPolicy in navigator.dart, responsible for:

• Overlay entries reallocation: In NavigatorState.build, route overlay entries are distributed to left and right overlays, enabling two pages to be visible simultaneously.
• Navigation operation interception: Intercepts key push/pop operations to maintain split-view invariants, avoiding routing anomalies in multi-page scenarios.
• Popup and barrier handling: Assigns PopupRoute to the correct overlay and places a mirror barrier on the opposite side to block interaction.
• Dynamic split view visibility: Controls the visibility of left and right overlays to dynamically adjust whether the current page displays split view on screen orientation or size changes (landscape/portrait switch, fold/unfold), enabling seamless transitions.
• Forced split/no-split: Supports forcing specific pages into split view or fullscreen mode (e.g., video player forced fullscreen).

We are also open to other approaches preferred by the official team.

Questions for the Flutter Team

1. Is this a feature direction the team would consider for inclusion in the framework? Large-screen/foldable support is a stated priority, but current solutions (widget composition) require significant app changes. Would a more transparent, Navigator-level approach be welcome?

2. Does the team have existing development plans for similar functionality? If related work is already underway, we want to avoid duplicating effort.

3. If the feature direction is acceptable, which implementation approach does the team prefer? Specifically:

   • Is directly modifying navigator.dart acceptable?
   • Or should it be a pure package (at the cost of not supporting Router routing)?
   • Or a new widget (e.g., SplitViewNavigator) wrapping Navigator?

Background

• Platform: The implementation is cross-platform, with local testing done on Android Pixel Tablet emulator
• Flutter version: Based on Flutter 3.41.9
• Proof of concept tested with real applications (not just examples)

We are sharing this proposal early to get direction from the official team, avoiding investing significant work in an upstream-quality implementation only to be rejected. We can provide more details, code, or demos as needed.