Why a Link Opens the Wrong App on Mobile

A link that works normally on a desktop can open an unexpected app—or stay in a browser—on a phone. Mobile operating systems decide how to handle links using the URL scheme, installed apps, domain associations, and sometimes the browser or app where the link was tapped.

This guide explains the difference between web links and app links, then walks through a practical way to diagnose the behavior on iOS and Android. Exact settings and behavior can vary by operating system version, browser, and app configuration.

Key Takeaways

• An https:// link is an ordinary web URL, but a valid domain association can let a mobile app open it instead.
• Custom-scheme links, such as exampleapp://item/42, are different from verified HTTPS app links and may be claimed by more than one app.
• Check the exact URL, installed apps, system link preferences, association files, redirects, and the fallback destination—in that order.
• Test the link from the browser and the app where people actually tap it; link-handling behavior can differ between contexts.
• Provide a useful web destination so the link still works when the app is missing or cannot be opened.

Three kinds of links that are easy to confuse

Ordinary web links

An ordinary web link uses a web scheme, usually https://, and points to a website:

https://shop.example.com/products/42

On a desktop, it normally opens in a browser. On a phone, the same URL may open an installed app if the domain and app have been configured for platform link handling. Otherwise it opens a browser.

Deep links

A deep link takes a person to a particular place in an app. The term describes the destination or behavior, not one universal URL format. A deep link might use a custom scheme:

shopapp://products/42

Custom schemes can be convenient, but they do not provide the same domain-ownership verification as HTTPS app links. If multiple installed apps register the same scheme, the operating system's choice or prompt can vary. A link using a custom scheme may also fail when the intended app is not installed.

Platform-verified HTTPS app links

Apple Universal Links and Android App Links are platform mechanisms for associating an app with a website domain. They use HTTPS URLs, but require the app and website to be configured to establish that association. When the setup is valid, an eligible URL can open the associated app; otherwise, it can remain a web link.

A matching-looking URL alone is not enough. The host, path, app configuration, and domain association all matter. Subdomains such as www.example.com and example.com should be treated as distinct hosts unless each has been configured as needed.

A diagnostic workflow

Work through these checks with the exact URL that fails. Record the full URL, including its scheme, hostname, path, and query string. A shortened link or a link copied from a message may take a different route from the URL you expected.

1. Compare the URL in the address bar with the intended destination

Tap the link and inspect where it goes. If it passes through a shortener, tracking service, redirect, or campaign landing page, note each hostname and the final URL. Compare that sequence with a link that works.

Check for differences such as:

• http:// versus https://.
• www.example.com versus example.com.
• A different subdomain, such as m.example.com.
• A path or query parameter that routes to a different screen or app.
• An intermediate redirect that drops or changes part of the URL.

For a first test, use the final HTTPS URL directly rather than a shortened or redirected version.

2. Test from more than one place

Try the same URL by entering or pasting it into the phone's browser, and then by tapping it in the original context, such as an email, messaging app, social app, or QR-code reader. Also test in another browser if available.

If it works in one place but not another, the source app or browser may be affecting how the link is opened. If the address changes before the app launches, investigate the redirect chain. Do not assume that a browser's behavior represents every app that can handle links.

3. Check which relevant apps are installed

Confirm that the expected app is installed and updated, and note other apps that could handle the same kind of URL. Then test on a device without the expected app, if possible. This reveals whether the website fallback works.

If the wrong app opens, check the device's supported controls for link-opening or default-app preferences. Names and locations differ across OS versions and manufacturers. On Android, inspect the app's supported-link or default-link settings where available. On Apple devices, check whether the user previously chose to continue opening that site's links in a browser; the precise controls can depend on how the link was opened and the OS version.

Changing a user preference can help diagnose a device-specific issue, but it does not repair an incorrect app-to-domain association.

4. Verify the domain association

If you maintain the app and website, check the platform association for the exact hostname in the URL and for the app identifier used by the installed build.

For Apple Universal Links, verify that the website's Apple App Site Association configuration and the app's associated-domains entitlement agree. Check that the relevant paths are included and that the association resource is served from the expected host. A configuration for the apex domain does not automatically establish the same setup for every subdomain.

For Android App Links, verify the website's Digital Asset Links declaration and the app's intent filters. Confirm that the declared package and signing-certificate fingerprint match the app build installed on the device. A debug build and a store-signed release build can use different signing certificates.

The exact requirements and validation tools can change. I could not retrieve current Apple or Android documentation in this environment, so verify implementation details against the current platform documentation before changing a production configuration.

5. Follow redirects and test the fallback

Check whether every redirect preserves the intended HTTPS host and path. A link may start on the associated domain but end on a different host that has not been associated with the app. Redirect behavior can also vary by browser and OS version, so test the real chain on target devices rather than relying only on a desktop browser.

Test at least these outcomes:

• The app is installed and the URL should open a specific screen.
• The app is not installed and the URL should show a useful web page.
• The app is installed, but the requested screen or item does not exist.
• The URL is opened from the browser and from the app that originally shared it.

A fallback should not leave the person on a blank page or a broken custom-scheme URL. Prefer a meaningful HTTPS page, with a clear next step when the app is needed.

How to narrow down the cause

These are diagnostic clues, not proof of a single cause. Reproduce the case on the affected device and inspect the actual URL and app build before changing configuration.

Common Mistakes

• Assuming every HTTPS link must stay in the browser. A correctly configured Universal Link or App Link can open an app.
• Assuming a deep link means a custom URL scheme. Deep links can also use verified HTTPS URLs.
• Checking only the main domain. The exact host in the link—including www or another subdomain—matters.
• Testing only on a developer build. Signing identity, installed build, and OS state can differ from a user's device.
• Blaming the operating system before checking redirects. A redirect can change the host or path and alter which app is eligible to handle the URL.
• Using a custom-scheme link as the only destination. It may not work if the app is absent or another app claims the scheme.
• Treating a user's default-link preference as a server configuration fix. Preferences can explain a particular device's behavior, but do not establish a missing domain association.

Best Practices

• Use HTTPS URLs as shareable links and configure platform app associations for the hosts and paths the app should handle.
• Keep links useful on the web. Treat app opening as a supported route, not the only route.
• Test release-signed builds on real devices across the OS versions and browsers you support.
• Test direct URLs, redirecting URLs, subdomains, query parameters, app-not-installed cases, and links opened from common sharing apps.
• Make app routing tolerant of missing, malformed, or outdated destinations; show a sensible screen rather than silently opening the wrong content.
• When reporting a bug, capture the full starting and final URLs, device and OS version, browser or source app, installed app version, and whether the app was already installed.

Conclusion

When a link opens the wrong app on mobile, start with the exact URL and how it reaches the device. Then check installed apps and user link preferences, verify the app-to-domain association for the precise host and path, and test redirects and fallbacks on the affected platforms. The same link can behave differently across browsers, OS versions, and app configurations, so reproduce the real user journey before settling on a fix.