I haven't previously weighed in on the native apps versus web debate. In fact, I feel that the debate is largely over. It's not that either has won, but rather that we are using each for its strengths. Today, though, I believe I've gained new clarity on the functional delineation between native and web, and what the web needs in order to achieve "native-like" experiences.

The Strength of Ubiquity

The Web has a great advantage: it's everywhere. Building for the web is to embrace fragmented clients and, in response, progressive enhancement. The fundamental function for the web is universal access. Once you start trading access for animations, access for modularity and encapsulation, or access for client-side functionality, you're trading away the biggest strength the web offers. If you build a native app, you know that only those on your target platform will have access. And that's okay, you've made that tradeoff decision up front. There seems to be a common idea (or maybe it's just loud) in the web community that we can treat the JavaScript-enabled browser as a platform and build something native-like that hits anything that has a browser. Well, anything that has a modern, JavaScript-enabled browser. And by "modern," we mean "meets all the requirements for my framework."

The Problem of Web as Platform

I don't have a fundamental problem with building for target audiences that are smaller than "anyone with a web browser." I do think that trying to achieve larger reach by publishing to the web and then limiting that reach by requiring a certain level of browser functionality is confusing, but that's not the real problem. The real problem is that we know so little about the environment in which our product will be used. Right now, today, we cannot reliably implement gestures in websites. The risk for colliding with native gestures in the mobile browser is just too great. The Web, and web apps by extension, exist as an app inside an app. The browser is not an OS, it's an app: it has its own gestures, interface, and controls. And our websites exist inside of them. It's not just a needed-functionality problem; it's a UI problem. Are we placing our UI controls right next to the browser controls? Are our gestural power-features conflicting with the browser's gestures? Building for the web requires a certain amount of letting go, a level of agnosticism towards platform and environment. We cannot treat the browser (or webview) as a clean environment; it has its own opinions.

"Native-Like": A Brief Sidebar

I've come to believe that web apps will never truly rival native apps, for a single, simple reason: user interface conventions. iOS and Android have conflicting UI conventions. Take tab bars as an example: iOS guides you to put them at the bottom of the view, within easy access of the user's thumb; Android guides you to put them at the top, so as to not conflict with the ever-present Back, Home, and Recents OS/hardware controls. When we first began building sites for mobile after the iPhone, the web, at mobile sizes, was designed to look like iOS. Now, though, mobile web design has largely embraced the same conclusion that we reached on the desktop: the website can contain its own design conventions and shouldn't mimic the OS. This is a good place to be. Web apps shouldn't attempt OS-level cohesiveness.

What We Need for True "Web Apps"

To truly achieve a native-like experience with web technologies, we need an opinion-less environment, and we need to know when our web app is being run in such an environment versus a browser or another app's webview. This may be met by the HTML5 Web Application Manifest, or something similar, I don't know. I do know that it's not being met currently. If we know that our website is being run as such, we can make assumptions about our environment and treat our session as a native app that happens to be built with web technologies, otherwise we can default to an ubiquitous, environment-agnostic site. And there's a lot of power in ubiquitous, environment-agnostic sites.

A Plan From Here

My current strategy doesn't change. Build for the web because of its reach. Build for the web for everyone. Build for the web first; it's reach is too large to ignore. Build for native for what native can provide: hardware access, gesture support, and an experience coherent with the OS. Perhaps soon we'll be able to take advantage of more and more of these native functionalities with web technologies that run as first-class apps. But we're not there yet.