What Is Deep Linking? A Plain-English Explanation

Deep linking is the practice of using a link that opens a specific screen inside a mobile app, instead of the app's home screen or a web page. A deep link (often written as one word, "deeplink") is the link itself: a URL that carries enough information for the phone to open the right app and for the app to show the right content.

Here is the difference in practice, using a made-up recipe app:

The last two rows are deep links.

What is deep linking, and what does "deeplink" mean?

On the web, every page has its own address. Apps did not start out that way: tapping an app icon opens the front door, and the user finds their own way from there. Deep linking gives screens inside an app their own addresses. "Deep" refers to the destination, content past the home screen. Deep link and deeplink both mean the link, and deep linking is the technique.

A deep link has two jobs:

1. Get the phone to open the right app. The operating system has to recognise that this URL belongs to your app and not to the browser.
2. Tell the app where to go. The path and parameters in the URL (for example /recipes/lemon-tart or ?code=SPRING) tell your app which screen to show and what data to load.

iOS and Android handle the first job. The second is always your own code: the app receives the URL, reads it, and navigates.

How do deep links work on iOS?

iOS gives you two ways to make a link open your app: custom URL schemes and Universal Links.

Custom URL schemes

A custom URL scheme is a prefix you invent and register for your app, such as recipeapp://. Any link that starts with that prefix is handed to your app.

Custom schemes are quick to set up, but limited. Apple's documentation on defining a custom URL scheme says that custom schemes are "an acceptable form of deep linking" but that universal links are "strongly recommended". Two reasons stand out:

• Nothing stops another app from registering the same scheme. If two apps claim it, Apple says the app the system targets is undefined.
• A custom scheme URL is not a web address, so there is nothing to fall back to. If the app is not installed, the link fails, and on iOS the user can see an error saying Safari cannot open the page.

Universal Links

A Universal Link is an ordinary https:// link to your own website that iOS opens in your app instead. Apple's guide to allowing apps and websites to link to your content describes the behaviour: when someone taps a universal link, the system sends it directly to your app without going through the browser, and if the person has not installed your app, the same URL opens in their browser so your website can handle it. One URL works for both.

To prove that the app and the website belong to the same owner, you set up a two-way association:

• On your website, you host a file named apple-app-site-association in the .well-known directory. It lists your app's identifier and the URL paths the app handles.
• In your app, you add the Associated Domains capability in Xcode with an entry such as applinks:recipes.example.com.

When the app is installed, iOS downloads the file and checks that the two sides agree. The details are in Apple's guide to supporting associated domains.

How do deep links work on Android?

Android uses the same two ideas, both built on intent filters.

Intent filters and custom schemes

An intent filter is an entry in your app's AndroidManifest.xml that tells Android which links an activity can open. Google's guide to creating deep links lists what the filter needs: the VIEW action, the DEFAULT and BROWSABLE categories (without BROWSABLE, a link tapped in a browser cannot reach your app), and one or more <data> tags describing the URLs, with at least a scheme.

A filter with the scheme recipeapp makes recipeapp://... links open your app. You can also declare https links this way, but Google notes that plain deep links are subject to the system disambiguation dialog, the "Open with" prompt that asks the user to choose between your app and other apps that can handle the link.

Android App Links

Android App Links are the verified version, and the Android equivalent of Universal Links. According to Google's App Links documentation, they establish a trusted association between your app and your website, so that verified links open in your app immediately, with no dialog. They are supported on Android 6 and later, on devices that have Google services.

The setup mirrors iOS:

• Add android:autoVerify="true" to the intent filter for your https links.
• Host a Digital Asset Links file at https://your-domain/.well-known/assetlinks.json that names your app and its signing certificate.

When the app is installed, Android fetches the file for each domain in your intent filters and verifies it. If verification does not pass, your links still work as ordinary deep links, but they may open the browser or show the chooser.

What are the main types of deep links?

Universal Links and App Links are not separate from deep links. They are the recommended way to build them on each platform. "Deferred" and "contextual" describe what a link can do, so a single link can be a Universal Link, deferred and contextual all at once.

For the trade-offs in more detail, see our comparison of deep links, Universal Links and deferred deep links.

What is deferred deep linking, and when do you need it?

Deferred deep linking is deep linking that survives an install. If the person tapping the link does not have the app yet, they are sent to the App Store or Google Play first, and the original destination is delivered to the app the first time it opens. The link is "deferred" because its job is postponed until after the download.

Neither Universal Links nor App Links do this alone. Both fall back to the website when the app is missing, and after an install the app opens on its home screen with no memory of the link.

How a deferred deep link works

1. The user taps the link. It goes to a server run by you or your linking platform, which records the destination and any parameters.
2. The server checks the device. If the app is installed, the link opens it directly. If not, the user is redirected to the correct store.
3. The user installs the app and opens it.
4. On first launch, an SDK in the app asks which link led to this install and receives the destination and parameters.
5. Your app routes the user to that screen.

Step 4 is the hard part, and it differs by platform. On Android, Google Play provides the Play Install Referrer API, which lets an app retrieve the referrer URL of its own install, along with the times the click happened and the install began. On iOS, the App Store does not hand a referrer string to the app in the same way, so linking platforms hold the link details on their own servers and return them when the newly installed app checks in.

When you need one

You need deferred deep linking when many of the people tapping your links will not have the app yet, and where they land after installing changes the outcome:

• Referral and invite links. The new user should see who invited them and receive the reward.
• Affiliate and creator links. The sale has to be credited to the person who shared the link.
• Promotions and shared content. Someone who tapped a link to a specific offer, product or article should land on it after installing.

If your links only go to existing users, standard Universal Links and App Links are enough. Our guide to deferred deep links for app marketing covers the marketing use cases in more depth. If you used Firebase Dynamic Links for this, the service shut down in August 2025; see what replaces Firebase Dynamic Links.

Why do deep links break?

Deep links depend on your website, your app and the operating system agreeing, so there are several places for them to fail.

The association file is missing or wrong

Most Universal Link and App Link failures come back to the file on your web server. Apple states that the apple-app-site-association file must be served over https:// with a valid certificate and with no redirects. Apple also requires each subdomain to have its own entry and to serve its own file. On Android, a wrong certificate fingerprint in assetlinks.json is a frequent culprit.

Verification did not pass on Android

When App Link verification does not succeed, Android treats your links as ordinary web links, so the user gets the browser or a chooser. Google's documentation notes that on Android 11 and lower, the system makes your app the default handler only if it finds a matching file for every host in the manifest, so one misconfigured domain can affect the others.

The tap happened somewhere links behave differently

Apple documents one surprising case: when a user is browsing your website in Safari and taps a universal link to the same domain, iOS keeps them in Safari, on the assumption that they want to stay in the browser. Links to a different domain open the app. Behaviour can also differ when a link is opened inside another app's built-in browser, or when an email tool rewrites your link to pass through its own click-counting domain, because the domain being opened is no longer the one associated with your app. Test links in the places your audience will really tap them.

The app opens but lands on the home screen

The operating system did its job and your app did not. Either the app does not handle that URL path, or the handler runs before the app is ready to navigate (for instance, before the user is logged in). Hold the destination until the app can show it.

What does a deep linking platform do?

A deep linking platform is a service that creates and manages deep links for you, so that one link behaves correctly on every device. Insert Links, the deep links built into Insert Affiliate, are one example, and Branch and AppsFlyer are two others. You can build basic deep linking yourself with the features above. A platform earns its place when you need what the operating systems do not provide:

• One link for every case. The platform detects iOS or Android, app installed or not, and routes accordingly.
• Deferred deep linking. It stores the link details at tap time and returns them to the app on first open, through its SDK.
• Hosted association files. It serves the apple-app-site-association and assetlinks.json files on a link domain, so you do not maintain them yourself.
• Parameters and reporting. It carries campaign, referral or affiliate data through the install and reports on clicks and opens.

Where this fits with affiliate links for apps

A creator shares a link, a follower taps it, installs the app, and subscribes a few days later. Unless the affiliate's identifier travels through the install, nobody can say who earned the commission.

Insert Affiliate handles this with its own deferred deep links, called Insert Links. Each affiliate gets a link that detects whether the user is on iOS or Android and whether the app is already installed. If it is, the link opens the app and credits future sales to that affiliate. If it is not, the user goes to the App Store or Google Play, and on first open the SDK recalls which affiliate referred them. Insert Links can run on a custom URL scheme alone, with Universal Links and App Links as an optional, recommended upgrade. The Insert Links setup guide walks through each step. If you already use Branch, AppsFlyer or another deep linking platform, Insert Affiliate can read the affiliate from those links instead, so you do not have to replace anything.

Frequently asked questions

What is the difference between a deep link and a normal link?

A normal link opens a web page in a browser, or at best opens an app on its home screen. A deep link opens a specific screen inside an app, such as a product, a profile or an offer. The best deep links are also ordinary https:// links, so one URL serves both the app and the website.

What is the difference between deep linking and deferred deep linking?

Standard deep linking only works when the app is already installed. Deferred deep linking also works for people who do not have the app: it sends them to the store, then delivers the original destination when they open the app for the first time. You need it for referral, affiliate and advertising links.

Are Universal Links and App Links the same thing?

They do the same job on different platforms. Universal Links are Apple's verified https:// deep links for iOS, and App Links are Google's equivalent for Android. Both rely on a file on your website that proves you own the domain and the app, and most apps set up both.

Do I need a deep linking platform?

Not always. If you only need links that open an installed app on the right screen, Universal Links and App Links cover it with no third party. A platform becomes worthwhile when you need deferred deep linking, a single link that routes by device, or data carried through the install, because the operating systems do not provide those out of the box.

Where to start

If your app has no deep links yet, pick the few screens people most need to reach, give them clean https:// URLs, and set up Universal Links and App Links with a web fallback. Add deferred deep linking when you start sending links to people who do not have the app, which is when referral and affiliate programmes begin. Insert Affiliate is free to start if you want those links to pay commission on the purchases they drive.