Native vs. Web Apps

Debates over Android-vs-iPhone are so regular in the tech industry these days that I found it refreshing to have a discussion on Twitter with Remy Sharp and John Allsopp about native versus web apps (again). The argument by Remy and John was that most apps can be made using web technologies and would benefit from platform agnosticism and far greater reach than those sold on an AppStore (on only one platform per development effort). My argument is that this is simply not yet the case. I’m going to explain why, but first, a little dispelling on definitions.

In a Web Directions blog post from last October, John seems very much dismayed at the notion that native apps are “inherently better” than web apps, simply because they’re native. I think John is looking at it all wrong, and is letting himself get frustrated by claims in this realm for the wrong reasons.

I posit that the quality of an application is determined by three factors, in order of significance:

  1. The quality of the work done by the developer;
  2. The quality of the environment in which the application is used;
  3. The quality of the tools at their disposal

It’s illogical to suggest that #2 and #3 are irrelevant, but I’ll address all of them, in reverse order.

The quality of the tools

Better tools are no guarantee for better results, but worse tools objectively limit you in what you can feasibly accomplish with them. Don’t forget that in the case of application development, one aspect remains constant: the time and money investment you can make to build it. This means that worse tools, which require more effort, thus more time, thus more money, will negatively affect the overall quality of the end result compared to something made with better tools.

This is an objective truth that has nothing to do with however talented the development team is. But more on that later.

The quality of the environment

This factor matters quite a lot. For native apps, the environment equation is something like this:

Hardware + Operating System + OS version + API level

For web apps, it’s slightly compounded but otherwise very similar:

Hardware + Operating System + OS version + Browser + Browser version + Web API level

I initially omitted OS and OS version from the web app equation, but that would have been a mistake because, especially on mobile, some browsers rely on a web framework that is installed on the OS level, and only gets updated when the OS gets updated.

The first lesson here is obvious: web apps have a more extensive equation, meaning there are more possible permutations to deal with—especially since good web developers eschew dropping support altogether for users of older browsers and favor using practices such as Progressive Enhancement. This in contrast to native platforms (especially on mobile), where it’s quite common to simply require the end user be on at least OS version n or later, and anyone who isn’t simply won’t get the app. For web apps, that means the development effort is already spread thinner across a larger number of environments to support, and since we have a constant of X time and Y money to spend on this, this factor is detrimental to the quality of web apps.

But if you think these equations are statistically equal, you’d be wrong. Web APIs are inferior to native OS APIs because there are far fewer of them so far, and many of the ones that bring web APIs up to the level of native APIs are so brand new that they are 1) comparatively poorly implemented, poorly supported and poorly documented, and 2) only available in the latest, often unstable development versions of browsers. If you look very simply at market shares, an apples-to-apples comparison between web browsers and Android OS version (chosen because Apple doesn’t make iOS version breakdown statistics available) tells us that Android 2.1 is roughly equivalent to IE8.0. Internet Explorer 8.0.

I could compile a list of all the cool new things we’re seeing in HTML5 and CSS3, and then cross out every single one of them because IE8 supports exactly zero of these latest-and-greatest cutting edge features. To suggest that IE8 can match up against Android 2.1 in terms of features and device capabilities is absolutely ridiculous. Especially if you consider performance.

Android 2.3, the latest version for smartphones, has an internal share of 0.8% (of all Android users), which is roughly akin to Chrome 10. But Chrome 10 doesn’t have all of the same device and API capabilities as Android 2.3, and even that’s for Chrome 10 on the desktop. The Android version of Chrome lags behind in quite a few things, making this comparison reveal the same disparity between native APIs and Web APIs.

For another example, read what Aditya Bansod of Sencha wrote, on the Motorola Xoom/Android 3.0 Honeycomb’s browser:

We were excited about the first true Android operating system for tablets and had high hopes for a mobile browser that was as powerful as the platform. Sadly, the Xoom and Honeycomb are a real disappointment. We found consistent and reproducible issues in CSS3 Animations and CSS3 Transitions among other things. We had issues where the browser either hung or crashed. Regular scrolling was slow or below full framerate. We had issues where media playback failed or performed incorrectly. At times it felt like we were using a preproduction device, but we bought our test device from a Verizon Wireless store.

And beyond the HTML5 features, there were many more mundane web rendering issues: form element borders disappearing unpredictably at various zoom resolutions, CSS border radii with flattened edges, the accelerometer object being upside-down, the virtual keyboard causing layout bugs etc.

Whilst no platform or environment is ever bug free of course, we don’t see iOS or Android app developers suffer from such problems with the very latest public releases of their respective target OS. This makes the Android 3.0 browser feel very immature as an environment, whereas Android 3.0 itself, like iOS 4, feels robust, mature and reliable.

Bringing this all together, what it means is that for a developer, the API level equation skews heavily in favor of native apps. Native APIs are more mature, more stable, more powerful, more plentiful, and more widely available compared to their apples-to-apples-compared web equivalents. There’s a huge gap between the two right now; this gap is being closed by the browser vendors, but to suggest it is negligible or not even there is simply wrong.

The quality of the developer

A highly talented team can legitimately make a better app with worse tools and for a worse environment, than a less-talented team using better tools and for a better environment. This is why #1 is the most important factor, but as explained above, to discount the relevance of #2 and #3 is both illogical and simply incorrect.

Now, John and Remy are both incredibly talented and hard-working developers. They also work with very talented designers and know their tools of the trade better than most. But unless either of them cares to back up their claims with a factual example in the form of an Angry Birds (or whatever) done completely in the browser, all the evidence we have suggests that no matter your talents as a web development team, native apps have a leg up on whatever you create.

I’m not suggesting that people “should thus” go and abandon the web in favor of native apps. I think both platforms have their strengths and weaknesses, and among mobile native platforms there are a lot of differentiating factors as well. What I’m sayig is that the things that make native apps better now is that their tools and environments are much more capable and mature now. The CocoaTouch frameworks that Apple makes available as part of its iOS SDK are vastly superior to anything we’ve seen for the Web so far. This is not conjecture or opinion: you can do a lot of things with CocoaTouch that you cannot do, period, with web frameworks, and a good Objective-C developer can almost certainly make something perform a lot better whilst looking nicer than a comparatively good web developer.

In conclusion

What all of this speaks to is really this: because we deal with a vastly greater amount of legacy environments on the Web, whilst at the same time running as fast as we can to catch up to 25+ years of maturity on native OS platforms, web apps made within the same amount of time by an equally talented team of people will be less great than a native equivalent. That’s not an inherent truth, however, because it won’t always be true. It is merely a truth of the moment. That’s the reality of today. In a number of years, be it 2, 5 or 10, it will no longer be true.

I’m comfortable with that reality. I accept it, and still I personally choose to stick to doing things on the Web, abandoning (perchance temporarily, perchance not) my plans of getting into iOS development. But I won’t fool myself or anyone into thinking that I (or you) can do with web technologies what amazing things we see being done with native apps. Not just yet, anyway, and that’s okay with me. The Web has different strengths.

For instance, here’s one of the Web’s strengths that makes me personally love it more as a platform: I can publish content to it in ways that make the content rich and wonderful for users with modern hardware & browsers, whilst still being fully accessible to anyone using technology going back to the ’90s. They won’t get the same experience, but I’m at least not denying them access.

I love making web applications and tools for the web, and I love working with great content for the Web. But most people are nothing like me, and people who want to build a great application with a certain set of features in mind can get better results with native technologies right now than they can with web technologies. That’s a sour consolation for people who are already skilled and familiar with the tools of the web and are hoping to use those skills, instead of starting from scratch learning new tools and languages, but that’s simply a piece of the greater equation: do you want to make the best conceivable application with a fantastic user experience, or do you want to limit yourself only to the tools you already know?

Right now, my argument is that as a web developer, you cannot have both.

If you liked this, you should follow me on Twitter!