Home› Blog› Universal Links vs App Links: The Complete Developer Guide
App-Entwicklung

Universal Links vs App Links: The Complete Developer Guide

20. July 2026

If you have ever tapped a link on your phone and landed in the wrong place – a browser instead of an app, or worse, an error screen – you have experienced a broken deep link. For development teams and product managers, this is not just a minor inconvenience. It represents lost conversions, frustrated users, and unnecessary support tickets. Universal Links and App Links are the platform-native solutions Apple and Google provide to fix this problem, but they work quite differently from each other.

This guide explains exactly how Universal Links (iOS) and App Links (Android) differ, how to set each one up correctly, and what common mistakes to avoid – so your team can implement reliable, seamless navigation between web and app environments.

Universal Links is Apple's mechanism for associating a domain with an iOS or iPadOS app. When a user taps a standard HTTPS URL, iOS checks whether the domain has a registered association with an installed app. If it does, the app opens at the correct in-app screen. If the app is not installed, the browser opens the web page as a fallback – no custom URL scheme required.

App Links is Google's equivalent for Android. Introduced in Android 6.0 (Marshmallow), App Links verify that an HTTPS URL belongs to a specific Android app using a `Digital Asset Links` JSON file hosted on the target domain. Like Universal Links, verified App Links open directly in the app without triggering an disambiguation dialog.

Both systems replace the older, fragile approach of custom URI schemes (e.g., `myapp://path`) which offered no verification and no graceful fallback. According to the Android Developers documentation, App Links require proper hosting of a `assetlinks.json` file to pass automated verification – a step many teams overlook.

Understanding the structural differences between Universal Links and App Links prevents costly implementation mistakes. Here is a direct comparison:

Verification File and Location

Verification Timing

Supported OS Versions

Handling When App Is Not Installed

Getting Universal Links right requires attention at both the server and app level.

Step 1 – Create the AASA File

Your `apple-app-site-association` file must be valid JSON (no `.json` extension). A minimal example:

json
{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.yourcompany.yourapp",
        "paths": ["/products/*", "/checkout", "/account"]
      }
    ]
  }
}

For iOS 13+, use the newer `components` key instead of `paths` for more granular URL matching, including query parameter support.

Step 2 – Host the File Correctly

Step 3 – Enable Associated Domains in Xcode

In your Xcode project, navigate to Signing & Capabilities → Associated Domains and add entries in the format `applinks:yourdomain.com`. For multiple subdomains, add each one separately.

Step 4 – Handle the URL in AppDelegate / SceneDelegate

Implement `application(_:continue:restorationHandler:)` in your `AppDelegate` or `scene(_:continue:)` in your `SceneDelegate`. Parse the `NSUserActivity` with `activityType == NSUserActivityTypeBrowsingWeb` and route users to the correct screen.

Key tip: Always test on a physical device, not the simulator. The simulator does not properly replicate the Apple CDN fetch behavior.

Use the Android Studio App Links Assistant or generate the `assetlinks.json` file manually:

json
[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourcompany.yourapp",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:...YOUR_CERT_FINGERPRINT..."]
  }
}]

You need both your debug and release certificate fingerprints if you want to test before publishing. For Play Store apps, also include the Play App Signing fingerprint from the Google Play Console.

Step 2 – Host the File

Step 3 – Declare Intent Filters in AndroidManifest.xml

xml
<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="https"
        android:host="yourdomain.com"
        android:pathPrefix="/products" />
</intent-filter>

The `android:autoVerify="true"` attribute triggers automatic verification on install.

Step 4 – Validate with the Statement List Generator

Use Google's Digital Asset Links API to confirm your file is reachable and correctly parsed.

Even experienced teams make these errors. Avoid them to save hours of debugging:

1. Redirects on the verification file – Any HTTP redirect (including HTTP→HTTPS) causes verification to fail silently on both platforms.

2. Wrong certificate fingerprint – Using only the debug fingerprint in production, or forgetting the Play App Signing fingerprint, breaks verification for Play Store builds.

3. Missing subdomains – If your app handles links from `shop.yourdomain.com` and `m.yourdomain.com`, each subdomain needs its own AASA or `assetlinks.json` entry (or a wildcard domain configuration for iOS 13+).

4. Stale AASA cache on iOS – Apple's CDN caches AASA files aggressively. After updating the file, it may take 24–48 hours to propagate to installed devices. Plan version rollouts accordingly.

5. Not handling the fallback web page – If the app is not installed, users land on your website. Make sure those landing pages are functional, mobile-optimized, and offer an app download prompt (Smart App Banner for iOS, Play Store redirect for Android).

6. Testing only in development – App link verification depends on signed builds. Always validate with a release-signed APK or IPA before shipping.

Validation and Testing Tools

Reliable testing is non-negotiable for Universal Links and App Links. Use these tools:

For a detailed testing workflow, our blog covers additional mobile QA strategies for SMB development teams.

Most consumer-facing apps need both Universal Links and App Links – one for each platform. The two systems are parallel implementations that serve the same user experience goal but operate independently.

A practical rule of thumb:

Important: Both systems support HTTPS only. If any part of your infrastructure still serves HTTP, fix that first – not just for deep linking, but for security and SEO reasons.

For decision-makers, the business case for investing in proper Universal Links and App Links implementation is straightforward:

If your development team has not yet verified that your Universal Links and App Links are fully functional across all paths, this is worth prioritizing in the next sprint. A broken link in a paid acquisition campaign or transactional email directly costs revenue.

Summary: What to Do Next

Implementing Universal Links and App Links correctly requires coordination between your backend team (file hosting), mobile developers (manifest / entitlement configuration), and QA (device testing). The setup is not complex, but the details matter – a single misconfigured redirect or missing certificate fingerprint will cause silent failures that are difficult to diagnose without the right tools.

To recap the essential checklist:

If you want expert support setting up Universal Links and App Links for your iOS and Android apps – or if you need a full audit of your existing deep link infrastructure – our team at Pilecode is ready to help.

Schedule a free initial consultation →

Have questions about this topic? Get in Touch.