Partager cet article

Vous avez un projet mobile ?

Consultez notre offre

Choose the suitable links implementation that fits your needs

I was recently in charge of implementing the deep linking to a client application. I was enthusiastic to take the subject since I had understood the need and I knew how to get to a solution. But things didn't happen as expected. The client changed the expectations several times and it turns out a simple feature to become a complex one.

The purpose of this article is to give some tips on how to choose the best mobile deep linking solution over the market that will fit your need.

Overview of deeplinks

Before going further, let's define some vocabulary.

Linking

Giving a way to people to reach a content in your app. Basically, "linking" refers to the use of a link that brings any user from the place they saw the link to the place they can read the content attached to this link in your app. This app can be web site or a mobile app or even a desktop app (not discussed in this article).

URL

Since we are talking about urls, here is the standard format for urls:

<protocole>://<<auth-data>@><domain><:port></path/><?query-params><#bookmark>

For instance:

http://Jojo:lApIn@www.exemple.com:8888/chemin/d/accès.php?q=req&q2=req2#signet

Links

In the mobile industry, we often refer to the following 4 types of URL:

1. Web Links

When dealing with web, a url link is usually an http link. This link can be opened by any browser from the market. Thanks to a link, you can navigate between the pages of a website. The http link is by nature one of the main components of the web technology.

An example of http link: https://blog.bam.tech/developer-news

2. Mobile Links (aka Deep links)

Http are not the only ones. There are also links such as ++code>ftp://++/code>, ++code>file:///++/code>, ++code>ssh://++/code> based on the different internet protocols or some other like ++code>tel:++/code> or ++code>mailto:++/code> based on desktop or mobile applications. The idea is that each protocol will define its short name also known as the scheme.

This ability has been hijacked in the mobile industry to give to each application the possibility to create its own scheme. Knowing this scheme, the OS can redirect any related links to the targetted application. This is the origin of "mobile deeplinks".

A deeplink is a link to a specific content into your app. It uses the scheme you defined in your application configuration. Here is the default behavior on mobile:

Let's say, you have an application called BAM and you want to point to a content into the blog section.

For a web site, you would have something like **https://blog.bam.tech/posts/234/article-links.**

For a mobile app, you will have something like bamblog://posts/234/article-links.

bamblog is the scheme you defined for your application.

3. Hybrid (Web & Mobile) Links

Based on the success of deeplinks, the rise of mobile applications, the will to improve users experience and for some security reasons, a new concept emerged to replace deep links: Universal Links.

Introduced by Apple with iOS 9 (WWDC19), the idea is simple: how to guarantee that your users will always reach your content when your application is not installed on their mobile phone ?

To reach this goal, Apple gave to the apps developers the ability to use their website url as deeplink, making it possible to use one object for 2 goals:

From desktop, this link will redirect to the browser.
From mobile, this links will redirect to
your app, when installed
the browser, when not installed

Universal links also exist for Android 6+ and are known as App Links.

* in the schema, desktop also stands for mobile browser.

4. Smart Links

Universal links and deeplinks are really useful but are facing many limitations that can be frustrating. Let see these situations:

Deeplinks can be broken: Sometimes when the user follows your deeplink, if the app is not installed on its device, he will need to install it. But just after the installation, the app is opened but the link won't redirect the user to the right place. This problem is known as the broken deferred deeplinks.
Universal link will fallback on the browser: when the app is not installed, the link will redirect the user to the browser. And if you want to redirect to the App Store, the universal link won't be enough in this situation. In response to that issue, Apple highly suggests the use of a smart App Banner in your website that gives a path to the store.
Platform specific content: another common issue with deeplinks is to redirect the user to a specific content based on the place he came from. Let's say you have a unique link that leads to a content and the location of this content is not the same on your app than your web site. But for some marketing and SEO reasons you wouldn't use different links.
Specific webviews: you share your content link to a social network like Facebook and you expect the users to be redirected to your app since you configured it for: OOPS !! The links is broken and always redirect to the browser.

These kinds of situations reveals the purpose of smart links.

A smart link is a link that will give a better guaranty to bring the user to the right place in your application no matter if it's installed or not. You can directly use it as a universal link or use it to alias your own link.

For instance, let's say I have a universal link: http://my-organisation.com/my-specific-content which is not working everywhere. To make it work everywhere, I will replace it with the smart link: http://my-smart-link-solution.com/my-specific-content .

Here is a naive explanation of how it works:

Many solutions exist in the market:

Google came with the Firebase dynamic link giving a great flexibility to the developers. You can for instance define a specific link that will be used on desktop.
Facebook brought its own solution Facebook App Link. If you are trying to campaigns over Facebook, Messenger or Instagram, you may be interested.
There are many other solutions. I can think of Branch, Adjust,... If you have more to recommend, please tell me in the comments!

Just be aware of data tracking. Using smart links, you give the ability to these services to capture analytics and tracking data. Think to disable capture of analytics if you are not using this feature.

The kind of problems you could face

The problem which leads me to this article is that we have successively implemented Deeplinks and Universal links before falling back on the firebase dynamic links. That generated rework for both developers and product owner teams. That also generated some frustration when some links was broken because some update was not properly anounced and Product owner got their deep link broken. In a better world, we would like to choose the appropriate solution before implementing nor installing anything.

Maybe you encountered a similar issue and you are wondering how you could have overcome it. Let's it see together.

Here was the scenario:

Step 1

Product owner [PO] ? Devs: Hey guys ! When a new user subscribes, we would like to redirect him to the app when he clicks on the link received by email
Me: Oh! That's really easy. We can do that. Is that the only need ?
PO: Yes! that's all !
Me ? Devs: Let implement Deep Links !

Step 2

PO: Oh no! it's not working ! when I click onto my email, nothing happens
Backend: Actually, we just found out our email partner solution breaks the deeplinks down and make them not clickable
Me: ? ! OK ! Let implement Universal Links !

Step 3

PO: Argh, it's broken once again ! If I click on the link from Facebook, I'm redirected the 404 page that tells me the link is not supported. I should be redirected to the app if it's installed.
Me: What ?!
PO: We are planing a social network campaign and we want some links to redirect to the app. We are targeting Facebook, Instagram, Twitter and Snapchat.
Me: After some investigations, it turns out that Facebook alters links which breaks them and make them redirect automatically to the browser. Ok ! Let call Big brother. Let implement firebase dynamic links !

What we learned

That story reveals many issues that can be summarized with the current mistakes to avoid

to not challenge the PO need enough
We didn't take the time to ask the right questions that would have helped us to have a better understanding of the real need: "Linking to the app from everywhere", not just from emails.
to not identify the real scope of the feature
We haven't identified during the first iteration that the right feature was in fact to cover different kinds of carriers: emails, social networks, websites over the web
trusting the technology
we trusted iOS and Android about the existence of deeplinking solution but we didn't check either double check the documentation about the right PO need. Will deeplinks or universal links do the job into a social network context ??
define the acceptance requirements at the user story scale and not the "feature" (deeplinking) scale
- at the end of the POC we had good result for each OS (model and minimal version) according to the user story that led to that POC
- but we didn't define for each in which user context the feature should work/ By user context, I mean the app that displays the link (email app, browser, social network app or website, ...)

Understand the need

Before asking which of deeplink or universal link or another link will fit your need, take care of being certain of the real need. It will help to avoid the type of issues we got.

One way to do that is to:

ask a lot of questions about the feature even if it looks really easy and familiar with something you have already done in the past.
check if there is not another way to achieve the purpose before even diving into ADRs and choosing between the available solution: is the email the right solution to send the link ? A notification tab inside your application may do the job. Keep your mind opened.
check the roadmap if it's available. Sometimes you will catch an information that is really useful for your use case but it's not relevant or just considered as another feature from your PO point of view.

Identify the right scope

When the uncertainty is removed, you can now identify the scope of your feature

A. exploring the exhaustive ways your links will be shared

For instance, is it common for your users to share links that pointes to a content in your app ? It will be if you expose a sharing button for instance. Is an operator of your Marketing service able to share links somewhere on the net that leads to a content of your app? Can your servers deliver content that points to a specific content of your app?

B. exploring the exhaustive ways your links will/should be received

For instance, which app could open your app links? We can say that it's OK if your SMS application breaks down url to make them not clickable. Actually, less and less people use to use SMS to share content. But is it the same if the email view breaks them down? or is it acceptable if the link redirects to the browser and not to the app? What about other apps like Slack/Teams/WhatsApp/...? and what about some applications that behave differently following the OS...? This list can't be exhaustive and really depends on your use case.

The picture below represents the ways your links are shared and received. Doing the same diagram for your app will help to clarify the need.

For each block on the left part of the diagram above, you need to check the following things:

is your link modified and wrapped into another link
Ex: https://myapp.org ? **https://someCarier.org?link=https://myapp.org**
is the view that display your link known to be problematical: it can be difficult to test. But achieving this check will reduce the edge cases. You may focus on the one that are expected to work in your application process.
For instance, if you don't send SMS, it's OK if your link do not open the app directly. But in the same time, if you are working on the shopping application, you can imagine that your link could be shared by SMS. The point is that you need to clarify the scope of your application and what you want to handle.

Choosing the solution

Additional questions can affect the solution you will take. For instance

should my link be the same for desktop and mobile environments?
Or, do I need a reporting about the usage of my links ?
the list of question will really depend on your business rules

The BPMN below is the simple version of my check list in which I will add other questions about the price of the solution, the debug ability, the need to configure a backend, the ability to customize and many other.

My toughts

As you can see, choosing a type of link is not easy. It's really important to assess your need before to start coding ...

After being worked on app links, I came to the conclusion that the smartest your link, the most

you increase your retention rate. No matter where the link is clicked, the user is redirected to your app
you reduce frustration of broken links
you increase the user experience by building custom workflows that leads the user to the app or any other web content

I've absolutely no doubts about the solution I will choose the next time I will have to implement a mobile deeplinking solution. I will use Firebase Dynamic Links (FDL) for the following reasons:

highly customizable !!! You can configure different behaviors depending on the user context (mobile or desktop)
no server side configurations unlike universal links unless you are doing really complex things which are not the purpose of this article
reporting about link usage: the reporting tools are available in the Firebase console with the other reporting tools of other service. It's really easy to manage if you are already using Firebase
debuggable thanks the debug parameter offer by FDL
a better resilience: I think I can trust a Google product when dealing with such complex features. I know that doing so will increase the coupling of my app with the firebase service but I'm ok with that since it remains the current better solution in the marker
it comes to a Google price ?

This choice is really personal and debatable. That's why I will always suggest to anyone to focus on its own need.

In hopes this article will be useful...