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.
Before going further, let's define some vocabulary.
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).
Since we are talking about urls, here is the standard format for urls:
In the mobile industry, we often refer to the following 4 types of URL:
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
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.
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:
Universal links also exist for Android 6+ and are known as App Links.
* in the schema, desktop also stands for mobile browser.
Universal links and deeplinks are really useful but are facing many limitations that can be frustrating. Let see these situations:
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:
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 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:
That story reveals many issues that can be summarized with the current mistakes to avoid
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:
When the uncertainty is removed, you can now identify the scope of your feature
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?
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:
Additional questions can affect the solution you will take. For instance
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.
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
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:
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...