# Multi-Window Support in React Native iOS: The Honest Path

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-07. 6 min read.
> Source: https://vp0.com/blogs/multi-window-support-react-native-ios

React Native assumes one window. A second is not just a second screen, and adaptive resizing covers most of what users want.

**TL;DR.** Multi-window support is an iPad and desktop feature (no multi-window on iPhone), built on UIScene, and genuinely hard in React Native because RN is architected around a single root view and single JS context. Match ambition to need: ship excellent adaptive layout for Stage Manager and Split View resizing first, which covers most of what users actually want, then build true multiple windows only for genuinely document- or canvas-based apps. The real engineering is per-window state, a global current-screen assumption must become scene-aware, not the window-opening mechanics, and the scene work lives at the native boundary. A free VP0 design gives layouts that already resize cleanly, which is most of multi-window support before a single scene is added.

## What does multi-window actually mean on iOS, and where?

Two real things, and conflating them wastes effort. On iPad (and Stage Manager on both iPad and Mac), an app can run in **multiple windows side by side**, two notes open at once, a document beside its reference. On the Mac via Catalyst, the same, with its own routing covered in [the Mac Catalyst sidebar navigation guide](/blogs/mac-catalyst-sidebar-navigation-ui-react-native/). On iPhone, there is no multi-window in that sense, so "multi-window support" is fundamentally an **iPad and desktop feature**, and the first honest step is deciding whether your app's users are on the devices where it matters.

The underlying mechanism is scenes. iOS represents each window as a [UIScene](https://developer.apple.com/documentation/uikit/uiscene), and multi-window means your app supports multiple scene instances at once, each with its own UI state. React Native apps are built around a single root view and a single JS context by default, which is exactly why multi-window is harder in RN than it sounds: the architecture assumes one window, and multi-window challenges that assumption at the native boundary.

## Why is this genuinely hard in React Native?

Because React Native was designed single-window, and a second window is not just a second screen. The honest difficulties:

| Challenge | Why it is hard in RN | Implication |
| --- | --- | --- |
| Multiple scenes | RN's host setup assumes one root | Native scene-delegate work, not pure JS |
| Shared JS context | One JS runtime driving two windows | State and navigation must be window-aware |
| Per-window state | Two windows showing different things | Your store can no longer assume one "current" screen |
| Lifecycle | Each window foregrounds/backgrounds independently | Per-scene lifecycle handling |

This is why most React Native apps do not support true multi-window, and that is often the correct decision. The work touches the native scene delegate, the app's assumptions about a single navigation tree, and shared state that suddenly has to be partitioned per window, none of which the JS layer handles for free. Going in clear-eyed about the cost is the difference between a feature and a months-long detour.

## What is the realistic spectrum of "support"?

It is not all-or-nothing, and matching ambition to need is the whole decision:

- **Adaptive layout first (do this regardless).** Long before true multi-window, the app should handle being resized, in Stage Manager and Split View an iPad app runs at arbitrary widths, and an app that letterboxes or breaks at non-fullscreen sizes fails the basic bar. This is the same read-the-real-size discipline as [the desktop-class NavigationSplitView](/blogs/ipad-pro-desktop-class-navigation-split-view-swiftui/), and it covers most of what users actually want.
- **Multiple windows of the same scene.** Letting the user open a second window of your app (two documents) requires scene support but can share most logic; this is the meaningful middle.
- **Distinct auxiliary windows.** A separate window type (a media player popped out, a companion panel) is the most work and the rarest need.

For most apps, nailing adaptive resizing and stopping there is the right call; reach for true multi-scene support only when the app is genuinely document- or canvas-based and users really will want two open at once.

## How do you approach it without breaking the app?

Native-first, state-aware, and incremental. The scene support lives in native code (the SceneDelegate and Info.plist scene configuration), via the [scene delegate](https://developer.apple.com/documentation/uikit/uiscenedelegate), so this is not a pure-JS feature, and an agent should expect to touch the native iOS project, carefully, the same managed-boundary caution as any native integration. The bigger design shift is state: a single global "current screen" assumption has to become per-window, so navigation and any store keyed on "the active view" need to become scene-aware, which is the part that quietly breaks an app retrofitted for multi-window.

The pragmatic path: ship excellent adaptive layout for resizing first (the [multitasking guidance](https://developer.apple.com/design/human-interface-guidelines/multitasking) is the bar), validate that users on iPad actually want two windows before building it, and only then take on scene support, treating per-window state as the real engineering rather than the window-opening mechanics. The screens are unaffected by the windowing decision; a free [VP0](https://vp0.com) design gives the agent layouts that already resize cleanly, which is 80% of "multi-window support" for most apps before a single scene is added.

## Key takeaways: multi-window support in React Native iOS

- **It is an iPad and desktop feature**: no multi-window on iPhone, so decide if your users are where it matters.
- **The mechanism is scenes (UIScene)**, and RN's single-window, single-JS-context architecture is why it is genuinely hard.
- **Adaptive resizing comes first and covers most needs**: handle Stage Manager and Split View arbitrary widths before any true multi-window.
- **Per-window state is the real work**, not opening the window: a global current-screen assumption must become scene-aware.
- **Match ambition to need**: most apps should nail resizing and stop; build multi-scene only for genuinely document- or canvas-based apps.

## Frequently asked questions

**How do I add multi-window support to a React Native iOS app?** It is iPad and desktop only, built on UIScene, so it requires native scene-delegate work plus making your navigation and state scene-aware rather than assuming one current screen. Start with excellent adaptive layout for Stage Manager and Split View resizing, which covers most needs, before attempting true multiple windows. A free VP0 design supplies layouts that already resize cleanly.

**Does multi-window work on iPhone?** No: multiple side-by-side windows are an iPad (and Mac via Catalyst) capability, available through Stage Manager and Split View, not an iPhone feature. So multi-window support is fundamentally about iPad and desktop, and the first step is confirming your users are on those devices before investing in it.

**Why is multi-window hard in React Native?** Because React Native is architected around a single root view and a single JS context, while multi-window means multiple UIScene instances each with their own state. The native scene work, the shared JS context driving two windows, and the per-window state partitioning all challenge RN's single-window assumptions, which is why most RN apps do not support it.

**What should I build before true multi-window?** Adaptive layout: an iPad app runs at arbitrary widths in Stage Manager and Split View, so it must resize and reflow cleanly rather than letterboxing or breaking at non-fullscreen sizes. That handles most of what users actually want and is the prerequisite for any further multi-window work.

**What is the hardest part of multi-window support?** Per-window state, not opening the window. A single global assumption about the current screen has to become scene-aware so two windows can show different things independently, and retrofitting that into an app built single-window is where the real engineering and the subtle bugs live.

## Frequently asked questions

### How do I add multi-window support to a React Native iOS app?

It is iPad and desktop only, built on UIScene, so it requires native scene-delegate work plus making your navigation and state scene-aware rather than assuming one current screen. Start with excellent adaptive layout for Stage Manager and Split View resizing, which covers most needs, before attempting true multiple windows. A free VP0 design supplies layouts that already resize cleanly.

### Does multi-window work on iPhone?

No: multiple side-by-side windows are an iPad (and Mac via Catalyst) capability through Stage Manager and Split View, not an iPhone feature. Multi-window support is fundamentally about iPad and desktop, so the first step is confirming your users are on those devices before investing in it.

### Why is multi-window hard in React Native?

Because React Native is architected around a single root view and single JS context, while multi-window means multiple UIScene instances each with their own state. The native scene work, the shared JS context driving two windows, and per-window state partitioning all challenge RN's single-window assumptions, which is why most RN apps do not support it.

### What should I build before true multi-window support?

Adaptive layout: an iPad app runs at arbitrary widths in Stage Manager and Split View, so it must resize and reflow cleanly rather than letterboxing or breaking at non-fullscreen sizes. That handles most of what users actually want and is the prerequisite for any further multi-window work.

### What is the hardest part of multi-window support?

Per-window state, not opening the window. A single global assumption about the current screen has to become scene-aware so two windows can show different things independently, and retrofitting that into an app built single-window is where the real engineering and the subtle bugs live.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*