Back stacks behave differently across apps

What it is

Tapping a map in a chat, or a sign-in page in mail, already left the original app. Android’s task / back stack can splice that jump into one return chain: Back in the map may reveal the chat. iOS treats the jump as an app switch; no system return chain crosses the app boundary. Getting back means the app switcher, or an occasional “Back to App” banner. The same “open the camera, take one shot” path often returns Android users to the thread that was sending the photo, and leaves iOS users in Camera. This entry is only about where a return chain goes when it crosses an app boundary. It is not about whether system Back exists, and not about unifying both ends with one button.

Why it happens

When Android starts another activity by intent, the default is to place it in the current task, so Back finishes it and uncovers the caller. Task affinity and launch mode rewrite that chain: an app that opens as a new task will not return to the caller, but to its own root. iOS apps are separate processes; system-level return walks only the current app’s navigation stack. Crossing apps is a foreground switch, not a splice. The same product path—share, authorize, pick an address, open a bank—feels on Android like “still in the thing I was doing,” and on iOS like “I went to another app.” If authorization finishes in a system browser, Android custom tabs usually attach Back to the original app; iOS depends on a return URL, and on failure the person sits in the browser with no idea whether the original sign-in is still alive.

Studying it

Trace a cross-app task: from a named entry in app A open B, fire that platform’s leave, and record whether the landing is A, B’s root, or Home. Afterwards ask where they thought they would land.

Independent variables: platform, whether B started as a new task, whether a system browser or share sheet sat in between. Dependent variables: actual landing, match to expected landing, use of the app switcher to recover A, repeat submit or repeat sign-in.

Log events named “back” are not the same API on both ends; align on the user action, not the function name. Tapping Back only inside one app does not measure a cross-app stack. Do not treat iOS’s “Back to Safari” banner as an Android-style stack—it is a one-shot entry, not a chain that can be popped repeatedly.

Where it stops holding

A share sheet that is a system modal, not a separate app, closes the sheet on return; both platforms are still in the original app and there is no cross-app stack. An in-app web view never left the app; return walks web history. Apps from the same developer may share a task on Android and behave as one app. iOS Handoff and failed universal-link fallbacks are other cross-device or cross-app paths, not a back stack.

Applying it

• When Android opens you from another app, system Back should return to the caller, not clear the stack onto your home. Return to your own root only when you were opened as a standalone task.
• On iOS, after a cross-app step, jump back through the system return if one exists; do not imitate Android’s repeated pops. If the jump fails, say which app the person is in now.
• For authorize, pay, and pick-image steps that must visit another app, draw “from where / back to where” separately per platform; do not share one flowchart.
• Verify by opening your app from chat, mail, and browser, then leaving. Android Back-repeated should land in the originating thread or message; iOS should recover the origin via an explicit jump or the switcher, without stranding people on the other app’s root. Any path onto a blank home that demands a fresh sign-in is a cross-app stack that was cut.

Related

• Within the group: K1.04.1 System Back exists on one platform and not the other · K1.04.3 Forcing one Back model onto both platforms breaks each convention
• Adjacent: G4.01 Back Stack and Back Semantics · K1.11 Deep Links and Inter-app Navigation
• Search terms: back stack · task affinity · cross-app navigation