URL Scheme Testing Guide
How to Test URL Scheme and Deep Links on Mobile
URL Scheme and deep link bugs are hard to debug because the failure can happen in the browser, WebView, operating system, app registration, redirect chain, or callback URL. This guide gives you a real-device workflow for testing each layer without guessing.
Quick answer: how do you test URL Schemes?
Test a URL Scheme by separating the direct scheme launch from the full redirect flow. First open the scheme directly on the device. Then test the same scheme from a mobile browser, from the target WebView page, and after every redirect that can modify query parameters. Confirm whether the app is installed, whether the scheme is registered, whether the callback URL keeps its state, and whether the WebView blocks external navigation.
When URL Scheme testing matters
- A payment, login, OAuth, or SSO redirect fails only on mobile.
- A button opens the app from Safari but not from an in-app WebView.
- The target app opens but loses callback parameters.
- Android and iOS handle the same link differently.
- A fallback web page appears even when the app is installed.
URL Scheme testing workflow
1. Test the raw scheme first
Begin with the smallest possible URL. If the raw scheme does not open the app, the problem is not the web page. Check app installation, scheme registration, platform rules, and whether the scheme was typed or encoded correctly.
myapp://open
myapp://open?screen=profile&id=1232. Test the encoded URL from a tool page
Use the URL Scheme testing tool to encode, decode, and open test links. This avoids mistakes caused by double encoding, missing separators, or unsafe characters in query values.
3. Test the full mobile page flow
Open the real page on the phone and trigger the same button or redirect the user will use. The full flow may add tracking parameters, login state, callback URLs, or platform-specific fallback behavior.
4. Compare browser and WebView behavior
Safari, Chrome, and an app WebView can handle external navigation differently. If the scheme opens in Safari but not in a WebView, inspect whether the host app intercepts navigation, blocks unknown schemes, or requires a whitelist.
5. Verify callback state
The target app may open successfully but fail to return the user to the expected page. Log every redirect URL and make sure the callback keeps tokens, state, order IDs, and original page parameters.
Common URL Scheme examples
| Pattern | Example | What to verify |
|---|---|---|
| Open app screen | myapp://product?id=42 | App opens and navigates to the expected screen |
| Web callback | myapp://pay?callback=https%3A%2F%2Fexample.com%2Fdone | Callback URL survives encoding and redirects |
| Fallback URL | https://example.com/open?target=myapp%3A%2F%2Fhome | Fallback only appears when the app cannot open |
Common URL Scheme failures
| Symptom | Likely cause | Next check |
|---|---|---|
| Nothing happens | Scheme is not registered or WebView blocks external navigation | Test raw scheme and WebView navigation policy |
| App opens wrong screen | Missing query parameter or route mismatch | Decode final URL and inspect app route mapping |
| Callback fails | State parameter lost in redirect or encoding | Trace each redirect URL |
| Works in Safari, fails in WebView | Host app intercepts, blocks, or rewrites navigation | Compare browser and WebView behavior |
URL Scheme testing checklist
- Is the target app installed on the test device?
- Does the raw scheme open outside the web page?
- Is the URL encoded exactly once?
- Does the WebView allow external scheme navigation?
- Are callback, state, and order parameters preserved?
- Does fallback behavior match installed and not-installed states?
Test mobile links with DebugAnywhere
DebugAnywhere helps you open test URLs on real devices, compare WebView behavior, inspect runtime state, generate QR codes, and validate URL Scheme flows from the same mobile environment where the bug appears.