What Is a Deep Link? How to Make Links Open Inside Your App

A deep link is a link that takes people straight to a specific screen inside your app instead of the home screen. In this guide, Talha Aslan and team walk through the setup we use in real projects: deep link types, iOS Universal Links versus Android App Links, verification files, what happens when the app is not installed, campaign use, and the most common mistakes.

Put simply, the word "deep" describes how far the link travels. It does not stop at the front door of the app; it walks the user into a specific room. In other words, it is the app version of linking to a product page instead of a homepage.

In practice, this kind of link solves three problems. First, it gets users to what they want in one tap. Second, it moves campaign, notification, and email traffic into the app. Finally, it gives you a clean way to measure which links actually drive in app results.

What do users lose when there is no deep link?

For example, here is the scenario we see most often. A user taps a product in a sale email. The app opens, but it lands on the home screen. Now the user has to search, browse categories, or give up. In practice, many simply give up.

On the other hand, if the link opens in a browser instead of the app, the user hits a logged out web page. The cart, saved items, and stored address are not there. As a result, the experience you invested in disappears at the most important moment.

Consider an example scenario with an online store app. The campaign email reaches thousands of people and the click rate looks healthy. Still, in app sales stay below target. The problem is often not the creative; it is the first screen after the click. That is why link routing is a shared job for marketing and product teams.

What types of deep links are there?

Specifically, you will run into four concepts in the field. People often use the same name for all of them, but they behave differently:

• Custom URL scheme: a link that starts with a prefix unique to your app. It only works when the app is installed.
• Universal Links: on Apple platforms, normal HTTPS links on your own domain that open in your app.
• Android App Links: HTTPS links on Android that rely on a verified association between your domain and your app.
• Deferred deep link: a flow that sends a user without the app to the store first, then to the right screen after install.

In short, the first three describe how a link opens. The last one describes how information survives the install when the app is not there yet. Also, most projects use more than one of these together.

Why is a custom URL scheme not enough on its own?

A custom URL scheme is the oldest and easiest method. You register a prefix for your app, and any link with that prefix opens it. However, the method has three weak points.

First, there is no proof of ownership. According to Apple's documentation on custom URL schemes, if multiple apps register the same scheme, the app the system targets is undefined. In other words, another app can claim your scheme. Google Ads Help makes the same point: with Universal Links and App Links, other companies cannot claim your link.

Second, if the app is not installed, the link goes nowhere and the user sees an error. Third, some email and social apps do not render these links as tappable. So while Apple calls custom schemes an acceptable form of deep linking, it strongly recommends Universal Links instead. We keep custom schemes only for internal routing or as a fallback.

What are Universal Links and how do they work on iOS?

Universal Links are an Apple feature that opens standard HTTPS links on your domain directly in your app on iPhone and iPad. According to Apple's guide to linking apps and websites, one URL works for both your website and your app.

In practice, the flow is simple. When someone installs your app, the system checks a file on your web server. That file confirms your website allows your app to open URLs on its behalf. Because only you can place this file on your server, the association is secure. After that, a tap on a matching link skips the browser and opens the app.

There are two jobs on the app side. First, you add the Associated Domains capability to the target in Xcode and list your domain there. Then you make the app read the incoming URL and route it to the right screen. If the app is not installed, the system opens the same URL in the default browser, and your website takes over.

What are Android App Links and how do they differ from a regular deep link?

On Android, a regular deep link uses the intent system to route links into your app, and Android's documentation says it works on all Android versions. However, an unverified link can trigger a disambiguation dialog that asks the user which app should open it.

Android App Links, by contrast, are the verified version. Specifically, you create a trusted association between your website and your app. Once verification succeeds, links to your site open directly in the app with no chooser. According to the documentation, App Links work on Android 6 and later, on devices that have Google services.

On the app side, you add the autoVerify attribute to the intent filter that handles the link. Then, at install time, the system requests the verification file for every host in your manifest. That means half the Android work lives in the app and half lives on the web server. If your web team and app team are not on the same schedule, setup usually stalls right here.

How do Universal Links and App Links compare?

Both systems rest on the same idea: a verification file on your server that ties your domain to your app. Still, the details differ. This table summarizes the key differences based on official documentation:

The takeaway is clear. In a new project, Universal Links and App Links are your primary path, and a custom scheme stays as an optional fallback.

What is the apple-app-site-association file and where does it go?

The apple-app-site-association file is the iOS verification file. According to Apple's documentation on associated domains, it has no file extension, contains JSON, and lives in your site's .well-known directory. It lists your app identifier and the URL patterns the app should open.

The documentation stresses these rules:

• Host the file over HTTPS with a valid certificate.
• Serve it with no redirects. A URL that returns a 301 or 302 breaks verification.
• If you use several subdomains, each one serves its own file and gets its own entry in the app.
• In the app's domain list, leave out paths, query strings, and trailing slashes.

Above all, one more detail matters. Apple says that starting with iOS 14 and macOS 11, devices request the file from an Apple managed content delivery network instead of your server. Apple also notes that this network fetches the file within 24 hours, and that devices check for updates roughly once a week after install. So a change to the file does not show up instantly.

What is assetlinks.json and how does verification work?

The assetlinks.json file is the Digital Asset Links verification file for Android. Android's guide to website associations says it lives in the .well-known directory of your domain. It must load over HTTPS with the application/json content type, and redirects are not allowed.

The file holds two critical values: your app's package name and the SHA256 fingerprint of your signing certificate. The most common mistake here is pasting the fingerprint of the developer's local key. According to the guide, if you use Play App Signing, the fingerprint you generate locally will usually not match the one on users' devices. You will find the correct value, and a ready snippet, on the app signing page in Play Console.

Also, if your app handles several domains, you publish the file on each one. On Android 11 and lower, the system makes your app the default handler only if every host in the manifest verifies. Consequently, a single forgotten subdomain can push every link back to the chooser dialog.

What does a deep link do if the app is not installed?

Put simply, it depends on the type. Universal Links and App Links are standard web URLs, so without the app they open in the browser. Google Ads Help describes the same outcome: instead of an error page, users go to the landing page on your mobile site.

That means every URL you route into the app needs a working web version. If the app has a product screen but the same URL returns a 404 on the site, everyone without the app sees an empty page. We see this most in projects that invent a separate URL structure just for the app.

A custom scheme, however, has no fallback at all. Without the app, the link does nothing or shows an error. On the other hand, if you want to send people to the store and then land them on the right screen after install, a normal link is not enough. You need a post install routing setup. If you are still choosing between web and native, our mobile app or PWA comparison covers that decision.

What is a deferred deep link?

A deferred deep link sends a user without the app to the store, lets them install it, and then opens the linked content on first launch instead of the home screen. Google Ads Help describes the goal as getting new app users to a specific in app page right after they install.

Still, the hard part is this: the store install does not pass the link information to the app by itself. Instead, you need a way to keep that information across the install. On Android, the Google Play Install Referrer API can return the referrer URL of the installed package. That lets you read campaign details on first launch.

For ads, Google Ads requires two things for this in App campaigns for installs: the Google Analytics for Firebase SDK in your app, and an allowlist for your links. Here is an example scenario. A loyalty program invite link takes a first time user to a signup screen with the invite code already filled in. As a result, the user never retypes the code.

What should you use now that Firebase Dynamic Links has shut down?

For years, Firebase Dynamic Links was one of the most popular ready made tools for post install routing. However, the Firebase Dynamic Links FAQ states that the service is deprecated and shut down, and that links served by it no longer work.

If old campaigns, QR codes, or email templates still use those short links, replace them with links on your own domain. Otherwise, a QR code on an old flyer or package sends people to an error page.

The FAQ recommends App Links and Universal Links for apps that only need linking after install. For deferred linking, it points to third party link providers rather than a Google alternative. So you have two paths. You can build simple post install matching on top of Universal Links and App Links on your own domain. Alternatively, you can use a third party measurement and linking provider. The right choice depends on budget, privacy needs, and campaign volume.

How should you use deep links in email and SMS campaigns?

Email is one of the channels where in app linking pays off most. People usually read on their phone, and the app is often already installed. However, there is a subtle trap: email platforms wrap links in their own tracking URLs to count clicks.

That wrapping can break Universal Links and App Links. The URL the user taps no longer belongs to your domain; it belongs to the email platform. The system opens the browser first and may not hand off to the app after the redirect. So run these checks:

1. Ask whether your email platform can move its tracking domain to a subdomain you own.
2. If it can, publish the verification files on that subdomain too.
3. For critical campaigns, consider turning off click tracking and measuring with in app events instead.
4. Before sending, test the link from inside the email app on both iOS and Android.

SMS, however, is simpler. A short HTTPS URL on your own domain usually works fine. For the rest of the email build, see our HTML email newsletter guide.

How do deep links work in Google Ads and social ads?

According to the Google Ads Help page on getting started with deep links, you can use them in App campaigns for engagement, App dynamic remarketing, and Search, Shopping, and Display campaigns. The same page notes that this setup is not automatic and requires code changes from the app team.

Google Ads also offers a deep link validator that helps find configuration issues. We recommend running your iOS and Android links through it before you launch. That way, you do not discover a setup error after the budget starts spending.

Social apps, on the other hand, are less predictable. Some open links in their own in app browser, and that browser does not always trigger Universal Links. As a result, a user from an ad may land on your web page first. In that case, a clear "open in app" button on the page is a practical way to reduce drop off.

Does it make sense to use a deep link in a QR code?

Yes, because it is one of the best use cases. Someone scanning a QR code is already on a phone and usually wants a product, menu, or offer fast. If the code contains a Universal Links and App Links URL on your domain, app users go straight to the screen. Everyone else gets the same content on the web.

Specifically, we have two recommendations here. First, never put a custom scheme in a QR code, because everyone without the app gets an error. Second, design the printed URL so it never has to change. You cannot update packaging or table cards without reprinting.

When you create the code, add campaign parameters and print a test with our QR code generator. If the code will not scan, the issue is usually print size or contrast, not the link; our QR code not scanning guide covers the fixes.

How do you measure deep link traffic?

Once setup is done, the real question is how much these links actually deliver inside the app. To answer it, you add source, medium, and campaign details to the link. Then the app reads them on open and writes them into an analytics event.

In practice, UTM parameters are the most common method. Universal Links and App Links are standard web URLs, so they carry query parameters, and the app can read them on open. To build parameters consistently, use our UTM builder, and for naming rules, read our guide to UTM parameters.

In the app, you log each link driven open as its own event, along with the target screen and campaign details. We explain which events to track and how to name them in our post on which events to track in a mobile app.

How do you set up deep links step by step?

The sequence below is the simplified flow we follow in projects. The code differs by platform, but the steps stay the same:

1. List which app screens should open from a link: product, category, order, campaign, profile.
2. Define a readable URL structure for each screen that also exists on your website.
3. Prepare the apple-app-site-association file for iOS and the assetlinks.json file for Android.
4. Place both files in the .well-known directory of each domain, over HTTPS, with no redirects.
5. Add the Associated Domains capability to the iOS app and an intent filter with autoVerify to the Android app.
6. Write a single routing layer in the app that parses incoming URLs and opens the right screen.
7. Send unknown or malformed URLs to a sensible fallback screen.
8. Read campaign parameters and pass them to analytics.
9. Test on real devices, including from inside email and messaging apps.

Most of these steps touch the app architecture. When we build your app, we design the link structure from day one and handle the store release too; see our mobile app development service for details.

What are the most common reasons a deep link does not work?

In practice, most problems we see in the field fit a few patterns:

• The verification file redirects: if the bare domain redirects to www, or HTTP redirects to HTTPS at that path, verification fails.
• Wrong fingerprint: assetlinks.json holds the developer's local key instead of the signing certificate from Play Console.
• Missing subdomain: the subdomain used for campaigns or email tracking is not covered.
• Same domain taps: Apple says that when a user browses your site in Safari and taps a link on the same domain, the system keeps it in Safari. So the app not opening may be expected behavior, not a bug.
• Cache delay: you fixed the file, but the device still uses the old copy.
• Another app holds the domain: Android's documentation says only one app at a time can be associated with a given domain on a device.
• No web version: the URL returns a 404 when the app is not installed.

To spot broken URLs across your site, you can also use our broken link checker. That way, you confirm that every web address you send into the app actually loads.

What should you watch for in deep link security?

An app link is a door into your app from the outside. Apple's Universal Links documentation calls these links a potential attack vector. It advises you to validate all URL parameters and discard malformed URLs.

In practice, we follow a few rules. First, a link never performs a critical action on its own. It does not delete content, confirm a payment, or display sensitive data. For those actions, the user confirms inside the app. Also, if a link points to a screen that needs a session and the user is logged out, the app shows the login screen first and then the target.

On the other hand, password reset and one time login links need expiry and single use rules on the server. The app only carries the link; the server decides access. That way, a link that reaches the wrong person does limited harm. Finally, add malformed URLs to your test cases.

How should you test deep links before launch?

However, testing is not one tap on one device. Where the link opens, the state of the app, and the OS version all change the result. Here is the checklist we use before launch:

• Try the link with the app closed, in the background, and not installed.
• Tap it from inside notes, messaging, email, and social apps.
• Open the same link while logged in and logged out.
• On Android, check verification state with developer tools. Android's documentation suggests waiting briefly after install for verification to complete.
• If you plan to run Google Ads, run the links through the deep link validator.
• Try malformed URLs and URLs with missing parameters.

On iOS, you can share a prerelease build with real testers and check the link flow using our TestFlight guide. This matters because the association gets its real test with a signed build.

Why do deep links matter in push notifications?

In fact, push notifications are the most natural use case for in app linking; that is because users expect a direct path. A person who taps a shipping notification wants the order details, not the home screen. When the notification and the screen do not match, users decide notifications are noise and turn them off.

So you build notifications and links on one shared URL dictionary. For example, the product screen uses the same URL pattern in email, QR codes, and notifications. Then a single routing layer in the app sends users from every channel to the right place.

When to ask for notification permission is a separate decision, which we cover in when to ask for push notification permission. On the linking side, the rule is simple: every notification opens the screen that matches its message.

When should you plan your deep link structure?

The best time is at the start of the project, while you plan the app screens and the website URL structure together. You can also add it later, but bolting a routing layer onto existing screens means more testing and more bugs.

Take an example scenario with a booking app. At launch, it has a home screen and a booking flow. Six months later come email reminders, promo codes, and printed flyers with QR codes. If nobody planned the URL structure, every new channel needs its own exception, and maintenance gets harder.

Also, if you redesign your website or change your domain, add the verification files and URL mappings to the migration plan. Otherwise, on launch day, every link to the app starts opening in the browser instead.

Who should set up deep linking for your app?

Above all, this is never one team's job. The web server, the iOS app, the Android app, store signing settings, and marketing measurement all have to be right at the same time. When those pieces sit with different vendors, the problem usually shows up in the gaps between them.

As Talha Aslan and team, we handle link structure, verification files, campaign measurement, and store release together while we build the app. We develop your app and take it to the stores. If your existing app has linking problems, we review the setup and give you a clear plan. To get a quote for your project, use the form on our mobile app development page.

In short, a well built deep link takes users to the right screen in one tap, while a broken one quietly burns your campaign budget. The difference usually comes down to a few files and a handful of routing rules.