Will native mobile apps business become HTML5’s next victim?

Seems like the world is pushed towards HTML5. Apple has been amongst those trying so hard to get Web developers out of the Flash domination, and judging by the latest news of Adobe becoming HTML5-religious Apple’s anti-Flash campaign was successful. Becoming stronger and better polished HTML5 looks to supplant not only Flash but also press back such mobile giants as Apple, Google and Windows.

Recently the popular prediction has become that HTML5 will kill mobile apps business. The logic is simple: better HTML5 => higher quality developer’s tools release => better Web apps => improved Web-browsing experience on mobile devices. All these make the native applications position pretty unsteady. So will it necessarily lead to the twilight of native mobile apps development? At first glance – all point to this supposition. Still let’s take a deeper dig.

1. All the look and feel.
Native apps are intended to look glossier and perform better than their browser-based counterparts. As they are developed separately for each mobile platform and therefore use advantage of being OS customized and smartphones’ hardware features advanced. But will native apps preserve this advantage for a long time? Sounds doubtful…due to several reasons.

First, because to the growing variety of mobile platforms and their sub/versions. Recently developers have to spend more and more efforts on versioning and support and this is indeed exhausting and expensive. So perhaps the biggest potential benefit of HTML5 is that it will enable app developers to focus on making one version of each app running smoothly in many kinds of browsers, thus freeing them to move on to bringing more and better apps to market. And that’s definitely good, especially keeping in mind that a well-designed Web app can be indistinguishable from a native application for the user, but not ideal in this terms as still HTML5 browser apps run differently from browser to browser and from device to device making it quite difficult for developers to ensure that all mobile consumers will enjoy the way an app works in their setup.

Another point of concern so far has been that, despite all HTML5 improvements, in real-life use cases native apps still run better, faster and more predictably than browser apps. It’s natural because mostly native apps run from the phone’s memory and rely less on the network. But that’s surmountable with time – with the advent of 4G networks users will be able to retrieve content from the network far faster and more reliably than in the past.

2. Visibility and promotion.
After creating a quality application your next step will be to make it visible and popular longest possible. Native apps published in an app store may receive very little notice as app stores have grown and become bloated with shoddy or useless apps and thus accessing apps has become more of a hassle. The main issue is poor organizing and categorizing that results in difficulties to find a proper app for user’s need even if it exists in the store. Still poor cataloging of apps at big app stores could be smoothed over by specialized app stores.

Browser-based mobile apps spare developers app stores addiction and lend themselves better to Web promotion via social media like Twitter and Google+. Still even if it seems easier at first glance isn’t it still a challenge in terms of making visibility better and longer but not seen for a fleeting moment? For those creating Web apps, there’s just no good way and even a good review of a Web app on a popular site has only a temporary impact.

The way to get your app in front of potential customers is to get it featured in an app store. And this is gained by building an app that highlights unique hardware capabilities, exactly the features the hardware company use to sell the product. [These will likely be features that you can’t access today or in the foreseeable future with a Web app. This isn’t because HTML5 won’t advance, but because the device and OS manufacturers will always do their best to keep their products somewhat ahead of the lower-common-denominator Web platform. It is how they sell products.] That’s business-justified. So HTML5 is good for many apps, enterprise and customer ones, but not for the core features or the main UI.

Basically relying on HTML5 to quickly get to broad compatibility across the mobile landscape could become a trap if you follow selective strategy in your product distribution and want to have the app perceived distinguishing. For instance, you might want to build apps that only work on the latest and greatest version of a phone, and intentionally not on previous models. Then fewer people will be able to use it but those with the newest toys. [The more your app makes the hot new hardware look good, the more it’ll get promoted by the hardware or OS manufacturer. That can give your app presence it could not otherwise get. Once your product is succeeding on the brand-new hardware, you can start adapting it to other platforms.] Doesn’t this strategy distributed strategy look the most attractive?

3. Distribution and revenue generating.
As you may predict here we will mostly speak of Apple and its revenue-sharing mechanisms that has been receiving so many claims. Apple takes a 30% cut of all app sales through its store – the only way for consumers to get apps. That’s much compared to an option to build a web app and putting the whole revenue in your own pocket. This is especially unfavorable for applications with subscriptions as surprisingly this 30% cut doesn’t just cover buying apps in the store, it also applies to in-app purchases including subscriptions that may remove all the profit. That’s why for instance you can already download HTML5 Financial Times 🙂

So many counterpoints but should there finally be an either/or decision? The truth is somewhere in between. And we believe for the majority there may be a place for both kinds of apps. Just an example – you can create a browser-based “lite” version of your app so that prospective buyers can try it out without having to visit an app store; and further if they like the game, they might decide to buy the full version as a native app.

Moreover, developers build many native apps in much the same way that they build browser apps, using the same tools, but then fit them with a native app “wrapper.” For this reason, native apps and browser apps sometimes aren’t as different as people may imagine.

And what do you think?
In your particular case what have you decided or are going to opt for?