Cross-app drag and drop is what split-screen is for

What it is

Two apps side by side are not mainly for “being able to see both.” They are for moving something from one side onto the other: a picture into mail, a span of text into notes, a file into a thread. Cross-app drag is the main value of split-screen—side-by-side puts source and target in view and in reach at once, so a drag does not have to switch apps or copy then paste. Desktops also drag across apps, but they rely on overlapping windows and a pointer. Tablet split-screen relies on two touch surfaces visible together. How drag-and-drop decomposes as an input primitive is a different topic. This entry is only why this form factor makes cross-app drag worth doing, and what split-screen is reduced to when it is not done.

Why it happens

The clipboard is an implicit channel: at copy the target is absent, at paste the source has left the view, and format plus object boundaries rest on a system convention. Split-screen externalizes source and target together; during the drag a person can see where the drop will land and can still change their mind. Touch drag needs a source large enough to grab, a start threshold that separates tap from drag, and a target that highlights droppable range on entry. On a tablet one hand can hold the source while the other scrolls the target—the structural advantage over a phone’s copy-then-switch. If an app only announces that it can sit beside another, but never declares acceptable types and never shows drop feedback on entry, side-by-side decays into two shrunken full screens whose leftover value is visual comparison. A failed drag with no reason looks like split-screen is broken, not like “this target does not take pictures.”

Studying it

Give the same task two paths: drag an object from A to B under split-screen, and copy, switch, paste under full screen. Use pictures, plain text, rich text, and files.

Independent variables: whether the target declares acceptable types, whether a droppable range appears on drag-enter, whether failure states a reason. Dependent variables: completion time, lost formatting, mid-drag abandonment, false belief that a drop already landed.

A comparison task (look at a reference on one side, fill on the other) should be completable without dragging, so the value of side-by-side reading is not counted as drag. Desktop pointer-drag data is not a stand-in for tablet touch drag: a finger occludes the drop point, and start thresholds differ from a mouse.

Where it stops holding

Read-only comparison—a document beside a form, a map beside a list—is a legitimate use of split-screen and does not require drag. When policy forbids some objects leaving the app (banking, enterprise containers), refuse at lift and say why, rather than failing silently at drop. When two apps share no common format, drag is not the main value; system share or export is. Desktop cross-app drag also involves file promises and deferred rendering; tablet split-screen is usually simpler, and that whole integrity apparatus should not be imported as a gate—but type declarations and failure reasons still have to exist.

Applying it

• Give draggable objects an obvious grab point and declare acceptable types. Highlight droppable range on enter; reject a mismatched type as soon as it enters the window.
• After drop, make the result visible in the target (a thumbnail, inserted text). Do not only change internal state.
• On failure, say whether the cause was type, permission, or a read-only target. Do not let the object fly back to the source with no words.
• Verify by dragging a photo from the library into a mail body, and a span of text into notes, under split-screen. Any step that can only be finished with copy-paste, or a drop with no visible result, means the main value of split-screen is still unpaid.

Related

• Within the group: K3.05.1 The app may own only a slice of the screen · K3.05.2 A split pane can be narrower than a phone
• Adjacent: K2.05 Cross-application Drag and Drop · C1.08 Drag and Drop · K2.10 Clipboard and System Services
• Search terms: split-screen drag and drop · cross-app drop · tablet multitasking