In the last part of this Mobile Deep Link series, we’ll go a little deeper into technical aspect of mobile deep linking. I say “a little” because this post is not gonna cover the whole code libraries to implement mobile deep link, but just the basics of deep link structure and implementation details as well as a deeplinking framework intended to make it easier to get started.

1. Deeplink Structure

A deeplink functions much like a traditional hyperlink on a webpage. It is composed of separate elements that make up what is referred to as a Uniform Resource Identifier (URI). The URI contains all the information that, when invoked, launches a mobile application with a specific screen.

When thinking about deeplink structure, the best practice is to implement a URL with a unique scheme name and routing parameters (path and query strings) that represent custom actions to take in the app. Unless you have very specific needs, we recommend using a simple URL structure as shown in the example below:


Where mobiledeeplinkingprojectdemo is the scheme name and path and query string are the routing parameters used to further route the user to a particular experience in the app.

For the scheme name:

  • When choosing a scheme name, it is essential to choose a name unique to your brand to avoid conflicting schemes across different applications
  • There is currently no central authority to manage conflicts with scheme names
  • The best practice is to have the scheme name reference your brand (e.g. mobiledeeplinkingprojectdemo). Another suggested pattern for scheme names is to use reverse domain name notation (e.g. org.mobiledeeplinking), but this is not widely followed

For the routing parameters (path and query string):

  • Routing parameters are optional, but are highly recommended. Routing parameters provide you with further control for routing the user to specific screens of the application or passing in additional parameters
  • The query string is optional, and might be used if you need to pass specific parameters, like a product ID
  • Third parties may append additional metadata to the routing parameters, so it’s important that your app can handle this use case (the iOS and Android libraries discussed in Part 2 account for this)
  • If the mobile app has a corresponding website, it is recommended that the routing parameters syntax for the mobile app match the URL structure on the website

Here are a few examples of deeplinks for popular apps on iOS:

DeveloperDeeplink – e.g.Purpose
Twittertwitter://timelineOpens the Twitter app and links to the user’s timeline
Facebookfb://profileOpens the Facebook app and links to the user’s profile
Yelpyelp://Opens the Yelp app (note: this example does not include any routing parameters)

2. Deeplink Implementation

Regardless of whether you choose to use the MobileDeepLinking library, implementing deeplinking requires you to:

  • Select the URI scheme you’ll be using, and declare it in the app’s manifest (discussed in more detail below). As discussed in Part 1, the scheme name must be unique to your app, otherwise conflicts with other apps may occur
  • Define the actions you want to launch by using a deeplink. Make sure these actions are in accordance with the URI syntax you chose. As mentioned in Part 1, the use of the URL syntax is highly recommended (e.g. schemename://path?query_string)

Once that’s done, you can start implementing the code that will handle the path and query string sections of the URL to launch the intended action.

It is recommended that you utilize the MobileDeepLinking libraries, but if you wish to implement mobile deeplinking directly, the high level process is as follows –


iOS apps are self-contained entities. There is only one point of entry in the app: the AppDelegate. When a deeplink to your app is initiated, it will call the AppDelegate with the deeplinking metadata.

It is important to maintain a consistent state in your app while providing the desired experience. A deeplink may be fired at any time in any app state, and it is your responsibility to keep the app in a stable state.

For example, this can mean allowing the user to return to the main screen of your app. To accomplish this, you must push the appropriate view controllers to send the user to the desired part of your app while still maintaining the correct view hierarchy.

When the app is opened, you can recover the URL that was used to launch it and process it according to your needs.

You can find reference documentation on the AppDelegate here.


Android apps are composed of a set of Activities. Each of these Activities can be called by other apps if configured as such. Depending on how your app and deeplinks are structured, you can choose to use one central endpoint or many.

It is important to maintain a consistent state in your app while providing the desired experience. An Android Activity will launch on top of the current context and it is your responsibility to ensure the appropriate view hierarchy is maintained. Additionally, it is important to have the necessary data ready for the Activity when it is loaded for the user.

When the app is opened, you can recover the URL that was used to launch it and process it according to your needs.

You can find reference documentation on Android deeplinking here.


Deep links are simply a way to identify, address and transport users to specific content in apps. While convenient (and necessary), they’re not that revolutionary or exciting. The future value of deep links lies in how we use them — what’s built on top of them, and the new consumer experiences they’ll enable.

This will include novel ways to discover deep links for apps that you have, discovering new apps through deep-linkable relevant content and services, and the transfer of more intelligence across the links themselves. Much like a hyperlink, it’s not the mechanism that will change the world, but the way we use them to connect the web together.


Mobile Deep Link – Part 3: Implementation
Rate this post
A knowledge craver who always strive to be wiser everyday.