Skip to content
Preptima
mediumScenarioConceptMidSenior

A deep link opens the right screen when the app is in the background and the wrong one when the app was killed. How do you test for that?

Treat each launch state as its own test case, because each delivers the link through a different code path. Cold start runs splash, auth and initialisation that can drop the link, and on iOS delivers it in the scene's connection options, not the continue callback. Test cold, warm, restored and logged-out.

5 min readUpdated 2026-10-09Target archetype: Product Startup

Answer

Short answer

A deep link that works when backgrounded and fails when killed is a launch-state bug. Each launch state hands the link to the app through a different code path, so mobile testing has to cover each one deliberately. Cold start goes through splash, auth checks and initialisation that can drop or override the link, and on iOS the link arrives in the scene's connection options instead of the callback the warm path uses.

Launch stateHow it arisesWhat usually breaks
ColdProcess not runningLink discarded by splash, auth or start-up routing
Warm or hotProcess alive, app in backgroundLink handled by onNewIntent or scene(_:continue:)
RestoredProcess killed by the OS, task still in recentsSaved state and the link fight over the screen
ForegroundApp already openIn-app routing from a notification or link
Logged outAny of the above, no sessionLink lost after the login screen

Was this answer helpful?

Likely follow-ups

  • After the user logs in from a cold-start deep link, how do you make sure they land on the linked screen rather than home?
  • Why can reopening the app from the recents screen take the user back to an old deep link, and how would you test for it?
  • What does the back button do after a cold-start deep link, and what should it do?
  • How would you automate the cold-start case in CI without a person tapping a link?

Related questions