Deep Link Testing

Why it matters

Deep links carry the moments that matter: a campaign, a password reset, a delivery update. When one breaks, the failure is quiet. The user lands on the home screen, on a web page that says "not found", or worse on someone else’s data, and the team hears about it through support tickets. Many causes sit outside the app’s code, in a file on the website, a signing certificate or a redirect added by an email tool, so ordinary UI tests that start inside the app do not catch them.

A deep link is also input from outside the app. Anyone can craft one, so the app must validate it and must never skip sign-in or perform an action without confirmation because a link asked it to. For the tester this is a compact, high-value area: a small, well-chosen set of combinations covers the real risks once you know which states and platform rules to combine.

Custom schemes, Android App Links and iOS Universal Links

A custom URL scheme link uses a scheme the app registers for itself, such as shop://orders/A-1042. It is simple, but nothing proves the scheme belongs to your app: another app can register the same one, and when no installed app handles it the link just fails. Keep it for links inside your own products, not for links you send to users.

Android App Links are ordinary https links that Android verifies. The app declares the domain in an intent filter (the manifest entry that lists the links an app can open) with android:autoVerify="true", and the website publishes /.well-known/assetlinks.json with the app’s package name and the SHA-256 fingerprint of its signing certificate. When verification succeeds, the link opens the app directly. Since Android 12, an unverified https link opens in the default browser unless the user has approved the domain for the app in its settings.

iOS Universal Links follow the same idea. The app lists the domain in its Associated Domains entitlement (applinks:shop.example.com), and the website publishes an apple-app-site-association file naming the app and the paths it handles. Since iOS 14, devices fetch this file through Apple’s content delivery network (CDN), which can take up to 24 hours to pick up a change; a device downloads the file when the app is installed and then checks for updates only about once a week, so after a fix, wait for the CDN and reinstall the app on the test device. A universal link typed into Safari’s address bar opens the website, and so does a tap on a same-domain link while the user is already on that site in Safari: platform behaviour, not a defect.

• Both files are served over HTTPS with a valid certificate and without redirects; assetlinks.json as application/json.
• Every Android build is signed with a key, and the fingerprint identifies that key’s certificate. It must match the key that signed the installed build: debug builds, release builds and builds re-signed by Google Play App Signing have different fingerprints, and the file can list several.
• The iOS file has no .json extension, and its paths apply to every installed version of the app, old ones included.
• Deferred deep linking, reaching the target after installing the app from the store, is not a platform feature. If the requirement asks for it, your team or a third-party SDK builds it, and it needs its own tests.

https://shop.example.com/.well-known/assetlinks.json  (Android App Links)
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.shop",
    "sha256_cert_fingerprints": ["14:6D:E9:...:2E:5F"]
  }
}]

https://shop.example.com/.well-known/apple-app-site-association  (iOS Universal Links)
{
  "applinks": {
    "details": [{
      "appIDs": ["ABCDE12345.com.example.shop"],
      "components": [{ "/": "/orders/*" }]
    }]
  }
}

Try it: JSON Validator Try it: URL Parser

Installed or not, signed in or not

Test the same link in several states, because each state takes a different path. Not installed: a custom-scheme link fails, while a verified https link opens the website at the same URL, so that URL must be a real page, ideally with a way to get the app, never a 404. Installed but not verified: the website opens although the app is there, the classic sign of a wrong fingerprint or a broken association file. Installed in an older version: the app must fall back to a sensible screen for a path it does not know, not crash.

How the app is running matters too. A link that arrives while the app is closed starts it from scratch; one that arrives while it is in the background or showing another screen reaches different code. Test both, and check where Back leads afterwards.

Then the user. Signed out: sign-in appears and, after it succeeds, the linked screen opens, not the home screen. Signed in as the owner: the right record opens. Signed in as another user: a clear not-available message and none of the owner’s data, enforced by the server and not only hidden by the app. Session expired or first launch after install: re-authentication, onboarding or a permission prompt must not swallow the link.

Try it: Pairwise Testing Generator

Triggering links and checking verification

Tap links from the channels users actually use: the email app, SMS, a chat app, a QR code scanned with the camera, a push notification. Some apps open links in their own in-app browser, which may not hand them to your app, and email click tracking often wraps a link in a redirect through another domain that is not associated with your app. Test the link exactly as it is sent, not the clean URL from the ticket.

For fast, repeatable checks use the platform tools. On Android, adb fires a link and lets the system choose the handler, and since Android 12 it shows and re-runs domain verification. On the iOS Simulator, simctl opens a URL; on a real iPhone, paste the link into Notes or Messages and tap it.

# Android: fire the link and let the system choose the app (no package name)
adb shell am start -W -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "https://shop.example.com/orders/A-1042"

# Android 12+: domain verification state, then a fresh verification
adb shell pm get-app-links com.example.shop
adb shell pm verify-app-links --re-verify com.example.shop

# iOS Simulator: open the link through the system
xcrun simctl openurl booted "https://shop.example.com/orders/A-1042"

Try it: Redirect Checker

Worked example: the order link in a shipping email

Requirement: "The shipping email links to the order. With the app, the link opens the order details; without it, the order page on the website." The link is https://shop.example.com/orders/A-1042 and the order belongs to Sara. Start from a decision table over four true/false conditions: installed, verified, signed in and owner. Each column of the table is one combination of the four with the screen the link should land on, and the columns give the core cases; the lesson on decision table testing shows how to build one and merge columns where a condition makes no difference. Then add running-state and channel variations to the riskiest columns instead of multiplying everything.

• Installed, Sara signed in, app closed: order A-1042 opens, and Back leads to the orders list as agreed.
• Same, with the app in the background on the cart: order A-1042 opens and the cart is unchanged.
• Installed, signed out: sign-in appears; after Sara signs in, order A-1042 opens, not the home screen.
• Installed, another user signed in: a not-available message, no data from A-1042, and the API refuses the request for that order.
• Not installed: the order page opens on the website (after web sign-in) with a link to the store; no 404.
• A build signed with a key missing from assetlinks.json: the website opens and pm get-app-links does not show the domain as verified. Report it against the configuration, not the screen.
• Unknown, empty or overlong id (/orders/A-9999, /orders/, 300 characters): a clear error screen, no crash.
• The real email, through its click-tracking redirect, in each supported email app: the same result as the clean link.

Try it: Decision Table Generator Try it: Test Case Generator

Frequently asked questions

References

• About App LinksAndroid Developers (Google)Android App Links: deep links to your own website that the system verifies through a Digital Asset Links file (assetlinks.json), so they open the app directly.
• Allowing apps and websites to link to your contentAppleUniversal links on Apple platforms: ordinary web links that open the app when it is installed — once the system has checked a file on your website — and the website otherwise.
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationThe testing manual that goes with MASVS: techniques and test cases for verifying mobile app security.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP FoundationOWASP's security requirements for mobile apps, grouped into control areas such as storage, cryptography, authentication, network and platform interaction.