About this doc
As I was asked about it many times in our development team and their stakeholders, I'll introduce Android / iOS mobile deeplinking technologies and how it works as far as I know.
TL; DR
- Don't use Custom URL Scheme except for the purpose of backward compatibility
- Use App Links (Android) or Universal Links (iOS) or 3rd party tools for deeplinking. When we use a 3rd party tool, please be careful of vendor lock-in
- App Links and Universal Links cannot handle some irregular cases. Please be aware of it and prepare a necessary contermeasure
What is deeplinking?
Mobile deeplink (this article will call it "deeplink" or "deeplinking" simply) is a link to access a specific feature of a mobile app.
By locating a link inside an app, you can navigate a user of one mobile app to another mobile app. It is useful to achieve a seemless navigation from Web to Mobile, or to promote some new feature.
Terminology in this article
Source (Web/mobile) app: An app that contains a deeplink. It can be a Web Browser app that can display the content of Web app (like Chrome app or Safari app) or an ordinally mobile app in a smartphone / tablet device (like Rakuten Ichiba app)
Target (mobile) app: A mobile app that is supposed to be opened by a deeplink located in the source app
Linked Web site: A Web site that has a valid domain exposed to the Internet and has a valid configuration for deeplinking. It is used to demonstrate that a target mobile app is linked with a specific service
Technologies used to achieve deeplinking
We have several ways to achieve these requirements. Let me introduce some of them.
1. Custom URL Scheme
Custom URL Scheme is an old technology to achieve deeplinking.
By locating a link whose URL starts with a custom scheme to your Web page, or that contains a click event into your Native UI (like a button), a mobile app that has a logic to deal with the link will be opened.
Example
pointclub://openwebview?url=xxx
rpay://
How it works
Implementation
- Developer of the target mobile app implements a logic to deal with a specific Custom URL Scheme (= adds a code to specify which action in the mobile app should be triggered by which URL), and then release the app
- Developer of the source Web/mobile app locates the link to their app, and then release the app
How deeplink works
- User installs the target mobile app into their mobile device
- When the user tries to open a link in the source app that contains the registered Custom URL Scheme, the mobile device will open the target mobile app and do whatever it wants
Pros
- Old but stable way that works with older devices
- Does not require any server side configuration
Cons
- The device cannot do anything (= Nothing happens) if the target app is not installed into the device. This means, the source app should handle the case when the target app is not installed, by itself.
- The device cannot / won't gurantee the behavior if multiple app in one device has a handling logic of a same Custom URL Scheme. This means, any other app can potentially "steal"
pointclub://
to open their app instead of our App 1
Personally, I don't recommend implementing Custom URL Scheme at all. It has fatal vulnerabilities listed above, and it is getting less popular.
Ref
- https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app
- https://developer.android.com/training/app-links/deep-linking
2. App Links (Android)
https://developer.android.com/training/app-links
Both of App links (for Android) and Universal Links (for iOS) are new technologies to deal with the problem of Custom URL Scheme.
The difference between these technologies and Custom URL Scheme is, by linking a target app with a specific (trusted) domain, it determines the behavior when the target app is not installed, and avoids the conflict of the target apps, described as disadvantages of Custom URL Scheme.
Example
How it works
Implementation
- Developer of the linked Web site uploads a configuration file called Digital Asset Links JSON. It should contain an info about the target mobile app (like its package name etc.) Example: https://point.rakuten.co.jp/.well-known/assetlinks.json
- Developer of the target mobile app implements which action in the mobile app should be triggered by which URL, and then release the app
- Developer of the source Web/mobile app locates the link to their app, and then release the app
How deeplink works
- User installs the target mobile app into their mobile device. At this point, the device tries to get the Digital Asset Links JSON from the linked Web site (its domain is described in Android Manifest) and to link it with the target app
- When the user tries to open a link in the source app that contains the registered Custom URL Scheme, the mobile device will open the target mobile app. If the target mobile app is not installed, it will try to open the link with the Web browser app or the source app itself (if it has in app browser mechanism)
Pros
- We can use a "normal" URL for deeplink
- More secure
- It can explicitly determine the behaivor when the target app is not installed
- Getting more popular in the future
Cons
- The service must have a Web site linked with the target app
- Difficult to control the behavior when the target app is not installed. We have to prepare a Web page for this fallback purpose
- Has some black box regarding the behavior
- It does not open the app when the source app is a Web Browser app and when the domain of the current page is same as the domain of the Web site Digital Asset Links JSON is located. It is going to be critical if your app has a Web version as well and your Web app wants to open the app by deeplinking
- Difficult to test in an inhouse testing environment
- Works only with Android >= 6
Ref
3. Universal Links (iOS)
https://developer.apple.com/ios/universal-links/
Example
How it works
Implementation
- Developer of the linked Web site uploads a configuration file called Apple App Site Association (AASA) file. It should contain an info about the target mobile app (like its package name etc.) Example: https://point.rakuten.co.jp/apple-app-site-association
- Developer of the target mobile app implements which action in the mobile app should be triggered by which URL, and then release the app
- Developer of the source Web/mobile app put the link to their app, and then release the app
How deeplink works
- User installs the target mobile app into their mobile device. At this point, the device tries to get the AASA file from the linked Web site (via Apple's CDN) and to link it with the target app
- When the user tries to open a link in the source app that contains the registered Custom URL Scheme, the mobile device will open the target mobile app. If the target mobile app is not installed, it will try to open the link with the Web browser app or the source app itself (if it has in app browser mechanism)
Pros
- We can use a "normal" URL for deeplink
- More secure
- It can explicitly determine the behaivor when the target app is not installed
- Getting more popular in the future
Cons
- The service must have a Web site linked with the target app
- Difficult to control the behavior when the target app is not installed. We have to prepare a Web page for this fallback purpose
- Has some black box regarding the behavior
- It does not open the app when the source app is a Web Browser app and when the domain of the current page is same as the domain of the Web site AASA file is located 2
- Difficult to test in an inhouse testing environment
- Works only with iOS >= 9
- Behavior seems to be different according to the OS the device has
Ref
- https://developer.apple.com/documentation/xcode/supporting-associated-domains
- https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content?preferredLanguage=occ
Other technologies
There are some 3rd party services that contains deeplinking as a feature.
4. Firebase Dynamic Links
https://firebase.google.com/docs/dynamic-links
Firebase Dynamic Links is a deeplinking solution provided by Firebase.
Example
How it works
Implementation
- Developer of the target mobile app creates a Firebase project
- Developer of the target mobile app adds the Firebase project by integrating SDK, and then release it
- Developer of the target mobile app adds the deeplinks from the Firebase dashboard
How deeplink works
This doc says how it works. https://firebase.google.com/docs/dynamic-links/operating-system-integrations
It says it technically uses App Links and Universal Links behind the scene.
The main differences are, the linked Web site is hosted by Firebase and it adds some fallback logic when the app is not installed by default.
Pros
- Can use it for free as long as we're using Firebase
- Can deal with the behavior when the target mobile app is not installed by default. It can open either of Google Play / App Store page or a custom URL
- Can workaround the same domain problem described as a cons of App Links / Universal Links. Since the domain of the linked Web sites are different from the domain used by the service, there won't be a problem
Cons
- Vendor lock-in. Note that your deeplink might be located in any places (that you cannot have a control) and be used for a long time
Personally I can recommend to use it if you don't understand the deeplinking well. You can also use it as a countermeasure of the problems happened in App Links / Universal Links.
5. Branch.io
Previously our team was using it.
We need to install an SDK into the target app. Then we can control the behavior of the deeplink (= which URL should open which page/app) by using a dashboard.
6. Adjust
https://www.adjust.com/glossary/deep-linking/
I think many of many apps are using it but don't know much about it.
Top comments (0)