A link that opens a shopping, social, or banking app instead of a web page can be surprising—but it is often expected behavior. iOS and Android both let websites associate certain links with installed apps. This guide explains the difference between those verified links and custom URL schemes, and walks through what to check when a link opens somewhere unexpected.
Key Takeaways
- iOS Universal Links and Android App Links can associate a website’s HTTPS links with an app.
- A custom URL scheme, such as
exampleapp://, is a different mechanism and does not by itself prove that an app controls a website domain. - The outcome can depend on the operating system, browser, installed apps, link format, and user settings.
- To diagnose a link, compare the exact URL in different browsers and check whether the relevant app is installed.
How web links open apps
A normal web link uses a URL such as https://shop.example/products/42. If the site and app have been configured to work together, the operating system may open the installed app for that link. If not, the browser normally handles it as a web page.
iOS Universal Links
Universal Links connect an app to a website domain. The app and website need matching configuration: the app declares its associated domains, and the website publishes an Apple App Site Association file describing which app can handle which paths. When the association is in place, a supported HTTPS link can open the app; otherwise, it can open on the web.
The system’s choice is not necessarily identical for every tap. User choices and how a link is opened can affect whether it stays in Safari or switches to an app. A link that remains in the browser is not, on its own, proof that the association is broken.
Android App Links
Android App Links are a way to associate website URLs with an Android app. The app declares the web links it can handle, and the website publishes a Digital Asset Links file to establish the association. If the link matches and the association is verified, Android can route it to the app. If not, Android may show a chooser or open the website, depending on the device and link-handling settings.
Exact menus and behavior can differ across Android versions and device manufacturers.
Verified links versus custom URL schemes
A verified web-to-app link starts with a web URL, usually https://, and relies on a domain-to-app association. A custom scheme uses a different form, such as exampleapp://product/42. Apps can register custom schemes, but the scheme alone does not establish that the app is authorized to handle a particular website’s HTTPS links. Other apps may also register the same scheme, and a custom-scheme link may not have a useful browser fallback.
If a page redirects from an HTTPS address to a custom scheme, the browser or operating system may ask for confirmation, open the app, or fail to handle the link. Redirect behavior varies, so test the original link and the final destination separately.
Version note: The platform explanation here describes the established distinction between verified web links and custom schemes. I could not live-check current Apple or Google platform documentation for this article, so confirm implementation details against the documentation for the OS versions you support.
Diagnose a link that opens an app
Use this sequence to narrow down what is handling the URL:
- Inspect the exact link. Check whether it starts with
https://or uses a custom scheme. Note the hostname, path, and any redirects. A shortened link may lead to a different URL than the one shown. - Check the operating system and browser. Try the same link in another browser on the same device, if available. Then compare with a different device or operating system. If only one browser behaves differently, its settings or link-handling behavior may be relevant.
- Check installed apps. If the app is not installed, a verified web link will generally have no installed app to open. If it is installed, try the link again after confirming which account or app instance is active.
- Try a different way of opening it. A link tapped inside a messaging or social app may be handled by that app’s built-in browser before it is handed to the operating system. Copy the URL and paste it into the device’s regular browser to compare.
- For developers, verify the association and matching rules. Confirm that the app’s declared domains match the website’s association file, that the file is served from the expected domain location, and that the link’s host and path match the rules. Check redirects too: the initial URL and final URL may not have the same host.
- Retest after configuration changes. Association changes may not appear immediately on every device. Test on a clean or separately configured device where possible, and record the OS version, browser, app version, and full URL.
For developers, a URL parser can help inspect the host and path, but parsing a URL does not establish whether the operating system has verified the app-to-domain association.
Workarounds for mobile users
- Copy and paste the web address into the browser’s address bar instead of tapping the link. This can help when the link came from an app with its own browser.
- Use a “Open in browser” option in the app or link menu if one is offered. The label and availability vary by app.
- On Android, review the app’s link-handling settings. In the system settings for the app, look for supported links or defaults and adjust them if your device provides that option. Menu names and controls vary by Android version and manufacturer.
- On iPhone or iPad, try opening the site by entering its web address in Safari rather than tapping a link that may be associated with an app. The available behavior can still depend on the link and user choices.
- If the link uses a custom scheme, ask for the HTTPS web link. A custom-scheme link may only work when its app is installed and may not provide a browser fallback.
These steps are workarounds, not guarantees. Device settings, browser behavior, app configuration, and platform version can change the result.
Common Mistakes
- Assuming every app-opening link is a custom scheme. Verified Universal Links and Android App Links use web URLs too.
- Assuming an HTTPS URL must stay in the browser. A correctly associated link may open its app when that app is installed.
- Testing only one path or hostname. Associations can apply to specific hosts or paths; a subdomain or redirected URL may behave differently.
- Blaming the browser before checking the link source. An in-app browser, redirect, or link-preview feature may affect how a tap is handled.
- Treating a URL parser as an association checker. A parser can show URL components, but it cannot verify the platform’s app-domain configuration.
Best Practices for Developers
- Prefer HTTPS links with platform-supported domain association when you need dependable web-to-app linking.
- Keep an accessible web destination for users who do not have the app or prefer not to open it.
- Test links with the app installed and uninstalled, across relevant browsers, and on the OS versions you support.
- Check the initial URL, redirect chain, exact hostname, and matching path rules when results differ.
- Use custom schemes only when their limitations and fallback behavior are acceptable; do not treat them as proof of website ownership.
Conclusion
When links open an app instead of the browser, the cause is usually a combination of link type, app installation, platform association, and user or browser settings. Compare the exact URL across browsers and devices first; developers should then check the domain association and link-matching configuration.