If you are targetting iOS9+, you should consider Universal Links.
Deep links are links that can redirect to an app if you open them on your phone. They are powerful for sharing and leveraging apps as a content resource, as the links can open a specific screen. As such, deep links are growing in popularity, wielded in the never ending quest of cultivating users.
URL Schemes: A Serverless Past
Prior to iOS9, URL scheme deep linking was the main way to open and communicate with apps. URL schemes allow you to define custom parameters that allow the system to open your app. They are easy to implement and are defined entirely within your app, allowing developers to avoid the maintenance of pesky servers.
A common scheme is HTTP, which is used in web browsers: In http://bradkratky.ca, http is the scheme. In a custom URL scheme, you define the scheme and pass the url to your app. RFC 3986 defines Uniform Resource Identifiers syntax components as follows (though it is not required to follow this syntax):
The following are two example URIs and their component parts:
\_/ \______________/\_________/\_________/ \__/
| | | | |
scheme authority path query fragment
Interestingly, you cannot use http or https for the “custom” URL scheme in your app. These schemes will be claimed and handled by Safari. To use an http or https scheme, Universal Links will be necessary. This is a limitation because URL scheme links will not be launched when sharing in format such as e-mail: testapp://testdata may not be recognized and hyperlinked like http links are by many applications.
The URL is passed to your AppDelegate using an NSURL, using application:openURL:options as of iOS9. From there the source application can be verified and the url can be handled, at the mercy of the developer. Apple’s doc on Inter-App Communication explains the process by which the app is then launched:
URL schemes are defined by your app so there is no guarantee it will be unique. Thus, caution should be used in passing sensitive data because it could be inadvertently used to launch another app. From Apple’s docs, there is no way to know which app will be preferred:
If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.
While this seems like a scary drawback, using something specific, such as your app’s bundle (com.companyname.appname), will likely avoid this issue. Apple still can’t be sure where it’s sending you, so it will prompt the user before opening an app via a URL scheme deep link. The user experience will be stricken with an unfortunate alert.
There is a solution: to prevent a prompt when the app is not installed, UIApplication’s canOpenURL: can be used to detect if an app can open the URL and provide logic to handle that case. Unfortunately, this creates additional work because you cannot depend on the resource you’re hoping to provide.
Though URL schemes are useful to launch other applications and very easy to implement, the interference of prompts, having to create a clickable hyperlink or launch from an app and looming possibility of same scheme collisions has this approach reeling. Universal Links were announced with iOS9 and capitalize on URL Scheme’s shortcomings. Stay tuned for the upcoming posts on Universal Links!