Next-Gen App & Browser Testing Cloud
Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

To open a link in the app instead of the browser, the app has to be installed and allowed to handle that website's links. On Android, open Settings, go to Apps, select the app, tap Open by default, and turn on Open supported links. On iOS there is no toggle: if the app is installed and registered for the domain through Universal Links, a matching link opens the app automatically. When this does not happen, the cause is almost always that the app is not installed, the option is disabled, or the app's link verification is failing, so the system falls back to the browser.
Android lets you decide, per app, which web addresses should bypass the browser and launch the app directly. This is controlled by the Open by default screen.
You can also long-press a link and choose Open in [app] when the app supports that domain. If you once chose to always open a domain in the browser and want to undo it, go to Settings > Apps, open the menu, and tap Reset app preferences to bring back the open-by-default prompts.
iOS handles this through Universal Links rather than a manual switch. When the app declares a domain and is installed, the system intercepts matching links and opens the app for you.
Unlike Android, iOS has no per-app "open supported links" toggle. Routing is decided entirely by the app's association file on the developer's server, so there is nothing extra for you to switch on as a user.
If you build or test apps, the user-facing behaviour above is the result of a few well-defined mechanisms. On Android, the app declares an intent filter for http and https links and sets autoVerify to true, while the website hosts a Digital Asset Links file at /.well-known/assetlinks.json so Android can confirm the app owns that domain. Once verified, those App Links open the app with no chooser. Custom-scheme deep links such as myapp://path need no verification but usually surface a chooser and cannot be triggered reliably from a plain web page.
On iOS, the app adds the Associated Domains entitlement with an applinks: entry, and the website hosts an apple-app-site-association (AASA) file at /.well-known/ that lists the app identifiers and the paths to capture. When the file matches, iOS routes those Universal Links straight to the app. For cases where the app is not yet installed, deferred deep linking sends the user to the store first and then opens the intended in-app content after the first launch.
| Aspect | Android App Links | iOS Universal Links |
|---|---|---|
| Link type | Standard http/https URLs | Standard https URLs |
| Verification file | assetlinks.json in /.well-known/ | apple-app-site-association in /.well-known/ |
| App configuration | Intent filter with autoVerify | Associated Domains entitlement |
| User toggle | Open supported links (per app) | None; automatic when registered |
| If unverified | Shows app/browser chooser | Falls back to Safari |
Because routing depends on a verification file plus the exact OS version and OEM skin, the same link can open the app on one phone and the browser on another. For a quick local check, Android testers can trigger a link with adb shell am start -a android.intent.action.VIEW -d "https://example.com/path", while iOS testers can use xcrun simctl openurl on a simulator. These confirm the intent filter or association is wired up, but they do not capture how a real Samsung One UI or Xiaomi build resolves the chooser, or whether the AASA file is reachable from a real network.
To validate App Link and Universal Link behaviour the way users actually experience it, run the links across real Android and iOS devices using TestMu AI'sReal Device Cloud. You can confirm that verified links open the app directly, reproduce cases where they fall back to the browser, and capture logs and video for the OS and device combinations that matter to your users.
Usually because the app is not installed, the Open supported links option is turned off on Android, or the app's link verification is failing. Both platforms rely on a verification file hosted on the website's domain; if that file is missing, misconfigured, or unreachable over HTTPS, the system will not trust the link for the app and falls back to the browser.
Go to Settings, open Apps, select the app, tap Open by default, and enable Open supported links. You can also review the list of supported web addresses to confirm the domains that should route to the app. After that, tapping a matching link opens the app directly.
iOS uses Universal Links. When the app is installed and registered for a domain, tapping a matching link opens the app automatically with no toggle required. If it opens in Safari instead, long-press the link and choose Open in the app, or reinstall the app so iOS re-fetches the association file.
Many social apps open links in their own in-app browser or webview. Because the tap never reaches the operating system, App Links and Universal Links do not fire there. Opening the same link in the system browser, or choosing Open in external browser from the app's menu, lets the link route to the native app.
Custom-scheme deep links use a URI like myapp://path and are not verified, so Android often shows a chooser asking whether to open the app or the browser. App Links are standard https links verified through a Digital Asset Links file, so a verified link opens the app directly with no chooser.
On Android use adb am start with the VIEW action and the link URL; on iOS use xcrun simctl openurl on a simulator. For real-world coverage, run the same links across real Android and iOS devices in a device cloud, since verification and chooser behaviour vary by OS version and OEM.
KaneAI - Testing Assistant
World’s first AI-Native E2E testing agent.

TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance