I have been a fan of Responsive Web Design ever since Ethan Marcotte coined the term in his wonderful A List Apart article. So it was no surprise that the very first initiative I started championing, two days into my new job at NPR in April 2011, was: Responsive redesign of npr.org.

Taking a large media website, with decades worth of content, through a major overhaul was no small deed, however. And the website was far from being my only concern. As the head of software engineering for NPR’s Digital Media, making sure we had sustainable strategy for NPR’s existing suite of native mobile applications was my top priority. Having very limited resources, it was becoming increasingly hard for Digital Media’s tech team to maintain a fleet of native applications across multiple platforms. The obvious question we were getting asked frequently was: did our new commitment to Responsive Web Design mean NPR would abandon native mobile app development and move everything to web apps? It did not.

The question was fair, however. Back then, and ever since, there have been very vocal advocates of the imminent sunset of native mobile development, in our industry. A group of respected developers and designers have been insisting, for years, that native mobile development is a waste and that every application should eventually be built with HTML/CSS/Javascript front-end. Beyond those individual advocates, major tech companies have also entertained the thought: Apple’s first-gen iPhone only supported web apps, Windows 8 Metro UI tried to make “HTML5” apps into first-class citizens of Windows ecosystem, Google has been trying to promote its suite of web apps (among other things: in the Chromebook experiment) for years now.

This is a question every content publisher has asked themselves at some point: is Responsive Web Design (RWD) the [only] answer? Are native mobile apps a relic of the past?

Certainly, there are examples of popular publishers answering this question with a “yes”. And yet, the choice these publishers have made is not a blueprint for the rest of the industry. Responsive Design is not here to kill native applications. Such choice is simply a fallacy.

Blame the Second Law of Thermodynamics if you will, or anything else you prefer, but whether we like it or not, in real life nothing ever has a single answer and applications are not an exception from this rule. Just because web developers find standardising on a single UI technology (HTML5/CSS/Javascript) more efficient, doesn’t make end-users suddenly and magically believe in the same. Whether we like it or not: the reality is that in many contexts:

“the best mobile experiences are native” ~ David Cohn (source: Twitter)

Looking back at the choices we’ve made: NPR had huge success with its Responsive Design initiative, increasing both traffic as well as engagement, but we also very successfully doubled-down on native mobile experiences when it made sense and it was the absolute right thing to do.

Responsive Web Design is not an alternative to native experiences.

It is very important we understand how misleading the ‘choice’ of “RWD or native app” is. It is as wrong as thinking that if you have a native application and a website then your website doesn’t have to be responsive.

The truth is: all websites must be responsive because increasingly people are browing the web on their mobile devices and it is your obligation, as a publisher, to make sure they have the best experience if they visit your website on their smartphone. That said:

A web browser is not the only application on our smartphone, and won’t ever be, so just because you have a responsive website doesn’t mean that you cannot create compelling native experiences as well.

Whether you choose to create these additional experiences is up to you. Some publishers may have decided that they don’t want to push the envelope in that direction, but that just means: others will pick up the opportunity.

Native mobile applications are not going anywhere and the future of all websites is to be responsive. These two assertions are not mutually exclusive, they are complementary – don’t create apps when what you actually need is a website; but also don’t pretend webapps can completely replace native applications, because they can’t.