Deep link vs universal link and app link: differences and setup without losing clicks

A deep link is a link to a specific screen in an app that shortens the path from a click to the intended action. It is used to send traffic from ads and links in bios directly to a product, offer, or registration form. In real campaigns, consider domain verification, OS cache, social media in-app browsers, and how different accounts see the same URL.

The main difference between deep link vs universal link is simple: deep link is a general concept for links to a specific screen in an app. Universal Link implements this principle on iOS through a domain and the apple-app-site-association file, while App Link does so on Android through assetlinks.json. For a digital agency, this difference is not theoretical. It determines whether TikTok, a marketplace, or a client's product opens directly on the required screen.

When a link breaks, a marketer often sees only the symptom: the click happened, the app did not open, and conversion dropped. The technical cause may be in the AASA file, Digital Asset Links, manifest, user settings, a redirect, or the session of a specific account. That is why testing should be performed not only by the developer but also by the person who launches campaigns across different platforms.

Testing is also important for mobile marketing. If one manager checks ads for several brands in the same browser, cookies, authorization, geo, and previous navigation become mixed. This is especially problematic when testing mobile campaigns: the same URL may open a different screen for a new user, an authorized user, a test account, or an Apple Developer account with a different configuration.

What deep link, universal link, and app link are and what the key difference is

Deep link is a general term for a link that leads not just to an app but to a specific place inside it. Universal link and app link are verified web links for iOS and Android that associate a domain with a specific app.

A classic deep link often uses a custom URL scheme such as myapp://product/123. It can open an app quickly, but it has a weak point: if the app is not installed, the system does not always know where to send the user correctly. Universal Links and Android App Links work differently. These are regular HTTPS links with a fallback web route: if the app is missing or the domain is not verified, the user sees the web page.

The link https://example.com/product/123 can simultaneously be a website page, a Universal Link for iOS, and an App Link for Android. The OS checks the domain and either opens the product screen in the app or keeps the user in the browser.

How to set up Universal Links on iOS via apple-app-site-association

Universal Links on iOS work through two-way trust between the domain and the app. The website must have the apple-app-site-association file, and the app must have the Associated Domains entitlement with the domain in the applinks:example.com format.

The AASA file is placed at the root of the domain or at /.well-known/apple-app-site-association. The .json extension is not added. Production requires HTTPS, valid JSON, and a domain that matches the one specified in the app. If an ad campaign leads to go.example.com while the entitlement specifies only example.com, Universal Link will not work for that subdomain.

The basic setup sequence is:

1. prepare a list of domains and subdomains actually used in ads, email, and links in bios
2. create the apple-app-site-association file with Team ID, Bundle ID, and path rules
3. place the file in /.well-known/ or at the root of each domain without an extension
4. enable Associated Domains for the App ID in Apple Developer
5. add the Associated Domains capability in Xcode and the applinks:domain value
6. test opening on a physical iPhone after installing or updating the app

In the technical checklist, verify the HTTP status, absence of redirects, content type, JSON validity, exact app identifier, and list of paths. If a CDN or WAF returns an HTML error page to the Apple crawler instead of JSON, Universal Link will not work even when the file opens in your browser.

The diagram identifies the two domain association files and the app identifiers each platform checks.

How to set up App Links on Android via assetlinks.json

Android App Links work through Digital Asset Links. The domain publishes assetlinks.json, while the app declares an intent filter in the manifest with android:autoVerify="true" for HTTPS links.

The file must be available at https://domain/.well-known/assetlinks.json. Each host and subdomain needs its own accessible configuration. The JSON specifies the relation delegate_permission/common.handle_all_urls, the app package name, and the SHA-256 certificate fingerprint. If the campaign uses www.example.com and m.example.com, Android verifies them as different hosts.

The App Links setup sequence is:

1. add an intent filter for VIEW, BROWSABLE, DEFAULT, https, and the required host
2. enable android:autoVerify="true" in the filter that must pass verification
3. generate the SHA-256 fingerprint for the release certificate, not only the debug build
4. create assetlinks.json with the package name and certificate fingerprint
5. place the file at /.well-known/assetlinks.json on each host
6. install or update the app on the test device
7. check the status with adb shell pm get-app-links PACKAGE_NAME

A regular Android deep link can open the app, but the system may sometimes show an app chooser. After domain verification, App Link tells Android which app should handle the URL.

Why links in social media open in the browser instead of the app

A link opens in the browser when the OS cannot verify the association between the domain and the app or when a social media in-app browser intercepts the route. This is not a single error but several verification layers.

Start with the domain. Universal Links and App Links are tied specifically to the host. If an ad tracker adds a redirect through another domain while verification exists only on the final domain, some clicks will go through the browser.

The second verification layer concerns verification files. For iOS, check apple-app-site-association; for Android, check assetlinks.json. The errors are common: 404, 403 for the crawler, HTML instead of JSON, an incorrect certificate fingerprint, an outdated Bundle ID, a different package name, or a situation where the server or CDN returns an HTML page instead of the verification file, for example because of a cookie banner.

The third verification layer concerns the opening environment. Instagram, TikTok, Facebook, LinkedIn, and messengers often open URLs in their own in-app browsers. Behavior there may differ from Safari, Chrome, or system opening from Notes. This is especially noticeable for TikTok Business Center: the creative may lead to the same URL, but a test from the TikTok app and a test from a clean Chrome session can produce different results.

Check the user state separately. If the app is already installed but the user manually disabled "Open supported links" on Android, the system may route to the browser.

What to choose for iOS and Android: deep link, universal link, or app link

For modern mobile campaigns, the basic choice is Universal Links for iOS and App Links for Android. A custom scheme can remain as an auxiliary route, but not as the main infrastructure for paid traffic.

It is easier to keep the comparison in one table. It shows not only the platform but also what happens if the app is not installed or the domain does not pass verification.

How to diagnose a link problem yourself

Diagnostics should start with the basics: check whether the verification file is directly accessible, and only then analyze the SDK, attribution, and ad account. Most failures are visible even before code analysis.

For iOS, open https://domain/.well-known/apple-app-site-association and https://domain/apple-app-site-association. Check that the response does not contain HTML, redirects, or an access error. Then compare the Team ID, Bundle ID, and paths.

For Android, work through adb. Before testing, it is preferable to have a physical device or emulator with a release build or a build close to release installed.

1. open https://domain/.well-known/assetlinks.json in the browser
2. check package_name and sha256_cert_fingerprints
3. reset the app links state with adb shell pm set-app-links --package PACKAGE_NAME 0 all
4. run verification again with adb shell pm verify-app-links --re-verify PACKAGE_NAME
5. wait a few minutes for the verification agent to complete the requests
6. check the status with adb shell pm get-app-links PACKAGE_NAME
7. launch the test URL with adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://domain/path"

On Android 15 and newer versions, changes in assetlinks.json may not propagate immediately because of cache and background domain verification. Test the ad URL with UTM, click ID, and a short domain separately, because the "clean" final page does not always reproduce the actual click path.

The diagnostic view shows the verification steps used to isolate an Android App Links routing failure.

How to test links across multiple accounts and geos without mixing sessions

Testing deep links on one device or in one browser quickly mixes sessions. For SMM and growth teams, this is a problem because different accounts, countries, cookies, system language, and IP can change the route after the click.

A typical scenario: an agency manages three brands with different TikTok Ads or Meta Ads accounts. In one browser environment, cookies, previous logins, locale, and redirect cache quickly accumulate.

A practical approach is:

1. allocate a separate test profile for each brand, account, or geo
2. assign a stable IP to the profile through a residential proxy if you are testing regional behavior
3. keep separate cookies and logins for each platform
4. record the full click URL, final URL, and opening result
5. repeat the test in the system browser, the social media in-app browser, and on a device with a clean app state
6. separate testing of installation, first launch, and repeated opening for an authorized user

Afina is useful specifically at this stage: each test account or geo can operate in a separate isolated profile with separate cookies, browser fingerprint, and proxy settings. This helps avoid mixing sessions when the team checks links for several clients, ad accounts, or regions. To connect a browser profile with a real mobile test, the approach with separating the browser and phone is useful: the web part is tested in the browser, while system app opening is tested on the phone.

Afina does not replace AASA, assetlinks.json, or a mobile SDK. It covers another layer of the problem: environment cleanliness, session stability, and geo control during testing. As a result, the team has the URL, account, geo, test time, and a reproducible result.

Download