The evolution of web-based "application jump" technology

Due to the convenience of web communication, almost all APP manufacturers use the promotion method of diverting traffic from the web to the APP. Specifically, it provides some trigger points (such as buttons, links) on the web page to jump to the APP.

URL Scheme

In the early days, application redirection could only be achieved through "URL Scheme". For example, through the following "URL Scheme", you can jump to "BeiLiao APP":

 ibeiliao://

There are also multiple ways to call "URL Scheme" in a web page:

 <!-- Option 1: Link jump-->
 <a href="ibeiliao://">Open BeiLiao</a>

 <!-- Option 2: JS jump -->
 <a href="javascript:location.href='ibeiliao://'">Open Beiliao</a>

 <!-- Solution 3: iframe call-->
 <span id="open-ibeiliao">Open Beiliao</span>
 <script>
 document.getElementById('open-ibeiliao').onclick = function() {
 var iframe = document.createElement('iframe');
 iframe.src = 'ibeiliao://';
 iframe.style.display = 'none';
 document.body.appendChild(iframe);
 setTimeout(function(){
 document.body.removeChild(iframe);
 }, 3000);
 };
 </script>

Originally, "Solution 3" was the best, because if the corresponding APP was not installed, the other two solutions would cause a pop-up window "The browser cannot open the webpage" to appear under iOS Safari.

However, "Solution 3" was "killed" in the end. It first failed in Safari in iOS 9, and later in the browsers of some Android phones. So currently we can only use "Solution 1" and "Solution 2", and the pop-up box under iOS Safari cannot be avoided.

In theory, "URL Scheme" can be used in any browser and WebView in APP, but in reality it is blocked by a large number of APPs and can only be used in browser-type APPs. This is because most manufacturers do not want users to leave their APPs.

Open or download?

The previous article mentioned a problem, what if the device does not have the APP to jump to, what should we do? Normally, we should jump to the download page of the APP. However, the biggest problem here is that the web page basically cannot know whether the current device has installed a certain APP (the reason why I add the word "basically" is that when the web page runs in WeChat, it can achieve this function by calling WeChat's internal JS API, but this API is only open to Tencent's "connected users").

Later, people came up with a solution: while using the "URL Scheme" to jump, a timer is used to jump to the download page after a certain period of time. If the app is installed on the device, it will jump to the app, otherwise it will jump to the download page after a certain period of time.

 <span id="open-ibeiliao">Open Beiliao</span>
 <script>
 document.getElementById('open-ibeiliao').onclick = function() {
 window.location.href = 'ibeiliao://';
 setTimeout(function() {
 window.location.href = 'https://mobile.ibeiliao.com/download';
 }, 1000);
 };
 </script>

This basically achieves the goal, but there are still two experience problems that cannot be solved:

• Even if the app is already installed, the browser will jump to the download page. When the user returns to the browser from the app, they will find that the download page appears inexplicably.
• If the APP is not installed, the pop-up window of iOS Safari cannot be avoided, but it will disappear after jumping to the download page.

Dealing with the ban

As mentioned earlier, "URL Scheme" has been blocked by a large number of apps, including the commonly used QQ and WeChat, but no one will give up these two important channels, so we still have to find a way.

The most helpless solution is to prompt the user to "open the webpage with a browser" and then let the user open the APP in the browser. However, this operation is still a bit complicated for non-IT professionals.

Another better way is to jump to Tencent's "App Store" first, and "App Store" will open or download the app based on whether the device has installed the app. Of course, this method requires the app to be transferred to "App Store", and it is only effective for Tencent apps; for other apps, it still only prompts "Open the webpage with a browser".

***One solution is "Universal Links" which will be described below.

Universal links

"Universal links", translated into Chinese as "universal links", have been supported since iOS 9. They can jump to the specified application through a normal https request.

Developers can configure the download page address of the application as a universal link. In this way, when users enter the download page:

• If the APP is already installed on the device, enter the APP;
• If the APP is not installed on the device, go to the download page and there will be no annoying pop-up box.

Most importantly, through "Universal Links", even in WeChat and QQ, you can jump to your own APP as smoothly as silk. Everyone thought that this was a system-level process that could not be blocked by any APP, until one day not long ago, it knelt down in WeChat... According to the analysis of a certain god, Apple still left a "backdoor" for "Universal Links" to make it invalid.

In the Android system, there is also a similar technology, namely App Links, which has been supported since Android M. However, due to the serious fragmentation of domestic Android versions, its application is not very widespread.

summary

Having said that, let's first summarize the implementation plan of application jump.

Android:

• WeChat, QQ: "URL Scheme" is not available, you can transfer through "App Store".
• Browser: "URL Scheme" is available.
• Other apps: prompt to open with browser.

iOS>=9 (supports "Universal Links"):

• WeChat: "URL Scheme" and "Universal Links" are not available, so please use "App Store" to transfer.
• QQ: "Universal Links" is still available.
• QQ Browser: "Universal Links" is not available, but "URL Scheme" is available.
• Other apps: Universal Links is available.

iOS < 9 (Universal Links not supported):

• WeChat, QQ: "URL Scheme" is not available, prompting you to open it with a browser.
• Each browser: "URL Scheme" is available.
• Other apps: prompt to open with browser.

It should be noted that the so-called "other apps" cannot be accurately detected and can only be judged one by one based on the special keywords added by the app in the User Agent (such as "Weibo" for Sina Weibo).

Open the specified page of the APP

The demand is endless. Being able to enter the APP from a web page is just the beginning. The next step is to jump to the specified page. The specified page mentioned here may be a native page or a web page. The key to this process is how to pass the page path when opening the APP.

Let's start with "URL Scheme". We can add paths and parameters to "URL Scheme", for example:

 my-app://open?url=https%3A%2F%2Fcn.bing.com%2F

The APP only needs to parse the parameters and then open the corresponding page. The same is true for "Universal Links":

 https://my-app.com/download?url=https%3A%2F%2Fcn.bing.com%2F

As mentioned above, "URL Scheme" and "Universal Links" are both blocked by WeChat. If transferred through "App Store", the above URL parameters cannot be passed to the APP. In this case, you have to find a space that both WeChat WebView and APP can read and write to pass data, such as the clipboard. The following JS function can write to the clipboard:

 function copyToClipboard(content) {
 var textarea = document.createElement('textarea');
 textarea.style.position = 'absolute';
 textarea.style.left = '-1000px';
 textarea.style.top = '-1000px';
 textarea.value = content;
 textarea.readOnly = true;
 document.body.appendChild(textarea);

 textarea.select();
 textarea.setSelectionRange(0, textarea.value.length);

 var result = false;
 try {
 result = document.execCommand('copy');
 } catch (e) {

 }

 document.body.removeChild(textarea);
 textarea = null;

 return result;
 }

Before jumping to the APP's application treasure address, write the address of the page to be opened into the clipboard in the agreed format:

 copyToClipboard('my-app:open?url=https%3A%2F%2Fcn.bing.com%2F');
 location.href = 'my-app's application address';

After opening the APP through "App Store", the APP will parse the clipboard content according to the agreed format and open the corresponding page.

Here is a detail: Why not just write the complete "my-app://open?url=" into the clipboard, but remove the "//"? This is because in the Android system, some browser apps will recognize the "URL Scheme" in the clipboard as a URL, and then prompt the user whether to open it. For users, it is a bit confusing to click "Open APP" and see this prompt.

Of course, there are some problems with the “clipboard solution”:

• Will overwrite the user's clipboard contents.
• Some native browsers of Android systems do not support accessing the clipboard through JS, but this is not a problem because you can use "URL Scheme" in the browser.

If you don't want to use the "clipboard solution", you can still prompt users to open the page with a browser. The specific choice depends on the decision of each product manager.