Bridging the web-native gap

The line between websites and apps is becoming blurrier every day. What with entire operating systems being made with HTML5, and the recent influx of native adblockers on mobile platforms, there’s all kinds of cross-pollination that is absolutely good for the industry and good for the web in general.

Despite this, there’s still quite a gap between native apps and the web. One glaring example that Twitter users have had to deal with for nearly three years: Instagram’s decision to remove photo previews from tweets. This political decision has caused a truly horrible user experience for all of us.

Little refined sugar free vegan fruity tarts for a Sunday. ❤️ https://t.co/Qw5lzGEA5e

— fearne cotton (@Fearnecotton) September 20, 2015

Yeah, nobody’s going to click that Instagram link. Not only is the preview missing, but this link will open up in your phone’s browser instead of the Instagram app. Even though you may be logged in to the Instagram app on your phone, you’ll likely have to log in again through the browser.

So let’s recap. If you want to fav an Instagram photo you found on Twitter, just follow these simple steps:

1. Click an obscure photo link that has no preview
2. Get directed to your browser, which is probably a second-rate experience compared to the native app you already have
3. Log in with the browser, even though you’re already logged in on your app
4. Get redirected to your home page feed. Now you’ve lost the photo you wanted to see.
5. Switch back to the Twitter app
6. Follow the same link you already clicked in step 1
7. Double-tap to fav

Here’s our problem: the browser doesn’t know your apps exist. Your apps don’t know that other apps exist. Your default browser gobbles up every link that comes across its path and the experience is terrible.

A better vision

This week, I’ve been musing about what a standards-based, backwards-compatible way to bridge the web-native gap. The more I thought about it, the more simple the solution seemed. We have the necessary tools at our disposal, but nobody seems to be using them to solve this problem.

There some truly mind-boggling proprietary URL schemes and workarounds out there. Relying on a new URL format or third-party app are not long-term solutions. These over-complicate the problem and drive a wedge further between the web and native.

What if all links to facebook.com were opened by your Facebook app by default? Any link to twitter.com would get intercepted by your Twitter client instead of opening in the browser. Same deal with Instagram.

This concept could be expended further. Let’s say you’re browsing Project Gutenberg to find a sweet ebook to read. You have an ereader app that listens for .epub links, and adds them to your library with one click. This saves you the steps of downloading the file, opening the app, and importing it manually.

Sounds nice. How do we get there?

The chokepoint here is the operating system itself. Right now, you can download alternative browsers and set them as your default. We need OSes to mash-up this functionality with a little regex and let any app be the “default browser” for certain kinds of links.

This preserves backwards-compatibility by opening links in the default browser if the user doesn’t have the app, or if they’re browsing on some other kind of device that doesn’t have apps. It’s the best of both worlds.

I’m not sure what the next step is: petition the smartphone OS makers? Build support in the developer community? Rally users on a per-app basis?

This solution really has benefits for all three groups of people. OS makers can save the time and energy they’re wasting on duplication of the HTTP protocol — no need to reinvent the wheel. Developers can offer deep integration with the web while offering first-rate native user experience. Users don’t have to feel shuffled around like sheep and get a smoother user experience.

Let’s talk about this. What do you think?

Update (1 Nov 2015): It looks like the newest versions of iOS and Android will support app-to-app links, also called deep linking. This is a good step forward, but unfortunately could also mean a step back. Both OSes will require apps to prove they own the URL, thereby crippling functionality for third-party clients and limiting the creative potential of the native mobile experience.

Sam Nabi