How to Handle Deep Links in Android and iOS Apps

To handle deep links on Android and iOS, give each destination a stable HTTPS URL, associate your domain with the installed application, and route the incoming URL to the correct screen. Android App Links use Digital Asset Links and matching app declarations; iOS Universal Links use an Apple App Site Association file and the associated domains entitlement. The URL must also work as a normal website address when the app is absent. Treat authentication, expired content, and redirects as part of the link design, not as cleanup after the app has shipped.

Design destination URLs before configuring mobile platforms

Start with a small route inventory: product pages, booking details, invitations, and account actions. Record whether each route is public or requires authentication. Prefer durable paths such as /orders/123 over addresses tied to temporary interface state. A copied link should remain meaningful after a website redesign or a new app release.

Distinguish ordinary deep linking from deferred deep linking. Opening a destination in an already installed app does not automatically preserve that destination through a store installation. That is a separate requirement with additional implementation and privacy considerations. Custom URL schemes can also open apps, but they do not provide the same verified website association as HTTPS app links.

Configure verified links in five stages

1. Make the website destination work on its own

Paste each URL into a fresh browser session. Confirm that server routing supports direct loads, not just navigation from the homepage. Provide a useful page if the app is not installed. If a resource has been removed, show an explanatory state rather than an endless redirect. Do not require an app installation just to explain what the link refers to.

2. Associate the Android app with the domain

Configure matching HTTPS intent filters and domain verification in the Android application. Publish the domain association at /.well-known/assetlinks.json with the correct package name and SHA-256 signing certificate fingerprint. Follow the Android App Links documentation. When Google Play signs distributed builds, use the applicable app signing certificate rather than assuming the upload certificate identifies the installed release.

3. Add the iOS website association and entitlement

Configure associated domains in the signed iOS app and serve an apple-app-site-association file for the relevant website. Its app identifiers and path rules must match the intended app and routes. Serve valid JSON over HTTPS without redirects. Apple describes the relationship in supporting associated domains. Merely uploading the file does not add the required capability to an existing IPA.

4. Preserve the destination across authentication

If a user opens a private order while signed out, keep an approved local destination through login and return there afterward. Validate return destinations to prevent open redirects. Enforce authorization on the server: possession of a link must not grant access to another customer’s data. For password resets and invitations, handle expired or already-used tokens explicitly and avoid recording sensitive tokens in analytics.

5. Test the installed app and browser fallback

Test links from messaging, email, and another website, with the app installed and uninstalled. Cover cold launches and an already running app. Browser navigation context and user preferences can affect whether an app opens, so a successful address-bar test alone proves little. Use the Android verification testing guide to distinguish routing bugs from failed domain verification.

Why verified links can still open the wrong screen

Domain verification and in-app routing solve different problems. The operating system may open the right application while its shell discards the incoming path and displays the homepage. Confirm that the chosen packaging implementation forwards supported URLs correctly. Also check redirects between apex and www domains, subdomains missing from configuration, and overly broad path matching that captures unrelated website pages.

A frequent release-only failure is a signing mismatch: local builds verify against one certificate while store-distributed builds use another. Another is a login flow that returns to a default dashboard instead of the intended destination. Keep these cases in the release test plan. For Android identity details, see configuring app signing for Google Play.

Deep-link acceptance checklist

• Every supported destination loads directly on the website.
• Domain files are public, valid, and match the release app identity.
• The signed application contains the required platform configuration.
• Signed-out users return to the correct authorized destination after login.
• Expired, missing, and unauthorized resources have clear outcomes.
• Tests cover installed, uninstalled, cold-launch, and running-app states.
• External destinations stay outside the app when that is the intended behavior.

PwatoApp builds still need route-level verification

PwatoApp creates Android APK/AAB and iOS IPA builds from an existing web app. The €49.99 one-time price includes unlimited builds for both platforms and release signing. Check the current requirements for your selected build type before relying on App Links or Universal Links; a signed build alone does not establish domain association. Test the final artifact, and do not assume packaging guarantees store approval or converts web routes into native screens.