A campaign link opens your app, but it lands on the home screen. Another link reaches the right product page, yet fails for someone who has not installed the app. The usual diagnosis—“our deep links are broken”—hides several different routing problems. Understanding deep linking vs universal linking lets you choose the right mechanism for each user state instead of debugging one vague category.
Deep linking is the outcome: a link takes someone to specific content inside an app. Universal Links are Apple’s verified HTTPS method for producing that outcome on iOS. They are not competing technologies. A Universal Link is one type of deep link; Android App Links provide the equivalent verified approach on Android, while deferred deep links solve the separate problem of preserving a destination through installation.
Deep linking vs universal linking: the short answer
People often use “deep link” to mean a custom URI such as myapp://product/42. That is only one implementation. Google’s current guidance describes deep links as URIs that lead beyond an app’s home screen and identifies Universal Links on iOS and App Links on Android as the platform implementations used to connect web and app content (Google Search Central).
Here is the practical hierarchy:
- Deep linking is the broad capability: open a specific app destination.
- Custom URL schemes are app-only routes such as
myapp://product/42. - Universal Links are verified
https://deep links for iOS. - Android App Links are verified
https://deep links for Android. - Deferred deep links preserve the intended route when the user must install first.
That last distinction matters. A native Universal Link has a web fallback, but it does not automatically send a new user to the App Store and restore the product route after installation. Firebase’s migration guide explicitly separates the behavior supplied by Universal Links and App Links from store routing, deferred journeys, click analytics, and short links (Firebase).
What deep linking actually means
A deep link encodes an in-app destination. It might represent a product, playlist, invitation, order, or account screen. The app receives the route, validates its parameters, and navigates somewhere more useful than the default launch screen.
For example, both of these links can express the same destination:
shopapp://products/42
https://shop.example.com/products/42The first uses a custom scheme. The second can act as a normal web URL, an iOS Universal Link, and an Android App Link when the domain and apps are correctly associated.
Custom schemes are quick to register and remain useful for controlled app-to-app callbacks or compatibility paths. But they have no built-in domain ownership check. Another app can claim the same scheme, and a device without the target app has no normal website to open. Google Analytics therefore recommends verified App Links and Universal Links as the industry-standard approach and notes that custom schemes are less secure and can produce an error when the app is absent (Google Analytics Help).
So “deep link” should describe what the user experiences, not force a conclusion about URL format. When a requirement says only “add deep linking,” the team still needs to decide the platform mechanism, fallback, install behavior, and measurement layer.
What Universal Links change on iOS
A Universal Link is an ordinary HTTPS URL whose domain has a verified relationship with an iOS app. The same link can open app content when the app is installed and web content when it is not. Apple calls this a two-way association: the app declares an Associated Domains entitlement, and the website publishes an apple-app-site-association (AASA) file listing the app and paths it may handle (Apple Developer).
At a high level, iOS evaluates a tapped URL like this:
- Does an installed app have a verified association with this domain?
- Does the URL match a path allowed by the AASA rules?
- Does the tap context permit an app handoff?
- If all checks pass, send the URL to the app; otherwise, continue to the website.
The app must then map the URL to the right screen. Verification proves that the app may handle the domain; it does not implement navigation for you.
This model gives Universal Links two important advantages over custom schemes. First, domain verification makes link claiming harder to hijack. Second, the HTTPS URL remains useful when the app cannot open. Apple’s documentation says users without the app receive the same information in a browser, which means the corresponding web page must be a real fallback rather than a blank redirect endpoint (Apple Developer).
Universal Links also have intentional browser behavior that can look like failure. For example, Apple notes that when someone is browsing a site in Safari and taps a Universal Link to the same domain, iOS may keep the journey in Safari because that best reflects the user’s intent (Apple Developer). A production test plan must account for source context, not just the URL.
Deep linking vs universal linking: comparison table
This table compares the common custom-scheme interpretation of a “deep link” with an iOS Universal Link. Remember that Universal Links are still deep links in the broader sense.
| Decision factor | Custom-scheme deep link | iOS Universal Link |
|---|---|---|
| Example | myapp://products/42 | https://shop.example.com/products/42 |
| Ownership verification | None built into the scheme | App and website association via AASA and entitlement |
| App installed | Can open the app if the scheme is registered | Opens the app when the association, route, and tap context match |
| App not installed | Usually fails or has no useful handler | Opens the HTTPS web destination |
| Web fallback | Must be added separately | Inherent in the URL, if the web page exists |
| Cross-platform use | Each app can register a scheme, with platform-specific handling | iOS only; pair with Android App Links for Android |
| Survives installation | No | No, not by itself |
| Setup | App registration and route handler | HTTPS domain, AASA file, app entitlement, and route handler |
| Best fit | Controlled callbacks and compatibility fallback | Public web-to-app links on iOS |
The choice is therefore rarely “deep links or Universal Links.” For public links, start with verified HTTPS links. Keep custom schemes only where the calling environment or integration requires them, and add deferred routing when a first-install journey must retain context.
The missing Android half: App Links
Universal Links apply only to Apple platforms. A cross-platform link strategy also needs Android App Links. Android uses the same broad idea—verified HTTPS ownership—but the implementation differs: an intent filter declares matching URLs in the app, android:autoVerify="true" requests verification, and /.well-known/assetlinks.json associates the website with the app’s signing certificate.
Android’s official documentation says verified App Links can route straight to the app without a disambiguation dialog, while users without the app continue to the matching website (Android Developers). It also documents Dynamic App Links on Android 15 and later, which can refine server-side path rules without requiring a new app release, subject to the platform’s manifest and verification constraints.
One HTTPS URL can serve all three surfaces:
- iOS reads the AASA association and may open the iOS app.
- Android reads Digital Asset Links and may open the Android app.
- Other devices and uninstalled users receive the web page.
The route contract should stay consistent across them. If /products/42 means one item on the web but maps to a different app object, users and analytics will see a broken journey even when both operating systems report successful verification.
Choose the link by user state and campaign outcome
Begin with the user state, not the vocabulary. Four questions determine the design.
1. Is the app already installed?
For re-engagement from email, search, SMS, or a website, use Universal Links on iOS and App Links on Android. They combine direct app routing with an HTTPS fallback. The detailed iOS Universal Links guide covers AASA route rules and device behavior; use a custom scheme only when a trusted source must call the app directly and verified web links are unavailable.
2. Must the destination work on the web?
If yes, verified HTTPS links are the natural default. Make each web URL a useful representation of the same content. Google advises matching the app content to the corresponding web content because Search still indexes and ranks the web page, even when an installed app can open from the result (Google Search Central).
If there is no web equivalent—perhaps a device-only settings action—use a safe landing page or an explicit app-only flow. Do not pretend an app-only route has a meaningful automatic fallback.
3. Must the route survive a new install?
Then you need deferred deep linking in addition to Universal Links and App Links. A deferred system records the intended destination before the store handoff and restores it on first open. Google Ads defines deferred deep linking as sending a new user to a specific in-app page after installation, which is a different lifecycle from opening an already-installed app (Google Ads Help).
This is where a managed platform can earn its place. Deeplinkly combines iOS and Android routing, deferred destinations, branded domains, and campaign attribution so the team can operate one link journey instead of stitching together native verification, store fallbacks, and first-open context. Use that layer when the requirement extends beyond native installed-app routing; native Universal Links alone remain appropriate for a simple iOS web-to-app handoff.
4. Do you need click and install attribution?
Native verification answers “may this app open this URL?” It does not automatically produce a campaign data model. Decide which parameters the app accepts, how redirects affect link recognition, how consent is handled, and how clicks, installs, opens, and conversions join together.
Email adds a specific trap: click-tracking systems often wrap the destination in a different domain. Customer.io’s documentation warns that universal and app links may require special tracking configuration because a wrapper can change which URL the operating system evaluates (Customer.io). Test the delivered message, not just the unwrapped URL copied from your dashboard.
A production implementation pattern
A robust setup can share one destination contract without forcing both platforms into identical configuration.
- Define canonical HTTPS routes. List supported paths, required IDs, optional campaign parameters, authentication behavior, and the web fallback for each route.
- Configure iOS Universal Links. Publish a valid AASA file over HTTPS, add the Associated Domains entitlement, and handle the incoming web activity in the app.
- Configure Android App Links. Add narrow intent filters, request verification, publish
assetlinks.jsonwith every production signing certificate, and handle the intent data. - Build one defensive app router. Parse URLs with platform libraries, allowlist hosts and actions, validate identifiers, and send unknown or unauthorized routes to a safe screen.
- Add deferred routing only where required. Preserve the canonical route and allowed context through install; define an expiry and a safe default when matching fails.
- Instrument outcomes. Record the original route, resolved destination, fallback reason, and campaign identifiers without treating raw URL input as trusted data.
Avoid broad wildcard rules until the smaller route set works. A narrow association is easier to review, less likely to open unintended web pages in the app, and simpler to test after domain or navigation changes.
How to test deep linking vs universal linking
Do not certify a link because it worked once on a simulator. Test production-like builds, real domains, release signing, and the actual channel where the link will appear.
| Scenario | Expected result | What a failure usually isolates |
|---|---|---|
| iOS, app installed, external tap | Exact in-app screen | AASA, entitlement, path match, tap context, or app router |
| iOS, app absent | Matching web page | Web route or fallback content |
| Android, app installed | Exact screen without chooser for verified links | Intent filter, assetlinks.json, certificate, or route handler |
| Android, app absent | Matching web page | Web route or redirect chain |
| Either platform, install required | Store, then intended screen on first open | Deferred-link service, install match, or first-open handling |
| Email or paid campaign | Same routing plus expected measurement | Tracking wrapper, redirects, stripped parameters, or attribution setup |
| Invalid or unauthorized destination | Safe fallback, never a privileged action | Input validation and navigation policy |
Use platform diagnostics rather than guessing, and run questionable URLs through a deep link debugger before widening association rules. Apple publishes a dedicated Universal Links debugging workflow covering the AASA file and device-side behavior (Apple TN3155). Android provides verification commands and recommends resetting link state before re-running domain verification on a test device (Android Developers).
Common reasons a verified link still opens the browser
When Universal Links or App Links fall back to the web, inspect the complete decision path:
- Association file problems: wrong location, invalid JSON, redirects, incorrect content delivery, or a mismatch between the website record and app identifier.
- Signing differences: Android’s debug, Play App Signing, and locally signed builds may use different certificate fingerprints.
- Overbroad or missing paths: the domain can verify while a particular route remains outside the allowed rules.
- User or browser context: same-domain navigation, a pasted URL, user preference, and in-app webviews can behave differently from an external user tap.
- Tracking wrappers: the first domain in the click chain may not be associated with the app.
- Router failure: the operating system opens the app successfully, but parsing, authentication, or stale content sends the user home.
- Caching: association updates are not necessarily visible immediately. Apple notes that its content delivery network fetches associated-domain files and devices check for updates on their own schedule (Apple Developer).
Log verification, handoff, route resolution, and final navigation as separate events. That turns “the link failed” into an actionable stage: OS association, channel delivery, fallback, deferred match, or in-app routing.
Frequently asked questions
Are Universal Links the same as deep links?
Universal Links are a type of deep link. Deep linking describes navigation to specific app content; Universal Links are Apple’s verified HTTPS implementation for that behavior on iOS.
Do Universal Links work when the app is not installed?
The URL still works, but it opens the corresponding website. A native Universal Link does not automatically send the user to the App Store and then restore the same destination after installation; that requires a store-routing and deferred deep-link flow.
What is the Android equivalent of a Universal Link?
Android App Links are the equivalent. They use HTTPS URLs, intent filters, and a Digital Asset Links file to verify that the app is allowed to handle the website’s links.
Are Universal Links more secure than custom URL schemes?
Yes, for proving who may handle a web domain. Universal Links require an app–website association, while custom schemes do not have the same ownership verification. The app must still validate every route and parameter before performing sensitive actions.
Can one URL open both an iOS and Android app?
Yes. The same HTTPS URL can be configured as an iOS Universal Link and an Android App Link, with the website as the fallback. The two platforms still require their own association files and app configuration.
Do Universal Links include deferred deep linking?
No. Universal Links open an installed iOS app or fall back to the web. Preserving the intended destination across an App Store installation requires an additional deferred deep-link mechanism.
Conclusion: use verified links first, then add the missing layers
The deep linking vs universal linking decision is simpler once the terms are separated. Use Universal Links for verified HTTPS routing on iOS, pair them with Android App Links for cross-platform coverage, and keep custom schemes for limited compatibility cases—not as the public-link default.
Then evaluate the journey your campaign actually promises. If users must reach the same content after installation or you need cross-channel attribution, add a deferred routing and measurement layer. Map the four user states—iOS installed, iOS absent, Android installed, Android absent—plus first open before you ship the link.