iOS Deep Linking: Universal Links Overview

December 18, 2016

I recently posted an article on URL schemes, detailing the benefits and restrictions of this approach for deep linking. Apple introduced Universal Links with the release of iOS9, addressing URL scheme’s shortfalls, but introducing some new challenges.

Universal Links: The Latest Approach

Apple’s Universal Links is the successor to URL scheme deep linking, available in iOS9+. Universal Links is linking web page addresses which can open an app. Essentially, this means a Universal Link uses http or https as it’s scheme, and you must own the linked web page (the URL’s authority). As a result, Universal Links are also guaranteed to be unique and are automatically recognized as links in other apps.

In addition to peace of mind, the significance of a unique link is that iOS is able to launch your app with confidence: the user will not be prompted when opening a Universal Link. This makes the user experience seamless. These are major advantages to Universal Links when compared to the old method, URL schemes.


As the web page needs confirm it’s association with an app, this introduces some requirements. For iOS to detect if a listed web page is associated, on app install it will check for a file hosted at a specific location on the domain. This is a one time operation and is only repeated if the app is reinstalled.

The file in question is apple-app-site-association. It must be accessed over SSL as https://<domain>/.well-known/apple-app-site-association on iOS 9.3 and https://<domain>/apple-app-site-association prior to that. For example, on my site I would host at The file must not have an extension, but the MIME type must be application/json. The file access is described briefly in Apple’s docs:

After you create the apple-app-site-association file, upload it to the root of your HTTPS web server or to the .well-known subdirectory. The file needs to be accessible via HTTPS—without any redirects—at https:///apple-app-site-association or https:///.well-known/apple-app-site-association.

For the hobbyist, SSL certification can be a limitation since hosting and gaining certification can be expensive. Fortunately, the certification for a limited number of domains can be acquired for free on sites such as startSSL.

Universal Links also allow the user to arrive at a destination without having the app installed: the web page simply opens in Safari. While this may not be appealing in some cases, you can still use the web page to host javascript which can redirect the user to the app store.

A note on Universal Links that can be easily overlooked is it’s availability from other apps. Apple’s documentation states:

If you instantiate a SFSafariViewController, WKWebView, or UIWebView object to handle a universal link, iOS opens your website in Safari instead of opening your app. However, if the user taps a universal link from within an embedded SFSafariViewController, WKWebView, or UIWebView object, iOS opens your app.

This means if you try and open the link from messaging or sharing apps that implement a browser in that way, your Universal Links will not work. Be sure to test deep linking if you’re hoping to redirect from specific sources.

I hope you’ve enjoyed this overview of the features and limitations of Apple’s official deep linking options. Universal links are great for giving users direct access to your content, but it’s important to plan the approach. Happy linking!


iOS Deep Linking: URL Scheme Overview

October 11, 2016

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 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:

"Waking a background app to open a URL".

“Waking a background app to open a URL”.

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.

A custom URL scheme being used to launch an app. In practice, this will be launched using openURL: or a hyperlink.

A custom URL scheme being used to launch an app. In practice, this will be launched using UIApplication’s openURL: or a hyperlink.

The user will be prompted to open a valid custom URL scheme.

The user will be prompted to open a valid custom URL scheme.

When no app with the custom scheme is found, nothing useful happens.

When no app with the custom scheme is found, nothing useful happens.











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!


Developing Univore

September 27, 2016

Screen Shot 2016-09-07 at 11.37.00 AM

An app I developed, Univore, was recently released for iOS (you can also read the technical overview here)! Students (and dieticians!) seem to really be enjoying the recipes and simple instructions that Univore provides. It’s been wonderful to hear all the feedback.

When we were preparing for release, the Univore team organized for an article by the U of T MD Program to be released. This tells the origin story of the idea for Univore – but what about it’s development?!

I met Liz and Brandon while attending UHN OpenLab’s Open Rounds, a weekly forum to discuss current projects and new ideas. Liz and Brandon presented the Univore concept, but mentioned they were having trouble finding a programmer. “Hm…I’m a programmer”, I thought. After the meeting I introduced myself and got to know a little more about what they had in mind for the project.

Univore was created to assist with healthy eating choices.

Univore was created to assist with healthy eating choices.

Liz and Brandon had enlisted the design services of the extremely talented Karen Keung, who had already created much of the design for the app. It looked beautiful! The finished designs was a major selling point for me – it was much easier to visualize a great finished product, and having the UX and UI settled made my job a lot easier!

Despite the finished concept and designs, there were some challenges during development. I still had about a year left in medical school and had limited time to dedicate to development. The design, while exceptional, required extra work to implement some custom components. The late addition of the grocery list feature caused some interesting challenges (namely combining different custom quantities of ingredients, such as “a handful” and “a tablespoon”).

How many red peppers should I buy for "1/4 cup of chopped peppers"?

How many red peppers should I buy for “1/4 cup of chopped peppers”?

Fortunately, the app was finished by the end of the semester, in time for Brandon and Liz to organize a focus group for testing. The feedback sparked a couple last minute changes, the most important being the explanatory introduction screens, and we prepared for launch on August 22!

I find it incredibly gratifying to finish projects and see them grow in the wild; I’m very proud to see Univore on the App Store! Try it now!! And while the work is done for now, I’m already getting excited to start my next project!

Univore in the wild!

Univore in the wild!