Friday 9 September 2011

Mobile Apps - Native vs Web (Part Two)


While doing some more reading and research trying to determine the subject for this article (continuing from Part One of the series), I decided to elaborate on some factors I found leaning towards pro-native. This is not to say that I think they are wrong, or I am right but merely to offer an outlook that was possibly overlooked. Firstly, an argument of “if it needs no internet connection it should always be developed as a native app”.

The issue of internet connection or not is an issue of distribution, and the method by which apps are installed and updated.  Coming back to the subject of local storage (covered in Part 1) there is no reason to rule out a HTML5/CSS/JavaScript application for a pure offline application. There are a number of HTML5 browser games now that allows offline play. The use of local storage to store user data such as save states or appcache for assets and offers the same kind of functionality that would be available through a native app. Again the limitation is that most mobile markets do not allow for apps that are not natively developed. This is where the issue of cross compatibility comes in; the potential of web/browser applications is limited only by the self-serving restrictions imposed of the respective markets. Not only can the user data be stored you can cache most of, if not all the application data through the browser thus rendering the “offline == native” argument redundant.

Any application whether it is a native or web app will initially need downloading from the relevant website or the specific device market. In the case of said web app you can cache all downloaded components in the browser offering true offline capabilities and likely a much smaller first download than a native application will need due to the small amount of data in HTML/CSS/JavaScript files (especially when you consider minified files). Whether native or web technologies they are merely presentational, it is about the approach that suits the application. This issue of ‘installations’, ‘clean end to end experience’, ‘browser support’ are all concerns that have existing or rapidly developing solutions when you look at applications developed using  web technologies.

Installations as it is, I think people overlook installation via caching using the Application Cache interface or AppCache as it is otherwise known. This provides many benefits, albeit providing some functionality that is an unfamiliar experience for the user however with the push to cloud technologies and the impact the web is having on people’s everyday lives it is something a user will adjust to. AppCache also provides a seamless, transparent update to the application which is a benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, this has a noticeable issue in performance speed for the user. The only exception to this is a download of resources from the server that have changed but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. Eric Bidleman has a great article explaining AppCache in more depth. [1]

Installations are a short sighted concept and installation via caching and transparent upgrades are often overlooked even though the single feature has been credited as the main success behind the Google Chrome browser. Using the AppCache interface, which provides a transparent updates and seamless updates to the application, can benefit to the user in a number of ways. First, the speed is increased as cached resources are local thus removing the need to make server requests for assets, providing a noticeable issue in performance speed for the user. The occasion where performance may be an issue is when downloading newer versions of changed resources from the server, but again, this only benefits the user as it seamlessly updates the application without the user being prompted or distracted by notifications. The only major downside would be user confusion over the new, improved, and transparent installation/upgrade procedure as the rapid change in analogy may affect the experience of users whose expectations lie with the existing monotony of the “next, next, finish” interface and are off put by its absence.

It is not ‘installed’ but still perfectly functional offline, with the ability to get updates over an internet connection (as any native app would). The advantage of web technologies is the ability to use the flexibility offered by mark-up/presentation along with a number of robust, efficient libraries and API’s available. I think it is a case of people not trusting the nature of the connection, the user likes the trust offered on app markets – and the way that you install applications is irrelevant, it just needs a clear analogy. There are a number of other concerns when you consider the approach to take with mobile applications such as browser support with things such as CSS compliance and JavaScript engines, but the same argument applies when you consider developing apps across multiple devices. The overall cost of developing an application across multiple browsers is far less than employing more developers to deploy apps for iOS and Android etc. especially when you consider the financial cost of targeting both. Both use different native languages, both need separate IDE’s and one even requires a particular set of hardware and operating system. All major factors to consider when weighing up the business side of things with the technical.

References:

No comments:

Post a Comment