Web versus native rant, late 2013 edition

iTunes App Store has nearly 1 million mobile application titles. Google Play store has over half that. Huge numbers by any measure. Still, there were probably as many or more dinosaurs walking the earth around 65 million years B.C. ― and then there were none.

What I’m getting at is simple: native mobile apps will sooner or later go the way of the Triceratops. And the comet that will extinguish them is called the web.

We’ve seen this play out again: from the tons of disparate OSes and platforms of the wild 80’s, we saw DOS and then Windows take the vast majority of the application market, not because they were necessarily the best, but because they offered a good enough, ubiquitous platform, that was also cheaper to target.

Desktop OSes are already more or less obsolete for most people. If you exclude professional software and some power user and enterprisy stuff, Windows, OS X or desktop Linux are nowadays mainly used for working through the browser.

On smartphones, a less mature platform, things are a little different, with native apps winning the day. And yet, I posit, this reign of the native app is due to smartphones immaturity as platforms, and will sooner or later come to an end as inefficient, just like it did on the desktop side (with the exception of a few apps that really need the extra performance or access to the “metal”).

It’s probably not an argument you hear for the first time. And yet, a lot of people in the industry are not convinced. Here’s why I am:

It’s a matter of cost

Web based apps are just less expensive. Costly iOS and Android programmers can be replaced with cheaper (and far more plenty) web programmers. And not just any web programmers; for the same going rate as a native mobile programmer you can hire seasoned web professionals, each of which will cover not just one but all your target platforms.

Of course a web app that behaves well across platforms needs a lot of work and attention to detail. But 3 or 4 native ports for each platform need even more ― in addition to fighting with the native SDKs (or being at the mercy of some third party cross platform framework).

With a web app, you get to build your application’s prototype low cost, and then you get to keep it, polish it and ship it. And, if you publish your web app as a real web offering, and not on a native app container, you even avoid paying the 30% tax to the smartphone OS vendor.

It’s a matter of maturity

It’s not like we’re in early 00’s anymore, just starting to experiment with this new-fangled AJAX thing. The web stack is already incredibly rich and is getting more mature by the minute.

In the span of a decade, browsers gained crazy fast Javascript JIT compilers, accelerated 2D and 3D support (with vector graphics thrown in for good measure), and an ever expanding arsenal of CSS capabilities. And they continue to move forward, with stuff as JS subsets offering near native performance like (asm.js), real-time audio/video communication (WebRTC), and a stable audio API.

Such maturity means that most mobile applications that needed a native implementation before, can now be made in HTML5. In fact, a lot of them are already made in HTML5, and it’s not even like the end user can tell. Some of them are hybrid apps, taking advantage of web views plus native code, or platforms such as Appcelerator and PhoneGap.

Consider gaming, the classic example of an application genre that can benefit from high performance native code. While AAA titles like Infinite Blade and Real Racing continue to leverage native code to get every last ounce of performance out of mobile phones, the availability of hardware accelerated 2D/3D canvases and tons of mature game frameworks mean that most mobile games are nowadays built with web technologies.

Of course, most application domains are not even that demanding. Business apps, social networking apps, productivity apps, etc, can be created in HTML5. And they, all the more often, they are. Not as some kind of second rate offerings, but as full blown, meticulously crafted apps, such as Wunderlist or Google’s hybrid offerings.

For some things, web technologies are not just mature enough — they are clearly better than native. I know it from experience.

Teams I’ve worked with have created apps such as TalentLMS (a mobile-optimized SaaS e-learning platform) or DynaRoute (a dynamic platform for tourism based on cutting edge services/devices integration research) that are available across platforms and devices while at the same time providing easy expandability. I’ve seen similar projects in the nineties, and those kind of apps would have taken huge teams and thousands of man years to create without leveraging web technologies. Heck, just compare the complexity and learning curve of something like CORBA to the modern web equivalents.

It’s a matter of reach

Web applications help you reach all major mobile platforms quickly and with the same codebase (including UI code). Now, that can also be achieved by some cross platform frameworks like Xamarin’s C# based offerings. But web apps go beyond that, in letting you target the web. (Duh!)

And that is a big plus.

For one, because there are still those multi-billion home and enterprise users, with their laptops (and even desktops, if you believe it). In front of which they sit and work for hours every day.

Second, because the “web” means ubiquity. Without you even having to try that hard. Your app on Linux? The web has you covered. Windows Phone? The web has you covered. Future “smart TVs”? I bet you they’ll be running a web browser.

It’s a matter of (still more) time

Even though web based apps will trump native mobile apps in the not too distant future, unfortunately we’re not quite there yet.

While web based apps have better reach, are cheaper to make and offer more than acceptable performance, there are two major stumbling blocks on their way to feature parity with native apps (mobile or not).

The first problem is are platform restrictions which result in crippled or no access to various device functions (from lack of accelerated WebGL on an iPhone to difficulties in accessing the filesystem on a web browser).

Some of those restrictions are arbitrary, others stem security concerns and a few are meant to give the official native SDK a competitive advantage. All of them will have to be overcome for web applications to reach their full potential.

The second problem is perhaps more difficult to tackle. It has to do with the difficulty of monetisation of web based apps versus mobile apps. Part of it is cultural: people are not used to pay for stuff on the web, be it best of breed email access (like Gmail) or casual games. But the lack of a simple, familiar and secure system for paying also doesn’t help.

One can knock down iOS all day for being a walled garden kind of experience, but they have hundreds of millions of credit card accounts and a very easy process for buying an application. The same can’t be said for the web proper (or even Android, which followed a more open model, plagued with rampant piracy and users reluctance to pay for apps).

In order for web apps to thrive we need a user friendly way to handle payments (and micro-payments). Marketplaces such as Google Play help with that, but they don’t yet cover all the relevant payment models, or have enough reach. And speaking of reach, US only payment systems, such as Google Wallet or Amazon Payments will always be inadequate for the needs of a global app market. It’s 2013 already: if Apple and Paypal have worked these things out, so can others.

TL;DR;

If you’re an enterpreneur or a software shop thinking of bringing your idea to the market, don’t get so caught up on this “native” thing. Chances are you don’t need it to succeed, and you probably can’t afford it anyway. Having a quality app and being first to market with a smaller budget trumps any native purism.

After all, we’ve seen this story play out before.


Dimitris Tsingos
http://www.linkedin.com/in/tsigos

Be Sociable, Share!

Comments are closed.