Native Apps vs WebApps - Horses for Courses

Over the last couple of years there has been a lot of spurious argument about the merits of native applications versus browser based web applications. The reality is that there are pros and cons of both approaches and the application context and business criteria should be the guide to which to select rather than rather meaningless generic arguments.

Too many times the webapp has been regarded as a poor relation of the native application. In truth, there are strengths and weaknesses of both approaches and a mature evaluation of them can lead to appreciable advantages in both development and deployment. Here are some points to consider.

Development Cost

To adequately cover a diverse user population, it is obviously necessary to write any client side native code at least twice, once for iOS and once for Android. Assuming that some level of desktop support is also required, at least one more implementation can be added, and with the recent entry of serious offerings from Microsoft and Blackberry, the situation is further complicated. It may be that neither of the two 'new' offerings makes much headway, but for the next couple of years, I think it can be reasonably assumed that between them they will make at least 10% of the user population. So, for native app development, one can either opt for a crushing multiplication of client development cost, or loosing at least 10% of the client market.

At this point, I hear a voice from the back of the room mentioning platform agnostic development systems, like , , , to name a few, and it's true that considerable advances have been made in this approach.

There are a few points to be made about such systems. The first is that of the 'arms race'. Each mobile platform manufacturer is in a continuous and bitter war to create new USP's for each release of their platform, and this results in the the developers of bridging products also being continuously in a state of catch up, with the concomitant implications this has for product stability.

The ease of development with such systems can also be greatly overstated. When they work, they work, when they don't, there is yet another proprietary layer of code to debug.

Monitoring the support groups of such offerings, as I do, it's notable how often developers spend a lot of time working out how to work round the restrictions and assumptions of these systems.

Finally, I'd make an appeal to history. Over the years, with each round of new technology platforms (networks, GUI's, you name it), there have been products that claim to paper over the difference between competing systems. For example, MS Windows and OSX would be a recent case in point. It's painfully obvious that none of these solutions has ever won widespread acceptance, and I suspect that this will remain the case.

On the flip side of all this, HTML5 compliance continues to converge on just about all platforms, even ones that are not generally included in this kind of evaluation, such as TV's. This means that single source code for the client side is much more of a real possibility.

App Stores - noisy bazaars

While the marketing platforms of app store's provide are frequently cited as a strong argument in favour of the creation of native applications, the reality is rather different. The amount of external market effort required to get any traction for a application is usually grossly underestimated, and this is because of the sheer volume of app releases. In truth, the app stores are just great for the platform manufacturers, (look at Apple's trumpeting of the number of apps for iPad), but the number of applications in the stores means that pitifully few will ever return the investment that was required to create them. Apart from games and other entertainment apps, the most successful offering in terms of revenue are those that are associated with subscription based services. Because such applications are very often free, the transactional platform provided by the stores is not needed. Equally, the marketing for such products is usually not focussed on the app store so much as traditional channels.

In the meantime, the acceptance criteria imposed by the stores (especially Apple's) mean that product offerings are frequently constrained by Apple policy, and even where they are not, the vetting procedure can add agonising delays to product updates. None of these points apply to web applications.

Access to Hardware

Here is one area where the native app has an unequivocal advantage. If your application absolutely needs access to say, the acceleometer or compass, there is really no alternative to creating a native application. That being said, there is some progress on this front, for example Google Chrome Mobile now provides camera access to web applications, but this is far from ubiquitous.

Native Look & Feel, advantage or millstone?

Again, on the face of it, this is an area where native applications have an undisputed advantage. However, this can in itself be somewhat of a two-edged sword. For one thing, on different platforms applications that adher to native conventions will work differently, sometimes subtly, sometimes not. It also means that documentation and other support mechanisms have to take this into account, further raising costs.

Also, it's also possible that true native UI compliance can lead to user confusion rather than the reverse, after all, plenty of people have iPhones and Windows laptops or Macintoshes and Android phones. UI standardisation is important for applications that have to seamlessly integrate into an environment, say, email clients, which should feel totally at one with the rest of the platform. However, it can't be said that games manufacturers worry very much about UI compliance, and we have all be using web sites with wildly different UI's for years. Sure there are plenty of complaints about many web sites, but the issues are really around the clarity and usability of the UI, not standards, and the same should largely be true about applications.

Installation as a barrier to adoption

In terms of barriers to use, the issue of installation is often overlooked, and it is true that many users will almost automatically install an app on almost any pretext. However, in many cases a user may hesitate before installation, thus creating significant drop out of adoption. This is particularly true in the case of ad hoc usage situations. For example, while installing a well reviewed game or utility may not make a user pause for thought, how many of us will install an app that may only be used once for a few minutes, like say one dedicated to a promotion or once off event like a trade show?

Increasingly, users are leery of installing apps willy nilly, that may cause unexpected issues on their precious device, and are becoming cautious in what they allow on their phones.

Conclusion

Reading over what I've just written, I can see that is may be regarded as a diatribe against native applications and promoting web apps. However, this is absolutely not my intention, rather I think that web apps have been unfairly regarded as a weak offering versus native implementations.
Certainly, this may well have been true once, with the weak HTML5 compliance and many bugs of mobile browsers, and it has to be said that Internet Explorer continues to be a drag on HTML5. However, mobile browsers especially are converging rapidly to stable, standards based platforms, while the native platforms continue to multiply and diverge.

In short, native implementations are certainly necessary for a large subset of applications, but it is also worth considering a web application when development cost, ease of deployment, adoption and update are important considerations.