After an inter-app jump, the way back to the source must still exist

What it is

After jumping from a calendar into a meeting, from a restaurant page into Maps, from in-app checkout into a wallet, the person has to be able to return to that event or that restaurant page—not be left on the target app's home. This is the return leg of a deep-link jump: whether the source is still a path, and how to take it. It is not whether a system Back key exists on a given platform, or how back stacks merge across apps. Those are a different set of platform conventions. The question here is only: after going out to get something done, is the source app still a walkable road.

Why it happens

A deep link hands the person to the target and usually backgrounds the source. Some systems briefly show "Back to X" in the status bar or on the gesture edge. That affordance is the OS's. The target must not assume it lasts, and must not treat its own Close as a substitute—Close that only pops a page inside the target leaves the person on the target's home, and the source is never foregrounded. Payment, authorization, and "open in Maps" are a borrow: the target is a tool, not the new home of the task. If the tool never yields control, the person has to hunt in recents, and if the source has already been reclaimed they may hunt into a cold start. If the source did not record "I am waiting on a payment result" before the jump, it also will not know which order to refresh on return. What breaks is task continuity, not the absence of a Back key on one OS.

Where it stops holding

When the person clearly chooses "keep exploring in Maps" rather than "see the route and come back," the return need not fire automatically, but the source should still be findable. When the target is a long occupation such as a full-screen game or turn-by-turn navigation, bouncing back mid-task would interrupt work in progress; return should be a discoverable exit, not a forced pop. If the source was swiped away after the jump, the person ended that task; the target should not offer a "return" that opens a dead app. Side-by-side desktop windows keep the source visible and do not rely on this return leg; auto-switching focus back after "done" on desktop would steal the window.

Applying it

• Before jumping out, record the waiting source context (which order, which meeting). On complete, cancel, or fail, send the person back to the source rather than landing on the target's home.
• Do not let the target's own Close impersonate the return leg. If Close is only a page-stack operation inside the target, the source never appears.
• Verify by opening a join link from a calendar event and then ending or leaving the meeting. The calendar event or day view should return, not the video app lobby. If the person has to find the source in recents themselves, the return leg was not kept.

Related

• Within the group: K1.11.1 A deep link must open the specific screen, not the app's front door · K1.11.2 A missing target app needs a fallback path, not a dead end · K1.11.4 Unchecked deep-link parameters become an attack surface
• Adjacent: K8.01 Task continuity · K1.04 Platform differences in back navigation
• Search terms: return to source app · cross-app navigation · handoff back