Test a Deep Link When the App Is Closed, Open, or Signed Out

A link that opens the app has only completed the first part of its job. A customer expecting a particular service request may still land on the home screen, lose the destination during sign-in or see a record belonging to a different account.

Define acceptance around the intended destination and the person allowed to see it. This fictional exercise uses request REQ-42 in a test account. It is a proposed test plan, not a report of a delivered client app or an executed device test.

AI-generated conceptual illustration; not a client screenshot.

Separate app state from account state

“Closed,” “open” and “signed out” are not three mutually exclusive conditions. An app can be closed while retaining a valid session, or running while signed out. Record both dimensions so one successful launch cannot stand in for every case.

Start with four combinations: closed and signed in, running and signed in, closed and signed out, running and signed out. Add background or suspended behavior if the supported platform handles it separately. Specify how you establish each state rather than using “restart” as an ambiguous instruction.

Apple's universal-link guidance describes different delivery callbacks for apps using scenes when they launch versus when they are already running or suspended. That distinction supports testing both paths; passing one does not demonstrate that the other receives the intended destination.

Write one destination contract

For the fixture, define the expected result as “show the detail view for REQ-42 in the authorized test account.” Merely opening the app or its request list does not satisfy that condition. Record the expected account and a harmless visible marker that confirms which record opened.

Keep the test URL free of credentials and private customer details. Use an ordinary record identifier in a controlled test dataset. The application still needs to check whether the current account may access that record; possession of the link is not the acceptance criterion for permission.

Follow the destination through sign-in

Android's conditional-navigation example routes an unauthenticated user to login before returning to a protected profile screen after successful authentication. It also defines a separate outcome when the user leaves without logging in. Use that distinction to specify your own destination and cancellation behavior.

For REQ-42, write the expected sequence: receive the link, request authentication, then resolve the destination using the authenticated account. Confirm that the intended record survives the login step without showing protected details beforehand.

• Complete sign-in with the authorized test account and confirm REQ-42 opens.
• Cancel sign-in and verify the agreed safe screen appears without protected content.
• Enter invalid credentials and confirm the app neither opens the record nor reports success.
• Sign in with a different test account that lacks access and verify the agreed access-denied or unavailable response.

Do not assume that successful authentication grants access to every record. Keep the navigation result and the permission decision as separate observations.

Check an already open app

Begin on another test record, then activate the REQ-42 link. Confirm that the app displays the requested record rather than retaining the previous screen's data. Repeat from a neutral screen and from a background state supported by the app.

If an unsaved draft is open, agree on its treatment before testing: preserve it, ask before leaving or apply another explicit rule. Record that outcome without changing the purpose of the link. Also check the next Back action; it should follow the application's documented navigation behavior, not an assumed universal rule.

Exercise invalid and repeated destinations

Include a missing identifier, a malformed URL and a validly formed link to a nonexistent test record. Apple's guidance calls for validating URL parameters and testing malformed links. For this exercise, define a clear fallback that reveals no protected record and offers a useful next step.

Activate the same valid link twice. Check whether it produces duplicate detail screens or repeats an action that should require explicit confirmation. This fixture opens a read-only detail view; receiving a link must not itself approve or modify the request.

Record the entry point with the result

For every case, save app build, operating-system version, starting screen, session state, link origin, expected destination and observed outcome. Tapping a link from a message and typing an address into a browser are different entry paths; test the ones your users actually rely on.

Record uninstalled-app behavior separately if it is in scope. This test plan assumes an installed app and does not promise automatic destination restoration after installation. Repeat the accepted cases on the intended release build before declaring the journey verified.

Contact Dynelink to define a focused deep-link acceptance plan for your mobile application.