Mobile deep links: opening the app instead of the browser

Three mechanisms, one goal

iOS Universal Links and Android App Links both associate an HTTPS domain with an installed app so a normal link opens the app directly. Custom URL schemes (myapp://) are older, still useful as a fallback, but show an ugly error if the app is missing.

The association files

iOS reads /.well-known/apple-app-site-association — a JSON file, served over HTTPS, with no file extension and no redirects, containing your Team ID and bundle ID. Android reads /.well-known/assetlinks.json containing your package name and the SHA-256 fingerprints of your signing certificates. A link platform that owns your short domain must serve both for you.

Signing fingerprints are the usual bug

Debug builds, release builds and Play App Signing all produce different fingerprints. List every one you actually ship. A single missing fingerprint means the link silently opens the browser instead of the app, with no error to debug.

The fallback chain

App installed and association valid → app opens. App missing → the browser opens your web page, or the store listing if that is more useful. Android intent URLs let you specify the fallback URL inline, which is the most reliable pattern.

Deferred deep linking

If someone taps a product link without the app, ideally they install it and land on that product, not the home screen. This needs the destination to be stashed and matched after install, which is app-side work — the link platform can only carry the parameters.

Test on real devices

Simulators lie about association files. Test a fresh install, an existing install, and the no-app case on both platforms before a campaign goes out.