iPadOS extended display architecture

This is very interesting post hope I understand correctly what you trying to accomplish, and more about when talking about MultipleScenes and moving Scenes to external displays.

To build a native iPadOS application that utilizes an external display with custom layouts while preserving pointer interaction, you must adopt a Multi-Scene Architecture. But hope other developers also provide their solution here.

https://developer.apple.com/documentation/swiftui/scene

Treats the external display as an extended desktop. Fully preserves native pointer interaction, hover effects, and custom interactive layouts. You cannot force the window to open full-screen on the external display automatically; the OS or the user dictates window placement, though you can programmatically request a new scene.

Because your app will effectively run two independent UI hierarchies (one on the iPad, one on the external display), your architecture must strictly separate UI from state.

https://developer.apple.com/documentation/uikit/uiscenedelegate/scene(_:willconnectto:options:)

But I recommend to look at the sessions open https://developer.apple.com/documentation/uikit/uiapplication/opensessions

And the support for MultipleScenes https://developer.apple.com/documentation/uikit/uiapplication/supportsmultiplescenes

In SwiftUI, you can achieve this using the WindowGroup and the openWindow environment value. Moving the Window and Scene where you want is the user's task.

Hope this gets you started.

Albert  WWDR

Thank you for the detailed explanation. It confirms that a multi-scene architecture is the correct direction.

I have a follow-up question to make sure we’re approaching this correctly.

We’re building a native iPadOS application that uses an M5 iPad with a 43” or 55” external monitor. Our goal is for the external monitor to become an interactive workspace while the iPad continues to display a separate control interface.

We understand that iPadOS controls window placement and that an application cannot automatically force a window to open full-screen or at a specific location on the external display.

Our question is about what happens after the interactive window has been created.

Once the application’s interactive scene/window exists on the external display, can the application fully control the layout inside that window? For example, can we programmatically size and position our own views (such as a large custom rendering view with supporting panels around it) based on the available window size, without requiring the user to manually resize or arrange our application’s internal views?

In other words, we’re not trying to control the OS-managed window itself. We only want complete control over the content and layout inside our application’s window.

Also, is there a recommended WWDC session, sample project, or Apple sample code that demonstrates this type of professional multi-window, external-display application?

Thank you again for your guidance.

@psharma007

Thanks for the reply and looks like you already going on the correct path.

Your understanding of the boundary between the OS and the application is exactly right, iPadOS manages the window's frame, its placement on the external display. while your application entirely owns the content area.

Once the UIWindowScene is established on the external display, you can programmatically size, position, and arrange all of your internal views. You do not need the user to manually arrange internal panels. The user never has to manually arrange your internal UI elements.

I would suggest structuring desktop-class, multi-window iPad applications that behave well on external displays, I recommend reviewing the Meet Stage Manager (WWDC22) https://www.youtube.com/shorts/IppdepnHJJo?themeRefresh=1

By following the multi-scene architecture and relying on standard layout engines for your internal views, your iPad control interface and your external interactive workspace will function exactly as you envision in my personal opinion. However I would like other engineers here to add their recommendations to make that job easier for you.

Albert  WWDR