Why Universal Links exist

Before Universal Links arrived in iOS 9 in 2015, opening an app from a link meant a custom URI
scheme: myshop://product/12345. That approach had three problems. There was no verification, so
another app could claim the same scheme. There was no fallback, so an uninstalled app produced an
error. And from iOS 9 onwards Safari started showing an “Open in…” dialogue for URI schemes,
which made the experience worse.

Universal Links solve all three: the link looks like an ordinary URL
(https://myshop.com/product/12345), the system verifies the association between the domain and
the app, and when the app is missing the browser simply opens.

How it works technically

iOS (Universal Links):

  1. The developer hosts an apple-app-site-association (AASA) file at
    https://yourdomain.com/.well-known/apple-app-site-association — a JSON file with the App ID
    and the paths.
  2. In Xcode the app receives the Associated Domains entitlement with applinks:yourdomain.com.
  3. On install, iOS downloads the AASA file and builds a map of domain plus paths to that app.
  4. When a link is tapped, iOS checks the map, opens the app and passes it the URL.

Android (App Links):

The same idea, through a digital-asset-links.json file on the domain and autoVerify="true" in
the app manifest.

E-commerce scenarios

Scenario Without Universal Links With Universal Links
Email with a product Opens in the browser Opens in the app on the product page
QR code in a physical store Browser, the app is ignored The app, with the product in context
Push notification tap A URI scheme or the browser Straight to the right app screen
Referral link Browser The app plus attribution

Important: Universal Links do not work on a long press (Long Press → Copy Link) or when the
navigation comes from JavaScript (window.location). For reliable routing, use a specialised SDK
such as Branch, AppsFlyer or Firebase Dynamic Links.