How to Test Deep Links in Mobile Apps (Android + iOS)

Deep links are the hyperlinks of mobile. A URL opens the right screen in your app, preserves context, and handles the case where the app is not installed. They power email campaigns, push notification

Deep links are the hyperlinks of mobile. A URL opens the right screen in your app, preserves context, and handles the case where the app is not installed. They power email campaigns, push notifications, referrals, shared content. When they break, everything downstream breaks — and deep link bugs are often invisible in analytics until someone checks.

What deep links actually are

Three flavors:

1. Custom scheme URIs — myapp://product/123. Work on-device, break when shared anywhere that does not recognize the scheme.
2. Universal Links (iOS) / App Links (Android) — https://myapp.com/product/123. Open the app if installed, open the website otherwise. The modern default.
3. Deferred deep links — work even if the app is not installed. Install, then open to the intended destination. Implemented via Firebase Dynamic Links, Branch, AppsFlyer, or custom install-referrer logic.

What to test

Installed app

1. Universal/App Link from any context (email, SMS, browser, other apps) → opens app
2. Custom scheme from same contexts → opens app where supported
3. App in foreground → navigates without restart
4. App in background → brings to foreground and navigates
5. App killed → cold starts and navigates (not home screen first)
6. Multiple chained deep links (rapid taps) → last one wins, no crash

Not installed

1. Universal/App Link → opens your website
2. Deferred deep link (if used) → installs app → post-install opens to the destination
3. Post-install attribution works (user came from campaign X)

Content types

1. Product page deep link shows correct product
2. Search results deep link shows the search with query preserved
3. Article deep link scrolls to the article
4. Action deep link (e.g., "share settings") opens the right modal
5. Authentication-required deep link redirects to login, then back to destination

Auth and session

1. Deep link for unauth user → login → lands on original target
2. Deep link for logged-out user with cached deep link → login shows "continue to [target]" button
3. Expired session deep link → refresh or re-login, preserve destination
4. Deep link for different user than logged in → either prompt account switch or reject cleanly

Edge cases

1. Malformed URL → lands on home, does not crash
2. URL with special characters (emoji, unicode, spaces) → decoded correctly
3. Very long URL (2000+ chars) → handled or rejected cleanly
4. Path that looks like a deep link but is not mapped → falls back to home or 404 screen
5. Deep link with query parameters → all parsed correctly
6. Deep link with fragment (#) → handled
7. Fake deep link in a malicious notification payload → cannot bypass auth checks

Security

1. Deep link cannot bypass auth (visiting /settings/account unauthenticated does not show account data)
2. Deep link cannot cross user contexts (user A's deep link cannot access user B's data)
3. Deep link parameters sanitized (SQLi, XSS patterns rejected)
4. Path traversal (../../../etc/passwd) rejected
5. Third-party app launching your deep link → no privilege escalation

Analytics

1. Deep link source tracked (campaign_id, source, medium)
2. Attribution propagates to first event after open
3. Deep link failures logged (malformed, unmapped, rejected)

Manual testing

Create a test matrix:

• Contexts: Messages, Email (Gmail + Apple Mail), Safari, Chrome, WhatsApp, Slack, another app via share sheet
• States: app installed + foreground, app installed + background, app installed + killed, app not installed
• URLs: valid happy-path link, malformed, expired, unauthenticated-required, very long

Send yourself links in each context. Tap each. Record what happens.

On Android, use adb shell am start -a android.intent.action.VIEW -d "myapp://product/123" to fire a deep link without the source-app overhead. On iOS, xcrun simctl openurl booted "myapp://product/123" for simulator, Safari URL bar for physical.

Automated testing

Android

@Test
fun deepLink_opensProductScreen() {
    val intent = Intent(Intent.ACTION_VIEW, Uri.parse("myapp://product/123"))
    val scenario = ActivityScenario.launch<MainActivity>(intent)
    onView(withId(R.id.product_title)).check(matches(withText("Product 123")))
}

For App Links, use adb shell am start -W -a android.intent.action.VIEW -d "https://myapp.com/product/123" in an instrumented test and assert the correct activity started.

iOS

func testDeepLink() {
    let app = XCUIApplication()
    app.launch()
    let url = URL(string: "myapp://product/123")!
    // Via UIApplication.shared.open or test-time injection
    app.openURL(url)
    XCTAssertTrue(app.staticTexts["Product 123"].waitForExistence(timeout: 5))
}

End-to-end with Playwright / Appium

Open Safari (or Chrome), type the Universal Link URL, tap the "Open in App" banner if shown, assert app opens to the correct screen.

How SUSA handles deep links

SUSA can launch your app with a deep link intent directly and continue exploration from that entry point:

susatest-agent test myapp.apk --deep-link "myapp://product/123"
susatest-agent test myapp.apk --deep-link "https://myapp.com/order/456"

The adversarial persona tries malformed deep links (injection patterns, traversal, very long paths). Results are tracked per-deep-link: did it navigate to the right screen, was auth enforced, any crashes or errors.

For deferred deep links, you need a dedicated tool (Firebase, Branch) — those are installation-flow-specific and outside SUSA's scope.

Common production bugs

1. Deep link lost during cold start — splash activity consumes intent, main activity never sees it. Fix: pass intent explicitly or use a dedicated deep link handler.
2. Auth loop — deep link triggers login, login triggers deep link, login triggers... Fix: clear deep link intent after consumption.
3. Universal link opens web, not app, on iOS — association file misconfigured or not served with correct content-type. Fix: validate via swcutil tool.
4. App Link opens but scheme-only link does not — domain verification fine but intent filter scheme mismatch. Fix: include both schemes in intent filter.
5. Deep link triggers crash on old versions — backend updated URL format, app does not recognize. Fix: always degrade gracefully, never crash on unknown paths.

Test deep links every release. The per-context matrix is tedious but catches the bugs that analytics hide.