When a product runs in split-screen beside another app, which single-window assumptions break, and how would you test them?

## What split-screen actually changes Split-screen — the arrangement where two applications occupy one display at the same time — changes three things at once for the application under test, and each one breaks a different assumption that a single-window layout made without ever writing it down. - **The window is no longer the screen.** Your application may be given a third of the width, or a short strip of the height, while the rest belongs to something else. - **The size is no longer fixed for the life of the screen.** The user drags the divider, and the window shrinks and grows underneath a screen that is already built and in use. - **Your application is no longer alone.** Another app may hold the input focus, the camera, the microphone or the audio output while yours is fully visible. ## The assumptions a single-window layout quietly made | Assumption | What split-screen does to it | What the case checks | |---|---|---| | The window width equals the screen width | The window may be a third of it | The flow completes at the narrowest supported fraction | | The size is fixed once the screen is built | The user resizes it while the screen lives | Unsaved input and selection survive a live resize | | Visible means focused | Visible and unfocused is a normal state | The app does not claim focus it was never given | | Sole use of camera, microphone or audio | Another app can take the resource | The degraded path shows, and use resumes when it returns | | There is room for a fixed header and footer | Available height shrinks sharply | Primary controls stay reachable rather than clipped | | The on-screen keyboard covers a known share | The proportions are different | The focused field stays visible while typing | Read that table as the case list. Every row is a behaviour rather than a look, which is what keeps this axis from collapsing into image comparison. ## Designing the case 1. Start full-screen and drive the flow to a state with **unsaved work** on screen. 2. Enter split-screen at the widest supported fraction, wait for a readiness signal, and assert the in-progress state survived — this is the same restore path a rotation exercises, reached through a different door. 3. Shrink towards the narrowest supported fraction in two or three steps, waiting each time, and assert that the primary control is reachable and that no label is drawn cut off. 4. Hand the focus to the other application and take it back, then assert your app neither acted on input it never received nor lost what was on screen. 5. Leave split-screen and confirm the flow still completes and submits the right values. ## Visible but not focused This is the state with no equivalent in a single-window run, and it is where the subtle defects live. A visible-but-unfocused app should keep drawing, keep its data, and keep any timer the user can see. What it must not do is behave as though the user is looking at it and typing into it: pop a transient message that will be missed, start an attention-grabbing animation, count the time as engaged usage, or assume the on-screen keyboard belongs to it. The opposite error is just as real — code that pauses everything the instant focus is lost will freeze the video a user deliberately put beside their notes. ## Telling a split-screen defect from a narrow-width one Most of what a first split-screen run surfaces is not split-screen-specific at all; it is a layout nobody ever tried at that width. There is a cheap discriminator: reproduce the same width full-screen on a smaller form factor. If the layout breaks there too, it is a width defect, and it belongs in the narrow-geometry case where it runs cheaper and reads clearer. What is genuinely specific to this arrangement is behavioural: - a size that changes while the screen is live, rather than being settled when it was built; - another application holding the input focus or a shared hardware resource; - transitions that arrive while your app is still fully visible rather than hidden. ## Is the axis worth carrying? Supporting split-screen is a product commitment with a recurring test cost, so it deserves to be decided rather than drifted into. It pays where two apps side by side is a real user story — reference material beside a form, a conversation beside a document, a video beside notes — and on any flow that holds unsaved work or a fixed-height header and footer. Elsewhere, one smoke-level check per screen family is enough. The opposite choice is equally legitimate: declare the arrangement unsupported, and then test that declaration, because it is usually made per screen, one screen opting back in is the classic miss, and larger form factors may resize the window regardless of what the product asked for.