Coming back must restore the screen the person left
Aliases: state restoration · placekeeping · resumption lag
What it is
When someone returns from another app, the UI should land on the screen they left: navigation stack, scroll offset, expanded groups, selected tab, focused control. The process may have died; the task has not. People treat the recents snapshot as a bookmark. A cold start to home tears the bookmark up. This entry is view state—where they were, what they were looking at. It is not why the process dies, and not how unsubmitted text in a field gets onto disk on its own.
Why it happens
Working memory still holds a place mark such as "I had scrolled to Do Not Disturb on the notifications page." If launch after death only knows the root, that mark has nowhere to land and the path has to be walked again. Deeper paths cost more: a third settings pane, mid-list, a result page with filters still on. OS restoration APIs (activity records, scene state) default to the task root; child screens, scroll, and collapse state have to be packed by the app. The recents screenshot can also fight the live UI: the card still shows the left-behind frame, the tap opens home. Expectation was raised by the picture and slapped by launch, a mismatch harder to explain than "the app was killed."
Studying it
Use an interrupt-and-resume paradigm: stop people mid-task on a deep screen, force a switch, then bring them back.
Independent variables: stack depth at departure, presence of scroll offset, restore-to-same-screen versus restore-to-root, interruption length. Dependent variables: resumption lag (time to re-find the departure point), wrong paths (wrong level, redoing filters), reports of "I lost my place."
If the lab lets people return immediately with the process still alive, the measure is task switching, not restoration failure. Compare "same screen" versus "home" under confirmed process death. Pixel-accurate scroll restoration points at the wrong row once content has refreshed; split "right page, wrong row" from "wrong page" in the dependent measures.
Where it stops holding
Expired auth or a kicked session must return to sign-in; a deep screen is not restorable state. When the content itself is gone (delisted product, expired campaign), land on an explainable stand-in, not a blank or a crash. First launch has no "left-behind" state. A covered desktop window usually keeps its process, so switching back is not this cold-start restore; shipping the mobile restoration blob to desktop fights the window manager's own memory.
Applying it
- On departure, write the stack, in-page scroll, and critical filters into system-restorable state or a local snapshot. Recording only "this app was opened" is not enough.
- The first live frame after tapping the recents card must match what the card shows. If it cannot, do not let the card display a deep screenshot that cannot be rejoined.
- Verify by stopping on a third-level settings or content screen, scrolling off the top, killing the process, and returning from recents. The first frame should still be that level, with scroll roughly where it was. If it lands on root, count the taps needed to rebuild the level: that count is the restoration tax.