July 27th, 2015
Deep linking as a technology has become a confusing mess of marketing terms and buzzwords over the last few years. This is primarily due to the lack of a centralized standard and the fragmentation of the mobile landscape. There are so many large technology companies vying for eyeballs on the phone, from Facebook to Google, to Twitter to Microsoft (and that’s just in the US alone!). Every large technology company wants to be the leader in the space, making their protocol the standard.
As developers, this makes our lives a living hell. We depend on all of the various channels (Facebook, Google, Twitter, etc) for organic growth, so we’re forced to adopt whatever they throw in our direction. It means that we have to learn all of the new fangled protocols, implement them, and continue to support them, just so that we can have a sharing menu that looks like this:
Flipboard’s share screen. Every share channel has a different deep linking standard.
When these large tech players enter the space, they are selfishly convinced that they can develop a standard by strong arming their way in. The philosophy is: “Well, everyone has to use [Fill in the big name platform], so let’s just make them use our app linking protocols. We certainly don’t want those other guys to own the standard protocol!” Then, they design some new mechanism so their scraper can determine how to link to your app. At the end of that path, their marketing team comes up with a big announcement which overhypes the functionality, making it confusing and convoluted to anyone trying to use it.
The interesting thing about every one of these deep linking protocols is that they’re all basically the same thing with different labels. They are all just metatags that you have to add to your website in one way or another.
Here, let’s look at a few examples to illustrate the point. Here’s a piece of content on the web:
To turn this IMDB website into a link that supports all platforms, you need to add:
<meta property="al:ios:url" content="imdb://title/tt0117500" />
<meta name="twitter:app:url:iphone" content="imdb://title/tt0117500">
<link rel="alternate" href="imdb://title/tt0117500">
A SSL-signed JSON file on your domain that looks like this:
"apps": [ ],
And the list goes on…
Our team started out by working on an app. We quickly realized that mobile linking was broken and we couldn’t easily get users to the content in our app that we worked so hard to create. So we built a tool for this problem, called it Branch, and pretty soon all of our friends were using it for their own app. It started to spread like wildfire.
Basically, we just tried to build the version of linking that we felt mobile developers needed by eliminating a lot of the complexity we saw in the ecosystem. There were a few key features that we felt were most important when it came to building a link that worked for apps:
First off, we felt that link paths were not a good representation of how developers store data in native mobile apps. A more representative data model would be a dictionary filled with keys and values.
No one wants to write a flexible string parser to cut out the data from a deep link URI path. Branch just returns the deep link data in a nice format when you call a method on their library.
Don’t want to worry about navigation controllers and back button stacks? Neither do we. You can register an Activity or View Controller to be displayed only when deep link data is detected.
You shouldn’t have to build a website with all of these deep link protocol metatags appended to it. Branch gives you a hosted http link, automatically configured to support all standards.
Lastly, you want a clickable link that will redirect to your app when installed and fall back to a mobile site or app store when not. We support every browser on every operating system, ensuring your users are never left hanging.
The bottom line is that Branch takes all the pain out of setting up app links and delivers a link that just works.
As described above, Branch automatically configures every link to work naturally with all of the following standards, so that you don’t have it. From this point on, you never have to worry again if your links are compatible. Use the hyperlinks below to read more on our blog about that particular standard. More guides are on the way!
App Discovery and Mobile Search:
Google App Invites