Mobile App Linking

Published on 14 May 2014 at 9:31 pm.
Filed under Mobile.

Mobile app linking is complex in its current form. A new initiative has emerged to simplify things.

Mobile users like to spend time in apps. Many apps link to websites that may too have apps. In an ideal world the app the second app would load to show users the linked content instead of the website. Potentially even make the user install the app to view the content if the content creator likes.

But we don’t live in an ideal world. Many apps today do not allow you to link to content within the app. For those that do support this they still need the linking app to detect if the user has installed your app before directing users to the content in your app. It requires a coordinated effort between both players. This is complex and adds bloat to the install size of any app that links to content. This is the problem the new App Links standard is trying to simplify.

App Links is a standard making it simple for supporting apps/sites to link to content inside of apps for Android, iOS, and Windows Phone. Support for other mobile operating systems like BlackBerry and Firefox OS will come in the future. Facebook recently announced that they support App Links in their app today. Right now they only support opening your mobile app and do not yet include App Links in their own site making it easy for your app to open content within the Facebook app. Also, from my testing they do not support App Linking from their own Windows Phone app.

So what do you need to support App Links? Glad you asked.

http://vimeo.com/93018959

Mobile App Linking Step 1: Deep Link Support

Deep Links is a term from the web that carried over to mobile. Deep Linking is simply linking to pages that are not your home page. The basic idea is that you’re linking deep inside to content.

Android, iOS, and Windows Phone allow apps to create their own URL schemes using custom protocols. The protocol for the web is the “http://” part of any URL. These operating systems suggest app developers create custom protocol names that are unlikely to clash with other apps or could be used in the future. This means that if we were to create a mobile app for ourselves than we would likely use “brandbuilderwebsites://’.

Explicit instructions on developing your own protocols in mobile apps is beyond the scope of this article. Please see the documentation for Intents and Intent Filters for Android, Custom URL Schemes for iOS, and URI Associations for Windows Phone.

Mobile App Linking Step 2: App Link Metadata

The App Link Metadata are HTML meta tags that you add to your website. There is one required meta tag for each version of your mobile app. There are two to three optional meta tags for each mobile operating systems. Let me be clear, you do not need to add meta tags for mobile operating systems that you do not have apps.

For the sake of simplicity lets assume that we have a mobile app called “Brand Builder Websites” that uses the URL “brandbuilderwebsites://index/” to load our home page. We will also assume that we have apps for Android, iOS, and Windows Phone. For further simplicity we will assume you only have one app for iOS. If you have separate apps for the iPhone and the iPad include similar instructions for them using “iphone” and “ipad” in place of “ios”.

For basic mobile app linking support we are only required to add the following meta tags:

<meta property="al:ios:url" content="brandbuilderwebsites://index/" />
<meta property="al:android:package" content="com.brandbuilderwebsites" />
<meta property="al:windows_phone:url" content="brandbuilderwebsites://index/" />

Windows Phone and iOS both need you to supply the custom URL to load your app. Android requires the app package name. The package name is basically the id used to load the app from stores like the Google Play Store or the Amazon Appstore.

Optionally, you may add the following:

<meta property="al:ios:app_name" content="Brand Builder Websites" />
<meta property="al:android:app_name" content="Brand Builder Websites" />
<meta property="al:windows_phone:app_name" content="Brand Builder Websites" />

<meta property="al:ios:app_store_id" content="123456" />
<meta property="al:windows_phone:app_id" content="123456-7890-1234567" />

<meta property="al:android:class" content="com.brandbuilderwebsites.MainActivity" />
<meta property="al:android:url" content="brandbuilderwebsites://index/" />

The first three tags supply a name of the app for each mobile operating system. The next two are the id to load the app in the appStore and the Windows Phone Store. The last are for the name of the activity (an Android thing I won’t get into here), and the custom URL to load.

Lastly, there are two other meta tags that you can add.

<meta property="al:web:should_fallback" content="true" />
<meta property="al:web:url" content="http://www.brandbuilderwebsites.com/" />

The first meta tag is useful because it lets you force the user to install your app to get access to this content. If it is false it will direct the user to the relevant app store link. Let me be clear that this only applies to users coming directly from another app. It does not instruct them to install your app if they come from the web.

The second meta tag lets you specify the web address. Truthfully there is no reason to include it on your website. It’s only useful if you have to fall back to using Facebook’s App Link Hosting if you cannot add these meta tags.

That’s all you need to support Mobile App Linking. Just a few lines of HTML on your website and a few changes to your app and you’ve improved the user experience for your customers. Ultimately isn’t what we all want, satisfied customers?

Thank you and keep building your brand.

This post was originally published as Mobile App Linking for Brand Builder Websites.