Mobile deep link testing: a checklist for iOS and Android

To test a mobile deep link, tap it from the place a user receives it and follow the journey to the intended screen and record. Repeat with the app closed, already open and signed out. Check who can view the destination, what happens when it is unavailable, and where Back takes you. An app launch alone doesn't tell you whether the link worked.

What do you need before testing a link?

Choose one real link and write down which screen it should open. For example, imagine you're testing an appointment-booking app. Create two fake appointments: one for Tuesday and one for Friday. The link in Tuesday's reminder should open the Tuesday appointment's details. If it opens Friday's details or the home screen, the test has failed. The checklist below uses this example.

If the user must sign in first, agree whether the app should return to Tuesday's appointment afterwards. Also agree what should happen if that appointment has been cancelled. Prepare another test account that cannot view it, so you can check access restrictions.

Record the build, environment and link source. Use synthetic data; keep live sign-in tokens and customer links out of shared worksheets and recordings.

List each entry route you ship: an HTTPS link, a custom URL scheme, a notification or a shortened link may reach the same screen through different paths. Test each promised route separately. A notification tap passing doesn't verify a link in an email.

Which app and account states should you test?

Start with the following cases for one supported iPhone and one Android phone. Expand coverage when a release changes routing, sign-in or domain configuration. Use your mobile device test matrix to choose additional OS versions.

Starting condition	Action	What to check
App closed; authorised account signed in	Tap Tuesday's appointment reminder	The app opens Tuesday's appointment with the correct date and status.
App showing Friday's appointment	Tap Tuesday's appointment link from the source app	Tuesday's details replace Friday's; the app doesn't keep showing the old appointment.
App in the background	Tap the link and return to the app	The requested destination loads after resume without an extra tap.
Signed out	Tap the protected link, then complete sign-in	The agreed destination survives sign-in; the app doesn't silently drop the request.
Signed in to an account without access	Tap the same test link	The agreed unavailable or access-denied response appears without exposing Tuesday's appointment details.
Destination deleted or link expired	Open a prepared invalid test link	The app explains the outcome and provides a usable way to continue.
App absent	Tap the HTTPS link	The expected web or install fallback works. Test any promised journey through installation separately.

Write down how you made the app closed or backgrounded. Swiping it away and an Android force-stop are different setup actions; “cold start” is too vague for another tester to repeat.

Repeat the signed-out case with the app closed and already running. This checks whether the destination survives both launch and sign-in. Keep the build, link and test account the same when comparing those results.

For each successful route, check the next Back action against your app's navigation design. Then tap the link again and check for duplicate screens or repeated actions. A reminder should not cancel or confirm an appointment merely because you opened it twice.

How do you check iPhone universal links?

Use Notes as a diagnostic starting point: paste the test link, then long-press it to inspect the app and browser options. Apple explains that the choice sets the device's future handling for that domain. Record it before changing it. Entering the URL in the browser address bar stays in the browser, and same-domain navigation in Safari can also stay there. Account for those documented behaviours before filing a defect. See Apple's universal-link troubleshooting guide.

Next, open the actual reminder email or message and tap its link. Record the sending app and any browser or preview it opens. Keep a direct destination link as a comparison if the reminder uses a redirect. If only the reminder fails, include both outcomes in the issue so engineering can investigate the handoff before the destination screen.

How do you check Android App Links?

Test on the build distributed to your testers and record whether the phone opens the app, a browser or a chooser. Note any previous change to the phone's link-opening preferences. Android documents that a user's preference can send a link to the app even when domain verification failed, so opening the app alone doesn't prove the association is correct. See Android's App Links test guide.

When the wrong handler opens, ask engineering to check the associated host and Digital Asset Links file for that build. Keep this separate from a case where the app opens but displays the wrong appointment: that report needs the screen sequence and account state. Include the exact test subdomain; success on a staging host doesn't verify the host in the release email.

What should happen when a link requires sign-in?

Test the whole sign-in round trip against the behaviour agreed for your app. Android's conditional-navigation example shows a protected profile destination reached through a login screen. Use the same idea to make your expected result concrete: “Sign in, then show Tuesday's appointment.”

Repeat after cancelling sign-in. Then open the link using the account without access. Successful authentication must not be treated as permission to view every appointment. If the app supports account switching, check which account is active when the destination finally appears.

What evidence makes a deep-link bug reproducible?

Capture the journey from the source link through the wrong result, including any sign-in screen. If recording would expose credentials, stop the capture or use sanitised screenshots with a written sequence. Copy this into the issue:

Title: Reminder opens home after sign-in instead of Tuesday's appointment
Build / device / OS:
Environment / link host and route:
Link source app and version:
Install history / app state and how it was set:
Account role / sign-in state / access to target:
Link-opening preference, if changed:

Steps from the source link:
Expected screen and test record:
Actual screen and record:
Back action / result of opening the link again:
Failures out of attempts:
Direct-link comparison, if available:
Evidence and timestamp:

Keep sensitive URL values out of the ticket. Describe the route shape and arrange a fresh test link through your team's approved channel if engineering needs one. For a rerun, record whether it started signed out again; a successful second tap after sign-in doesn't reproduce the first setup.

Use the bug report template generator to turn the failing case into an issue, then add the link source and starting states above. Once a fix arrives, the mobile bug retesting checklist helps you repeat that same journey on the corrected build.