The A List Apart Blog Presents:

URLs Beyond the Web

Article Continues Below

With the newest versions of the two most popular mobile operating systems, iOS 9 and Android M, third-party native applications will be able to respond to URLs, rather than a web browser, enabling deep-linking into applications. Tapping a link to a tweet will open Twitter’s official application and display it there, if the application is installed, rather than navigating to the tweet in the default browser.

This has some major implications for what we think of as “the web,” and how we build experiences for it. I don’t think “the web” consists only of websites. I see everything we build that is connected via the internet as “the web.” As John Gruber said:

We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors.

The things we build are—and should be—peers, but the shared language of the web, the URL, has not been fulfilling its “universal” promise. And yet, the universality of the web is what makes it one of the greatest technological achievements in human history.

After championing progressive enhancement for so long, we know that not all experiences are the same—nor should they be. I see URL-enabled applications as the next level in the progressive enhancement approach: those with the associated app installed will be sent to the app, since we might reasonably assume that’s their preferred experience, those without the app installed (or without it available on their device altogether) will be sent to the website.

I’ve talked before about not drawing such hard lines between experiences, and about letting operating systems handle the parts they can handle best. Application deep-linking is a great example of both. Another level has been opened up for our progressively-enhanced experiences, and it’s up to us to take advantage of that.

Cool URIs don’t change.” Even cooler ones work everywhere.

16 Reader Comments

  1. Thinking of deep linking as progressive enhancement is an interesting framing, and one that certainly got me thinking about the distinction between native apps and the web, especially as the technologies behind both become increasingly shared.

    I tend to disagree with the notion that we should consider native apps part of the web — even if they can now be linked from it. Your post has pushed me to think of the reasons why I hold this position (so, thank-you).

    We can easily define what constitutes a website: something built using the combination of HTML, HTTP(S) and URLs as a bare minimum. To arrive at a definition of what the web is however, I think you only need look at the names of those underlying technologies and the keyword ‘hyperlink’ (from which we arrive at the ‘web’ metaphor). While apps may be linked from the web, they are not ‘interlinked’. I believe that’s a crucial difference.

    I’m reminded of Ben Ward’s piece from a while back. Although he was talking about web apps, this line still resonates:

    Want to know if your ‘HTML application’ is part of the web? Link me into it. Not just link me to it; link me into it. Not just to the black-box frontpage. Link me to a piece of content. Show me that it can be crawled, show me that we can draw strands of silk between the resources presented in your app. That is the web: The beautiful interconnection of navigable content. If your website locks content away in a container, outside the reach of hyperlinks, you’re not building any kind of ‘web’ app. You’re doing something else.

    Finally, to mention apps and universality in the same breadth seems a little misguided: their native, proprietary, hardware-dependant nature is in direct opposition to what universality actually means in practice.

    Indeed, including native apps within the realm of the what we consider to be the web, risks us making assumptions that are similar to those we already make when using existing web technologies. We assume users will have devices powerful enough to power a 60fps animation. We assume users will have enough bandwidth to download a 16Mb page. Too often we see developers wilfully circumvent or nullify the inherit universal and accessible aspects of the web, and I fear if we start to believe apps are a reasonable progression of it, we’ll see the barriers rise even further. What happens when we assume that users will have an app installed? I can already imagine the HTML fallback: a download link to an app store page. That’s just not good enough.

    Outside of our industry, the distinction between the Internet and the Web has long been ignored. Yet for those of us who deal with these different connected platforms each and every day, we owe it to ourselves to talk honestly about their strengths and weaknesses, capabilities and constraints; I don’t think blurring the lines helps us have those conversations.

  2. I know people who prefer to use mobile browser versions even when an app exists. The reason is simply privacy: many apps want too many privileges on the phone, and the only way to opt out is to not use the app

  3. It’s a bit disingenuous of you to imply that this is a new feature of Android along with iOS. The new functionality in Android here is something deeper, related to signing of links between two apps, without involving the web at all. Android has been able to deep-link into apps from a URL since… before I started using it, years ago.

  4. It was very useful for me. Keep sharing such ideas in the future as well. I am glad to come here! It was very useful for me. Keep sharing such ideas in the future as well. SEO Sri Lanka

  5. Interesting Anthony – in my line of work I’ve always thought of apps as the “alternative” web and a competitor to the traditional URL. Your point of view has made me think again.

  6. I think that its definitely a step in the right direction, but I think that we still have a long way to go. I’ve never personally preferred the app-versions of many websites as they tend to be a bit impersonal. Hopefully with the added emphasis on this feature we’ll see apps that are better designed to integrate with their website counterparts and provide people with better user experiences.

  7. It’s great to come across a blog every once in a while that isn’t the same out of date rehashed material. Fantastic read! I’ve saved your site and I’m adding your RSS feeds to my website.

  8. Nice article Anthony. Mobile applications with web links are pretty common and it is a good reformation that an app can open a third party app in the relevant application. However this does not replace web browsers entirely and native applications that opens a link in web browser are still dominating. Know the difference between mobile app development methods at

  9. Totally agree. I like the fact that you have touched on the point where companies see more interaction between native apps and websites. It will be interesting to see how closely they interact in years to come and what device vendors will come up with next.

  10. Password managers use the URL to determine which account to use, so I’d certainly want it available for browser plugins / share type things, as well as the user. How about showing/copying the URL when long-pressing the top bar? (On iOS a tap of that scrolls to the top of the page, I don’t think it is used on Android?)

  11. Nice article Anthony, Massago App Toronto, We work exclusively with qualified RMTs in good standing with the College of Massage Therapists of Ontario (CMTO). We also ensure that Massago RMTs are experienced and reflect the highest standards in the industry. Plus, we like to work with really nice people.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA