Switching tabs must preserve each tab’s place
Aliases: per-tab navigation stack · keep-alive tabs
What it is
Each bottom tab is its own navigation stack: its scroll position, open detail layers, filters, and draft input. Tab state preservation means that leaving for another tab and coming back leaves that stack where it was, rather than resetting it to the tab’s root. Switching changes rooms. It does not demolish the room you left.
Why it happens
People treat each tab as a room whose light is still on. They open a conversation under Messages, edit an avatar under Profile, and expect the conversation still open and the list still on the same row. That depends on each stack being stored separately: list offset, child depth, and transient UI (the keyboard may close, but unsubmitted text must not vanish). Destroy the stack on switch and the bar is read as “re-open this module”, so people refuse to leave, or they memorise what they will need before they do.
It is not only scroll that is lost. Filter settings, page position, and a half-filled compose draft are all “how far I had got in this space”. The cost peaks on a deep stack: list to detail to child; a reset forces the whole path again. Never resetting has its own failure: the root needs an explicit “tap the already-selected tab to jump to top / root”, or a deep stack traps people in a child and the tab looks broken.
Studying it
Use a round-trip task: go two levels into tab A and note scroll, do unrelated work in B, return to A, and measure whether depth, offset, and form content restore. Independent variables: whether views are destroyed on switch, whether the process was reclaimed. Dependent variables: restore match rate, extra steps to rebuild the path, and spoken “where was I”.
Score in-session switches separately from cold starts after process death. Failure inside a session is an implementation error; loss across a kill is a lifecycle problem. Both surface as “why am I at the home list again”.
Where it stops holding
After a lapsed login, a permission change, or deleted data, the old stack may point at an object that no longer exists. Resetting is then safer than restoring an error page, but land on the root list, not a random child. Extremely tight memory may drop background tab views; full preservation is then impossible, but restoring the tab root and remembering the last object id is still worth doing. A forced refresh (pull-to-refresh, or a deliberate re-tap of the current tab) is the user throwing away place; it is not switch-destroyed state. A Search destination that should open on an empty query is a convention of that space, not a licence for the whole bar to reset.
Applying it
- Keep an independent stack per tab: scroll offset, depth, unsubmitted drafts. Switching changes which stack is visible; it does not destroy the other.
- Provide an explicit return-to-root: a second tap on the selected tab jumps to that tab’s root or list top, so a deep stack can be escaped, without making the gesture a silent wipe.
- On cold start, restore “the object that was open” before pixel-perfect scroll; if the object is gone, land on the root list and say so.
- How to check: go two levels into a tab, switch away and back, and compare with a screenshot taken before leaving. Loss of depth, offset, or draft is a fail. Then confirm that re-tapping the current tab resets only when the user is clearly asking to go to root.