It seems odd that in 2015 we must address ourselves to the problem of linking resources across a network, but in the version of 2015 we’re lumbered with, we live in an appified world, so address ourselves we must. While linking has formed the backbone of the web since the demise of Compuserve and AOL’s walled gardens in the mid-nineties, the apps that populate our smartphone home screens are about as interlinked as Compuserve’s forums in the early 1990s; which is to say, not very interlinked at all. Nor are they indexed by search engines, so if the information you need is inside an app, it’s invisible in search results.
Each app is an island in a vast archipelago that boasts neither boats nor bridges. But moves are afoot to fix that, and to create a system of links between them. Oh yeah, the ’90s are back, baby.
So, what’s the problem with deep linking apps?
Before we get to efforts to de-silo apps, a quick illustration of why a lack of interconnection is a problem for the user. Let’s say you’re in the Facebook app, and a friend sends you a link to a product listed on Amazon. You want to buy the product; it’s something you’ve been looking for for a while. You have the Amazon app on your phone, with your credit card details, delivery address, and so on, input and ready to use. You click on the Facebook link… and you’re taken to the Amazon website, and asked to log in. Frustration.
So a lack of links is a problem for users. It’s also a problem for business. Discoverability in app stores is a big issue for companies and developers, and it can be hard to point users towards apps that might be relevant to them. Once an app has been downloaded, it can be quickly forgotten—66% of app users only open apps between one and 10 times. Showing users a download prompt for an app when they click on a link, whether in an app or a browser, can help solve the problem of discoverability, though care must be taken so that the implementation doesn’t annoy your users or violate Google’s advice. Jumping users between already installed apps on their phones, through in-app or web links, could solve the problem of engagement drop-off. It could also be a boon for advertisers—a user could be served up with, for example, an ad for a Living Social discount offer within one app; with a tap the Living Social app is launched and the user is taken directly to deal within the app; one more tap and the ad network has a conversion to boast about.
Deep linking and custom URL schemes
Why is it then, that in 2015 deep linking on any platform should be a hot topic? That it is, is arguably all thanks to Apple. When the company created the App Store, it set up a wall between websites and apps: websites run HTML, while apps run native code. And although Apple allowed apps to be referenced via URLs, it insisted on separated URL schemes—so rather than the standard http:// we’re familiar with for websites, apps got custom URL schemes, with scheme names (or protocols) looking, for example, like facebook://.
When Android came along, it too used custom URL schemes to deep link apps; but importantly, it also allowed regular http:// URLs to be used too, meaning that native apps on these platforms did not necessarily need to be cut off from the rest of the web as with iOS apps.
You can see this approach in action right now if you have the Twitter app installed on your Android device. Open up your browser and click on this link: https://twitter.com/mobiForge/status/558355939989143553. Although this is a web link, it can be opened in the Twitter app, so the user is given a choice of apps that can open it: browsers and Twitter in this case. So it’s a deep link into an Android app, using a regular http:// URL. If you don’t have the Twitter app installed it will simply be opened up in the web browser on your device. Try the same thing on your iOS device, with Twitter installed, and you’ll still have that link opened up in a browser.
The user is given a choice of apps which are able to respond to particular web links, in this case http://twitter.com/…
Deep linking apps is a cross-platform problem
The past year or so has seen a flurry of activity around the problem of deep linking apps, with Google, Facebook and Twitter all advancing partial solutions, along with several start-ups, amongst them URX, Quixey, and Branch Metrics. In different ways and to different degrees, these companies have addressed themselves to several problems around app deep linking: creating standards for cross-platform app linking, app indexing, and app-install prompting.
As we saw earlier, deep linking, with web compatibility and fallback is already alive and well in Android-land. So what’s the point of these new app linking solutions? Well, they only make sense when you consider multiple platforms, that is, when you have versions of your app on multiple platforms. If you only have an Android app, then forget these services—you don’t need them for deep linking.
But, even though there appears to be a decent solution out there already on at least one platform, there’s a problem on some platforms, so there’s a problem on all platforms. That is, at least until everybody gets on the same page. And everybody will only be on the same page when a single link can be shared that works across all platforms—just like on that other popular interconnected network thingy everybody’s using.
Where these app linking services are useful is in providing a URL conversion service—basically a URL is converted to the iOS scheme to deep link to iOS apps, or to the Windows scheme on Windows Phone, or the scheme of whatever platform you are trying to link to, so that you can have one link that will work seamlessly across all platforms. Sort of like ‘One Web’, but for apps. Arguably these services are also adding value to some degree with by providing app indexing and install prompting solutions.
So, let’s take a look at some of these services.
Facebook App Links
At Facebook’s F8 conference in April last year, CEO and co-founder of Facebook-owned Parse, Ilya Sukhar, announced the launch of AppLinks.org, a new initiative aimed at making deep linking between native apps easier for developers. On their developers blog, Facebook explains: ‘If your app has web content, people will be redirected to a web view of that content. If your app is installed there may be an open button that launches your iOS app. if your app isn’t installed, there will be an install option to direct people to your app’s App Store page. If your app is mobile-only (no web content) then tapping the shared link will either direct people to your app (if it’s installed) or to your app’s App Store page (if your app isn’t installed).’ Implementing App Links involves adding App Link meta tags to the web content associated with an app; for apps without a corresponding website Facebook offers a Mobile Hosting API, and implementing the App links API within the app.
How Facebook App Links works (Source: App Links documentation)
Facebook has partnered with a range of third-party services, amongst them Pinterest, Spotify, Hulu, Dropbox and Goodreads; this means that if you have those apps installed and click a link on Facebook, you’ll be taken right to the app, rather than the website. If you don’t have those apps installed, you’ll be asked if you want to.
Beyond this, App Links is intended to be cross-platform compatible, and an open standard that’s not bound to any particular platform. It’s open source, and its reference SDKs mean that developers can implement them without going through Facebook.
As yet, however, App Links is far from any kind of ubiquitous standard. If you click on a Pinterest link within the Facebook app, it will launch the Pinterest app for you. Great. But let’s say you’re on Twitter, and click on a Pinterest link—you’ll be taken to the Pinterest website, because Twitter doesn’t support App Links yet.
The same goes for Google and Apple, meaning that if your app only has App Links enabled, then deep links aren’t available directly from Google search or iMessage.
Twitter App Cards
Twitter has its own solution: App Cards. App Cards allow for both app install prompting and deep linking to content within an app. They won’t, however, be of much use if you don’t have a website to add the markup to—unlike Facebook, Twitter doesn’t have a service to host the data you’re marking up.
App Cards are a little bit like App Links, but without being able to bake it fully into your own apps. Twitter’s solution doesn’t solve the problem of app-to-app linking—while it will link to content deep within apps from links on Twitter, App Cards isn’t really an attempt to solve the problem of building bridges in our app archipelago.
Google’s App Indexing API
Google’s App Indexing initiative is similarly limited—it allows Google to index apps (only Android apps, at that) just like websites, meaning that deep links to those apps appear in search results. Google has a solution for those apps that don’t have a corresponding web presence in the form of the App Indexing API, but with its focus on Google search, App Indexing is again far from a universal solution to the problem of linking apps to each other and to the web.
However, combining the App Indexing API with Android’s http-URL based deep linking delivers something of a satisfactory solution.
URX
Start-up URX is hoping to integrate the big three above, using something it calls omnilinks. Prefix any link with urx.io/, and it becomes an omnilink. No matter where the referring link originates—Facebook, Twitter, Google, mail, another app—the omnilink will route the user into the app if they have it installed, and the website, or app-install prompt, if they do not. For omnilinks to work, developers will need to register per-platform URLs for their app, and have the meta tags from Google, Facebook, Twitter or URX on their website. For how to do this, see here. To enable deep links, see here.
Quixey
Another start-up, Quixey, has taken a different approach, and is focused on indexing app content to make it searchable. At present, Quixey is an Android app that will perform two functions: semantic search in the app store (‘Is there an app that’ll recommend nearby restaurants?’), and search on your phone. For the latter function, Quixey will look through everything on your phone, including third-party apps, and return actionable results—if you search for a song, for example, it will return an option to stream the song on Spotify if you have that app installed.
The company is also behind the AppURL deep linking standard that helps developers map http URLs to pages within apps, which functions somewhat similarly to URX. But, although they provide an http to custom URL translation service, they state that “AppURL isn’t really about transforming http URLs into custom schemes. AppURL is about standardising http as the all-platform URL scheme, thereby broadening the addressable web to include apps.” As mentioned earlier, this is something Android already does out of the box.
Branch Metrics
Branch Metrics offers another single-link-for-all-platforms solution with its Contextual Deep Links product. This product offers a link transformation service similar to AppURL and URX, but allows arbitrary data to be sent with the transformed link, so that an app can be personalised with the data sent along with the link.
Deeplink.me
Deeplink is yet another single link solution, offering a URL transformation service, and provides deep linking without the need for an SDK, and with click analytics to boot. Deeplink.me is free for the first 30k clicks per month and costs up to $0.0002 per click after that.
Standardisation and the way forward
So, with all these different approaches, it would seem the time is ripe for standardisation. And there are indeed informal talks about the possibility of standardising a system of inter-app linking at the W3C Mobile Interest Group, albeit it as a somewhat reactive response to an already taking-shape app-linking landscape. Should one technique become widely adopted then the W3C work might be simply to rubber-stamp that approach. You can follow the public discussions here. But talks are at an early stage, and might not turn into anything, so don’t hold your breath.
Not to mention, of course, even in the event of a standard being developed, it would require all the major mobile OS providers to be onboard to be truly useful. This brings us back to the nub of the problem. There is already something of a solution on Android. On Android, via the Intents API, an app can register itself with the OS to respond to any URL, even http ones. It seems that this is the simplest approach with the fewest moving parts, and being compatible with the web right out of the box makes it quite attractive.
Final thoughts
This is a lot to take in, and it all seems unnecessarily complex for something like linking resources in a network, something the web got right back in the ’90s. Facebook App Links are unlikely to become widely used because the barrier to entry is too high. Twitter App Cards don’t fully solve the problem. URX, AppURLs, and BranchMetrics’ Contextual Deep Links all have a lower barrier-to-entry than App Links, but have a dependency on a third-party server to resolve the links.
It seems like Google got it right with Android at the beginning: using http URLs to reference apps, which automatically falls back to web. Just add some meta tags to your web page, and you get some extra goodies! Perhaps the simplest solution to cross-platform and web compatible deep linking would be if the nice folk over at Cupertino relaxed their custom URL restriction and allowed apps to register themselves as able to respond to regular http URLs. Then, apart for the value-add that these services offer, such as app indexing, then there’d be no need to implement these workarounds. Just register a URL for your app, optionally add a meta tag to a corresponding website to help indexing, and bam! we’re done. And we can all move onto a different problem. But until then, workarounds are where we’re at.
Update 23-01-15: Added reference to deeplink.me
Leave a Reply