Universal Links, App Links and deferred routing that holds

Deep links fail in two places far more than anywhere else. On iOS, the email vendor's click-tracking domain: Braze, Iterable, Salesforce Marketing Cloud and Klaviyo all serve the click from a domain they control, and unless that domain hosts its own apple-app-site-association file and appears in your applinks entitlement, every campaign link you send opens Safari instead of the app. On Android, the SHA-256 fingerprint in assetlinks.json is the upload key rather than the Play App Signing key, so verification silently fails and the chooser dialog appears. Five of the last six audits I ran had one of these two. Neither is visible in any dashboard, because a link that opens the web is a working link as far as your ESP is concerned. What gets built: The association files first, hosted correctly rather than approximately. AASA at the well-known path, served as application/json, no redirects anywhere in the chain, on every domain that can originate a link including tracking subdomains and any regional domains. Path patterns written against a routing table your app team owns, not one buried in a vendor dashboard where a marketer can change a rule and break checkout on a Friday. On Android, assetlinks.json carrying the correct signing fingerprint, autoVerify on the intent filters, and verification confirmed on device rather than assumed. The routing table: One table, versioned in your repository, mapping URL patterns to screens with a stated fallback for each. Every route answers three things: what happens when the app is installed, what happens when it is not, and what happens when the destination needs an authenticated session. That third case is where most implementations quietly drop the user on a home screen after login and lose the intent they arrived with. I specify the continuation. Deferred deep linking, said plainly: On Android it works. The Play Install Referrer carries the referrer string through the store reliably, and deferred routing is a normal engineering task. On iOS it does not, and I will not pretend otherwise. Since the fingerprinting methods were shut down, deferred routing on iOS means either a pasteboard read with a visible paste prompt the user must accept, or nothing. So I design the flows so the important ones do not depend on it: a short code the user carries, a Custom Product Page that makes the destination obvious, or an accepted, measured drop. Any vendor promising you reliable iOS deferred deep linking without a paste prompt is describing something Apple removed. What I refuse: I will not put a smart app banner on a paywalled article template without measuring what it costs in page views first, because on publisher inventory it frequently costs more than the installs are worth. I will not ship routing rules that only a vendor dashboard can change. I will not sign off on a launch where the test matrix has not been run on real devices. The test matrix: Thirty-odd cases, run on device, not simulated. App installed cold, app backgrounded, app absent. Origin from Safari, Chrome on iOS, Gmail, the Instagram and Facebook in-app browsers, WhatsApp, a QR code, an SMS, and a plain note. Those in-app browsers are where the sanctioned behaviour and the real behaviour part company most often. Wrong buyer: If you want the links working and do not want to own a routing table afterwards, an agency retainer suits you better. If your app has no authenticated state and one content type, this is more engineering than your problem needs.