📜 ⬆️ ⬇️

Deep Linking for Mobile Applications

At WWDC 2015, Apple engineers said they revised the approach to Deep Linking, last year Google announced the App Index - as a new look at deep links, in early 2015 in the world of mobile development they started talking about contextual Deep Links. What is this tool and how to work with it in relation to iOS - I will tell in this article.

What is it?


One of the ways to increase conversion while promoting an IT product is to reduce the barriers for users to achieve the desired goal. In mobile development, this problem is even more urgent. When using e-mail, push or sms-newsletters with information about promotions, simplifying access to the application functionality is simply necessary. In such a situation, simply launching an application from an external source is not a solution, because a promotion is a specific special offer in a specific section. So that after launching the application, the user does not have to wander through it, search and get annoyed, you need an additional tool that predetermines navigation. And there is such a tool.
Deep Linking (deep linking) - technology through which the user can move between applications in pre-defined sections.



How it works?


Imagine that a pizzeria decided to conduct an advertising campaign, in which it invites everyone to buy pizza Margherita with a 50% discount. The pizzeria has a website and a mobile application (the latter, of course, is preferable for working with a client for marketing reasons, and operations with a bank card are much more convenient in an application than in a browser). The company makes an sms-newsletter on its client base with information about special offers and gives a link to the desired section of the site. If a pizzeria application is installed on the client’s smartphone, then when clicking on the link, the site server will send the client immediately to the desired app partition for ordering (this is the Deep Linking mechanism); via the link in sms (or continue to use the web version).
')
In the concept of the World Wide Web, Deep Linking was incorporated into HTTP and URL as the ability to move between any documents on the network, not just the root pages. In mobile operating systems, this mechanism is implemented in different ways.

How to do it in iOS


The principle of operation of Deep Linking is as follows: the user initiates the transition by URL, the resource located at this URL determines the operating system and accordingly transitions to the application in the pre-defined section.

URL - a link indicating the location of a resource. Used primarily for network addressing, but can be used to indicate a location in the file system.

This technology has several ways to implement:

Classic iOS implementation


A common implementation consists of the following steps:

1. Translation of the request into the URL scheme, its execution with the ability to handle the absence of the scheme.
2. Processing of the scheme and navigation within the application to the specified section / screen.

URL scheme (URL scheme) - part of the URL to: //, responsible for the scheme of interaction with the resource to which the link itself leads, in most cases means the protocol.

There are a number of registered schemes, for example http, ftp, tel, mailto , etc.

Creating, executing and processing the result of the execution of the URL scheme

In order to correctly convert an HTTP request into a URL scheme, you need to store a correspondence table and / or a specified translation rule on the server.

There are several ways to correctly execute the URL scheme and process the result. It all depends on which environment the URL is executed from. If this happens in an iOS application, then there are standard ways to check if the URL scheme is registered in the system:

 [[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@”myapp://”]]; 

If the scheme is executed from the web environment, then it is best to use a JS script that will either launch the application or send it to the necessary resource.

Example:

 $(function(){ window.location = 'myapp://'; setTimeout(function(){ window.location = 'fallback.html'; }, 500); }); 

If after 500 ms the transition under the “myapp: //" scheme (the previously generated scheme) fails, the transition to the “fallback.html” will be made.

This script must be embedded in the resource responsible for the transition.
On GitHub there are several more or less successful implementations of such solutions.

Processing the received URL scheme and navigating inside the application

This part of the implementation of Deep Linking relates exclusively to the application, which must process the user's request and translate it into the necessary section.

To do this, first of all, you need to register your own URL scheme, which will be associated with the application.
In the settings of the main project target in the Info section you need to add in the URL Types —URL item the type of your scheme (Figure 2.)



In the Identifier field, you must specify the application bundleID, and in the URL Schemes field, the scheme with which your application will be associated. Next, you need to implement a navigation mechanism in the application. To do this, you need to handle the possible transfer to the application URL. You can transfer it in many ways, we will consider the direct execution of the scheme in the system.

In order to handle the launch of an application via a URL, in the application's AppDelegate method:

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 

From the lauchOptions dictionary, lauchOptions object by the UIApplicationLaunchOptionsURLKey key. If the object exists, it means that the application is launched via a URL scheme and this scheme can be processed. If the application is launched at the moment of executing the scheme, then the URL must be extracted in the same AppDelegate method:

 - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation 

Here it is necessary to use the url parameter for further navigation. Navigation in the app is an entirely personal choice, but I would recommend using the Router pattern. Firstly, it does not violate the principle of Single Responsibility, secondly, it will allow to encapsulate and later use this navigation from any place. A router must take a URL (as a key) and issue a ViewController or perform this navigation.

Third Party Solutions


From third-party solutions, you can consider Mobile Deeplinking (AppURL, AppLinks, UrbanAirShip, etc.) , these frameworks are complete solutions for the implementation of all components of Deep Linking technology. They contain separate libraries with their own external URL handlers and the navigation mechanism in the application. Accordingly, such solutions require the integration of their SDK in the project.

We should also consider a solution that does not require integration: Deep Link Me is a service that allows you to launch an application with a specific link, and if the application is not installed, redirect to the store. All settings occur directly on the site, from the possible options:

The only inconvenience of this solution is that the entire transit takes place via deeplink.me, which the user will undoubtedly see. To use this tool, you must implement support for URL schemes and navigation in the application yourself.

New look for Deep Linking


What does Google offer us in deep binding technology?

More recently, Google launched a new line of App Indexing. Of course, for the most part, it is aimed at Android development and is implemented as convenient as possible for her, but iOS has not been forgotten, though in a limited beta version.

So:
In addition to the workable Deep Linking, the indexing of the application in the Google search engine also appeared. As a result of a search on the world wide web, links to sections of the application will be displayed.

For implementation it is necessary:

1. Register another URL scheme in the project in the format:
gsd-{scheme}

where, “scheme” is your scheme registered above.
2. Connect the GoogleAppIndexing framework (you can through CocoaPods)
3. In the above methods of your application, process the transition as follows:
  NSURL *sanitizedURL = [GSDDeepLink handleDeepLink:url]; 

This will help to connect your application with Google App Indexing and create a panel to return to the search.
4. You must configure your site to which the transition is made. To do this, add the following to the site header:
 <html> <head> ... <link rel="alternate" href="ios-app://{itunes_id}/{scheme}/{host_path}" /> ... </head> <body> … </body> 

You can also give GoogleBot access to your site for full indexing.

All of these methods are based on working with URL schemes. She has long been known and practiced. Known and problems that may arise with them. For example, the behavior is completely undefined if two different applications register the same scheme. You also need to handle alternative behavior if your application is not installed. In such situations, all responsibility falls on the developer and implementation errors, unfortunately, become common practice.

How to avoid such situations?

Again, Apple does not disappoint us - starting with iOS 9, HTTP and HTTPS support has been added with a direct transition to the application.
In June 2015 at WWDC, the “guys from Cupertino” told us about a new approach to implementing such a convenient mechanism for promoting a mobile application.

They called it Seamless Linking, which can be translated as “seamless links”. This mechanism allows you to use the same web URL as when navigating through sections of your site, in addition, the connection between the application and the web resource occurs through the application's Bundle ID, which makes this connection unique, you can also specify those sections of the site that are represented in your mobile app, and Deep Linking will only work for them. Well, cool !!!

How it works?


The link is processed in the system and the domain (or host) is extracted from it and the path directly through which you can control the navigation in the application:

https://n-pizza.com/margarita_new

n-pizza is in this case a domain. The domain must be associated with the application through a special file protected by an SSL certificate that is stored on the site server. It should be called apple-app-site-association and contain a special JSON structure.

 { "applinks": { "apps" :[], "details":{ “123456.npizza.com” :{ "paths": ["*"] } } } 

Where 123456.npizza.com - app_bundle_id
“path” : [“*”] - says that your application supports all sections of the web resource, otherwise, you can specify certain paths:

 { "applinks": { "apps" :[], "details":{ “123456.npizza.com" :{ "paths": ["/margarita_new", "/old/greate_pizza/*"] } } } 

Next, the created JSON must be signed with the certificate that is used on your web resource, or generate a new one (it is permissible to use WildCard certificate), sign them with JSON and add it to the server. The certificate that is signed by the application in this case is not used.

It is important to understand that for each domain there must be a unique apple-app-site-association file

n-pizza.com/apple-app-site-association

In the application, you must establish associations with the domains that you support in “Associated Domains” in the project settings. And universal references must be processed in the AppDelegate method:

 - (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray *))restorationHandler 

Where, the type of activity for generic links will be:

 NSUserActivityTypeBrowsingWeb 

You can decompose the URL using native tools such as: class
 NSURLComponents 
or third-party frameworks like Bolts from Facebook. Further, the navigation should take place according to the already known scheme outlined above.

As a result, the user, clicking on the link, either finds himself on the resource where the link led, or in the application. A huge plus of this solution is that URL schemes are not used. But no less negative, that the solution is only for iOS and only with version 9.

Contextual Linking


Everything that is written above works great and gives the desired effect of penetrating the application only if the application is already installed. If you think about it, then the real benefits will be for large companies whose applications are installed by the majority of smartphone users, and there are no more than 40-50 of them.

If the application is not installed, and most of them are in the AppStore or Google Play, the user will be on the page of the site or in the application store, which is also not very good, because After installing and running the application, the main screen will be shown. Any of the scenarios is equivalent to a non-working Deep Linking.

To achieve the full effect of Deep Linking, there are contextual deep links. The essence of their work lies in the fact that the condition of transition into the application (parameters in the URL scheme), which is used for further navigation, and the device identifier are saved on the server side. After installing and running the application, this condition is requested and the navigation is built. For the user, everything looks neat and seamless.

You can implement this approach in conjunction with any of the above methods. Or use a ready-made solution by building an SDK.

Source: https://habr.com/ru/post/267587/


All Articles