The technical cause is almost always the same: an association file (apple-app-site-association on iOS, assetlinks.json on Android) that was configured once, worked in a staging environment, and was never re-verified against the exact combination of domain, certificate, and app signing key used in production.
When a mobile app fails to route deep links correctly after launch, the cost of fixing it-re-releasing, re-testing, and managing user confusion-is substantially higher than catching the failure before release. This is a process discipline as much as a technical one, and it's the specific gap where a mobile engineering team with production experience across fintech and consumer apps adds measurable value.
TL;DR
iOS Universal Links and Android App Links both depend on a domain-verification file hosted over HTTPS. If that file is malformed, uncached, or mismatched to the signing certificate, the link silently falls back to a browser instead of opening the app.
Deferred deep linking (opening the right in-app screen after a fresh install) fails for different reasons than direct deep linking, and testing one does not validate the other.
Cold app starts, Apple's CDN caching delays, and incorrect JSON in the association file are the most commonly documented root causes of failures that pass in staging but break in production.
A mobile engineering team with a written pre-release checklist catches these failures by testing on physical devices, real domains, and production signing certificates, not simulators with self-signed certs.
Fixing deep linking after launch costs materially more than validating it before release, because the failure is often invisible in analytics until conversion drops are already attributed to something else.
About the author: 724SOFTWARE is a Vietnam software team that has shipped mobile applications handling real-time trading, payments, and fan-engagement traffic, including a React Native app with 500,000+ downloads built to absorb concurrent voting spikes and an in-app trading experience embedded inside a live mobile banking app. That production experience, across iOS and Android release cycles for regulated and high-traffic consumer products, is the basis for the checklist below.
What Is the Technical Difference Between Deep Linking and Universal Links?
A deep link is any URL that opens a specific screen inside an app rather than the home screen; a universal link is Apple's HTTPS-based implementation of that concept, and Android's equivalent is called an App Link. Both moved away from custom URL schemes (like myapp://) toward HTTPS-based domain verification because custom schemes could be claimed by any app and offered no security guarantee.
The technical mechanics differ in ways that matter for testing:
iOS Universal Links | Android App Links
| |
|---|---|---|
Verification file | apple-app-site-association (no file extension, JSON object) | assetlinks.json (JSON array) |
Mapping method | applinks dictionary linking Team ID + Bundle ID to URL paths | Digital Asset Links protocol linking package name + SHA256 fingerprint |
Verification timing | Apple's CDN fetches and caches the file | Downloaded directly from host at install time |
Supported schemes | HTTP and HTTPS only | HTTP and HTTPS only, auto-verification restricted to these |
Both files must be hosted over HTTPS with a valid certificate, and both restrict auto-verification to http and https schemes. A single typo in either file, or a certificate that expires between deployments, breaks the whole mechanism without triggering an obvious error anywhere in the app itself.
Why Do Deep Links Work in Staging but Break in Production?
The most common reason is that staging environments and production environments rarely share the same domain, certificate authority, or app signing key, and Universal Links and App Links verify against exactly those three things. Documented root causes include incorrect JSON formatting in the association file, missing or expired HTTPS certificates, caching delays on Apple's CDN, and routing failures specifically during cold app starts (when the app is not already running in memory).
Cold-start routing failures are worth calling out separately because they're the hardest to catch in manual QA. A tester who taps a link while the app is already open in the background sees correct behavior. The same link, tapped when the app has been fully killed, can route to the wrong screen or drop the deep-link parameters entirely, because the app's navigation state has to be reconstructed from scratch rather than resumed. A QA pass that only tests warm-start scenarios will sign off on a build that fails for a meaningful share of real users, since a cold start is the default state for anyone opening a link from an email, SMS, or social app after not using your app that day.
What Is Deferred Deep Linking and Why Does It Fail Differently?
Deferred deep linking is the ability to route a new user to a specific in-app screen after they install the app from a link, rather than losing that context because the app wasn't installed yet. This requires a different mechanism than direct deep linking, typically involving a match on device fingerprint or clipboard data between the browser click and the first app open.
Testing direct deep links validates none of this. A team that runs a full regression suite against Universal Links and App Links but never tests the "click link, install app, open app, land on correct screen" flow will ship a build where marketing attribution and onboarding personalization silently fail for every new-user acquisition campaign, while every existing-user link works fine. These are two separate test suites with two separate failure modes, and treating them as one is a common gap.
What Should a Pre-Release Deep Linking Checklist Actually Include?
A checklist that only confirms "the link opens the app" is not sufficient, because that test passes even when the link routes to the wrong screen, drops query parameters, or works only on Wi-Fi. A better checklist separates concerns explicitly:
File validation: confirm the AASA and assetlinks.json files return valid JSON, are served with the correct content-type header, and are reachable without redirects
Certificate matching: verify the SHA256 fingerprint in assetlinks.json matches the actual release signing key, not a debug key
Cold start test: force-quit the app and test link opening, not just background-resume
Deferred install test: uninstall the app, click the link, install fresh, confirm correct landing screen
Cache-busting check: after any change to the association file, confirm Apple's CDN has picked up the update before re-testing (caching delays are a documented, common source of false negatives during QA)
Fallback behavior: confirm what happens when the app is not installed at all (should route to app store, not a broken page)
Cross-platform parity: test the identical link on both platforms rather than assuming iOS behavior generalizes to Android or vice versa
This is the difference between a mobile engineering team running a script and a team that understands why each step exists. For enterprise mobile app development in regulated sectors like fintech, where a broken deep link can interrupt an in-progress payment or trading confirmation, this checklist runs on every release, not just the initial launch.
How Does This Connect to Choosing a Development Partner?
The deep linking failures above are specific enough that they get caught reliably only by a team that has shipped and maintained mobile apps in production, not just built them once and handed them off. 724SOFTWARE's mobile delivery work, including custom mobile app development for a live mobile banking app with embedded stock trading and a derivatives platform running iOS, Android, Web, and Desktop from one team, is grounded in ongoing production support rather than one-off engagement cycles: a broken deep link in a trading app is a support ticket and a compliance question, not just a marketing metric.
For companies evaluating mobile app development across different regions, the practical question isn't whether a Vietnam IT team can write the code. It's whether that team's release process catches integration failures like association-file mismatches, cold-start routing bugs, and deferred-link failures before they reach production, working across the timezone overlap needed to fix them fast when they don't.
Frequently Asked Questions
Do Universal Links and App Links require the same association file?
No. iOS uses apple-app-site-association, a JSON object with no file extension. Android uses assetlinks.json, a JSON array. They use different verification protocols and cannot share a single file.
Can a deep link work on iOS but fail on Android with the same URL?
Yes, because verification is platform-specific. A correctly configured AASA file has no bearing on whether assetlinks.json is also correct.
Why does a deep link work in the browser but not after installing the app?
This usually indicates a deferred deep linking failure, a separate mechanism from direct link handling that depends on matching the pre-install click to the first app open.
Is HTTPS mandatory for both AASA and assetlinks.json?
Yes. Both files must be hosted over HTTPS with a valid, non-expired certificate; auto-verification is restricted to http and https schemes on both platforms.
How often should the association files be re-tested?
After any change to the app's signing certificate, domain, bundle ID, or package name, and as part of every pre-release regression cycle, not just at initial launch.
Does a cold app start really behave differently from a warm start?
Yes. Cold starts require the app to reconstruct navigation state from the link itself, which is a documented common source of routing failures that don't appear in warm-start testing.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based technology partner delivering custom mobile app development, web application engineering, and dedicated engineering teams for companies in Australia, Singapore, the UK, the US, and Western Europe. The team has shipped and maintained mobile apps handling live trading, in-app banking transactions, and consumer traffic spikes exceeding 500,000 downloads, work that requires exactly the release discipline described above. Teams scale from 1 to 50+ pre-vetted engineers within 2 to 4 weeks, operate under a follow-the-sun model with under 10 minute incident response, and align delivery with ISO 27001:2022 standards.
For companies building or maintaining mobile applications that require production-grade deep linking and release discipline, connect with 724SOFTWARE at https://724software.com.vn.
