Why links should open your app, not Safari or Chrome
When a customer has your app installed on their phone and clicks a link from your newsletter, an SMS notification, or an Instagram post, opening Safari or Chrome is a jarring drop-off. They are forced to log in again on the browser or navigate back to find what they were looking for.
Deep linking solves this by making your native app the default handler for your domain URLs. When configured correctly, clicking https://yourstore.com/product/winter-jacket opens the winter jacket page directly inside your installed iOS or Android app, logged in and ready for checkout.
The two standards: Universal Links vs Android App Links
Both Apple and Google abandoned legacy custom URL schemes (like myapp://product) years ago because any rogue app could register the same scheme and hijack traffic. Today, both platforms require cryptographic domain verification:
1. iOS Universal Links: Standard HTTPS URLs that Apple verifies by checking a digitally hosted JSON file on your domain. If the app is installed, iOS intercepts the URL and hands it directly to your app without bouncing through Safari. If the app is not installed, the link opens in Safari like a regular webpage.
2. Android App Links: Google equivalent under the Digital Asset Links specification. Android verifies that your app package and certificate fingerprint match the manifest hosted on your domain. Once verified, the Android OS opens the link in your app immediately without showing an 'Open with...' disambiguation dialog.
The server-side requirement: Hosting the verification files
This is the part that stays entirely on you: your website must host two public JSON files over valid HTTPS, with no redirects, no query strings, and standard MIME types:
For Apple, host an apple-app-site-association file at https://yourdomain.com/.well-known/apple-app-site-association (or at the root). It lists your Apple Team ID, Bundle ID, and the allowed path patterns (e.g., ['/products/*', '/cart', '/account']).
For Android, host an assetlinks.json file at https://yourdomain.com/.well-known/assetlinks.json. It specifies your Android package name and the SHA-256 fingerprint of your app signing key.
Neither file requires paying a third-party deep linking service like Branch or AppsFlyer if you just want your website URLs to open your app. You only need standard static file hosting on your existing web server.
The app-side requirement: Intent filters and Associated Domains
Inside the native shell, your app must declare its intent to handle your domain. On Android, this means adding an <intent-filter> with android:autoVerify='true' inside AndroidManifest.xml. On iOS, it requires enabling the 'Associated Domains' entitlement in Xcode or your build configuration with applinks:yourdomain.com.
When using an automated web-to-app generator, this native configuration should be generated automatically during the build process based on your domain. What the generator cannot do is upload the verification files to your web server—that remains your task.
How Tapbound handles deep linking
Tapbound builds Universal Links and Android App Links into your native shell out of the box. When you enter your domain, Tapbound configures the Android intent filters with autoVerify enabled and adds the Associated Domains entitlement to your iOS project profile.
From your dashboard, Tapbound provides the exact assetlinks.json and apple-app-site-association snippets pre-populated with your app bundle ID, Team ID, and signing fingerprints. You simply upload those two files to your website's .well-known folder. When someone taps a link to your site, your app opens directly to that page.
Common pitfalls and how to test deep links
Testing deep links requires real devices because desktop browsers and basic web emulators do not simulate mobile OS intent routing.
Pitfall 1: Redirects on the .well-known URLs. If your web server redirects http to https or adds a trailing slash to /.well-known/apple-app-site-association, Apple validation bot will fail silently and Universal Links will not activate.
Pitfall 2: Testing by pasting into Safari address bar. Apple deliberately disables Universal Links if you paste or type the URL directly into Safari search bar on iOS, assuming the user specifically intended to browse the web. Always test by tapping a link inside the Notes app, Mail, or an SMS message.
Pitfall 3: Mismatched SHA-256 key fingerprints on Android. If you upload an .aab to Google Play and Google manages your app signing key, you must use the App Signing certificate fingerprint from Google Play Console, not your local upload key fingerprint.