apps & deep links

QR codes that open apps

How a QR code can open an app, land on a specific screen, or fall back to the App Store — and why all that lives at the destination, not in the code.

A QR code can absolutely open an app on the right screen — but the code itself isn’t doing the clever bit. A QR only stores text. dottr encodes the exact https:// link you paste and nothing else. Whether that link opens an app, loads a website, or sends someone to the App Store is decided at the destination — the app and its website config — not by the QR or the generator.

The modern way: Universal Links and App Links

The robust approach is the platform’s verified app-linking system. Both use ordinary https:// URLs, so the same link works whether or not the app is installed.

iOS (Universal Links). The app owner hosts an apple-app-site-association file at https://yourdomain/.well-known/apple-app-site-association. It’s JSON served as application/json, but the filename has no .json extension. It lists the app’s ID and the paths the app handles. iOS fetches it (via Apple’s CDN) around the time the app is installed.
Android (App Links). The app owner hosts assetlinks.json at https://yourdomain/.well-known/assetlinks.json, and the app declares android:autoVerify="true" with its package name and signing fingerprint. Android verifies this on install.

This is a two-sided setup the app owner controls. You can’t wire it up from the marketing side — the verification files live on the destination domain and the app has to claim the association.

What happens when the app isn’t installed

This is the nice part. Because it’s a real web URL, the same link just loads the website in the browser. The site can then show a button or redirect to the App Store or Google Play, where the person chooses to install.

To be clear: a QR code cannot silently force-install an app. The most any link can do is open the app if it’s there, or point someone at the store listing. There’s no mechanism to push an install without a tap.

Skip the legacy `myapp://` schemes

You’ll see old advice to encode a custom scheme like myapp://screen. Don’t, at least not for QR codes:

If the app isn’t installed, the link just fails — often silently, with no web fallback.
Any app can register the same scheme, so it can be hijacked.
Phone cameras frequently won’t act on a scheme:// QR at all.

Apple, Google, and the deep-link vendors all now point to Universal Links / App Links for anything user-facing.

Remembering the screen through an install

Standard Universal/App Links do not survive an install. Scan with no app, install, launch — and you land on the app’s home screen, not the page you scanned. Carrying the intended screen through an install is called deferred deep linking, and it needs a third-party service or SDK — Branch, AppsFlyer (OneLink) or Adjust are the usual names.

It’s also less reliable on iOS than Android. Android can pass a referrer through the Play Store install; iOS has no equivalent and restricts device/IP fingerprinting, so it leans on probabilistic or clipboard-based methods. And don’t reach for Firebase Dynamic Links — Google shut it down in August 2025 and the links no longer resolve.

The practical move

Point your QR at a short link you control, not the raw store or deep link. The printed code is fixed forever, but a short link can be re-aimed — swap the store target, or drop in a smart open-or-install link later, without reprinting a thing. Shorter links also draw a cleaner, sturdier code, and the redirect is what makes a static code behave dynamically.