At the most basic level, a Uniform Resource Identifier (URI) is a format that launches a specific experience or piece of content in an app. Just as many applications recognize https:// or https:// as web URLs and launch the default browser, mobile devices launch apps when a user clicks a link starting with tel:// or a text messaging app for an sms:// link.
How to set up your URI scheme for easy deep linking and app discoverability
That covers launching one app from another, but the true power of URI schemes comes after launch. URI schemes can perform specific actions as an app opens. Check it out:
Open an app:
someapp://
Open a note-taking app and start a new note:
someapp://newNote
Open a retail app and search for brick and mortar shops nearby:
someapp:///storeSearch/location?lat=abc&long=xyz
Open an mCommerce app to look for blue suede shoes at a nearby shop:
someapp://storeSearch/location?lat=abc&long=xyz&search?terms=blue_suede_shoes
As they build, developers determine the addresses above – including the someapp:// prefix.
Optimizing your URI
URIs take on special importance on mobile. The sheer number of mobile apps means that tons of potential URI schemes are out there, since every app can—and should!—have its own. No industry standard for URI scheme creation exists, despite some attempts. Accordingly, we’d like to offer a few suggestions on how to pick a URI scheme that will gives users the best possible experience.
Rule 1: Choose a unique URI scheme
In all of the examples I’ve given thus far, the function of the app determines the URI. For example, https:// works because all web browsers surf the same web. https://www.somesite.com/some/content/here.html would work equally well in Firefox, Chrome, Safari, or Internet Explorer. Even taking into consideration the differences between those browsers in how they interpret CSS and HTML, the same basic content will be loaded in any browser. The website owner doesn’t care which browser people use and users can go to any website quickly and easily – there’s no proprietary software to install. Early on in the web’s history users overwhelmingly rejected walled gardens and opted for a single open web that anyone can add to and anyone can access. Despite the best efforts of some parties to change that, it’s largely held up. As a result, the entire web is on a single URI scheme – http.
Mobile app content, on the other hand, is a series of walled gardens. Facebook Messenger can’t load Google Hangouts or Slack messages. This creates a problem because the end user device has to figure out which application any given URI scheme should open. To give an example, multiple dating apps could conceivably use the dating:// URI, but their content would not be interchangeable and their links wouldn’t work reliably when someone has more than one installed. Say a dating app outputs a deep link like dating://somecontent/xyz to a user with two dating apps using the dating:// URI installed. When the user clicks the link, either app could open, depending on the person’s preferences. If the wrong app loads the user experience suffers, and the developer who drove the launch misses a chance for a meaningful engagement. So myawesomedatingapp:// beats dating:// every day of the week.
Rule 2: Standardize across all platforms
Whether someone has Android, iOS, or a Windows phone, “tel” and “sms” are the same everywhere. Seek to mimic this cross-platform seamlessness. This point may seem obvious, but within a company, each platform tends to have its own dev team. They don’t always communicate—especially in bigger companies. It’s best to map out URI schemes ahead of time so that all app versions follow the same roadmap. It’ll raise the success rate of the deep links and make working with those links easier for less-technical team members to work with your deep links.That’s true whether you build them in-house or use Branch.
Rule 3: Use descriptive paths
In the old days, URLs were useful. Sophisticated users and web spiders could navigate within a site and understand how content was related by reading and manipulating URLs alone. Then Content Management Systems took over the web from HTML-based sites and killed many of those useful URL paths. Thankfully, Google weighted their search algorithms toward the content and relevance of URLs. To save their SEO, website owners updated their CMSes to create descriptive URLs. Within a few years, the web had switched back to easy-to-read, useful URLs. Think of these paths as sign posts.
We can expect a similar shift on mobile as tools like Apple’s Spotlight search and Google App Indexing (which are now fully integrated via the Branch SDK) begin to use app crawlers to index in-app content. App marketing practices will be forced to adapt to a content-based world. Expect URI schemes to become as important to app SEO and app discovery as descriptive URLs are to website SEO. It’s a good time to get ahead of the curve.
Had problems or revelations while setting up your URI schemes? We’d love to hear your tips and suggestions in the comments.