Creating deep links into application content isn't something new. Developers have been able to do this for a while now with custom URL schemes. You might have seen a URL with a custom scheme in the past. These URLs are easily recognized and look as follows:

familymovies://FamilyMember/jack 

It's obvious that this isn't a regular web URL because web URLs generally start with a scheme of either http:// or https://. An application can register itself capable of opening URLs with a certain scheme. So, the FamilyMovies app we've been working on could manifest itself as a handler of familymovies:// urls.

However, there are a couple of downsides to this approach. First and foremost, this URL isn't sharable at all. I can't send this URL to any friends that don't have the same app installed. If I were to send this URL to somebody and they didn't have the app installed, they wouldn't be able to open this URL. This is inconvenient because in order for others to access the same content, assuming it's publicly available on the web, we would have to share a different URL that points to the website. But sharing a link to the website usually means that the content is shown in Safari instead of the app, even if it's installed.

The solution to this problem before iOS 9 came out was to use JavaScript on a webpage to attempt to redirect a user to a link that the app could handle. If this doesn't succeed, the user stayed on the website and they would be redirected into the app that the link originally came from. This approach is tedious and error prone. It's simply not as convenient as sharing a link to a website.

There is also a huge privacy concern regarding this approach. Any website can try to redirect a user to a certain URL scheme. This means that websites can attempt to redirect you to a banking app, dating app, or any other app that could give away information you don't want to share with everybody. Once a redirect succeeds or fails, the website may know that you have a certain app installed even though this information should remain private.

The third problem with custom URL schemes is that any app can register as being capable of opening a certain URL scheme. This means that you could create an application that registers as being capable of opening URLs with any scheme you can come up with and unfortunately iOS offers the users no control over which application opens what URL scheme.

Universal Links were introduced in iOS 9 to solve all of the problems that exist with custom URL schemes and more. First of all, a Universal Link looks identical to a regular web link. In fact, a Universal Link is identical to a regular web link. If you've found a great news article on the web and you share it with somebody who has installed the app that belongs to the news website the link is from, the link will redirect straight to the corresponding app. Safari does not open intermediately, there are no attempts made to redirect you from a webpage to a custom URL scheme. The user is simply taken from the place where they tap the link, right to the app.

This is much more secure because in this scenario it's impossible to sniff for installed apps. It's also more convenient because users can share the same link, it doesn't matter if the receiver of the link does't have the corresponding app installed because iOS will know whether the link should be opened in an app or if Safari should handle the URL.

Also, not every app can register as capable of opening a Universal Link. Any app that claims to be able to open a certain Universal Link must be accompanied by the server that hosts the website. This means that if your app claims to be able to open links from a certain domain, you must own that domain. Apple uses a verification file that you must host on the same domain that your app wants to handle links for to make sure that your app does not try to open links on behalf of another app or website.

Apart from security benefits, Universal Links also provide a more unified, seamless experience to your users. With Universal Links, Apple didn't just open the door to a better, easier way to link to content inside of your app, they also opened up an API that makes it really easy for your app and website to share login information securely. In the same fashion that ties the links for your app and website together, you can also tie your app to the login credentials stored in Safari for your app. Any user that logs in to your website through Safari can automatically be logged in to your app.

Now that you're aware of the great features and possibilities of Universal Links, let's see how this all works on the server side.