Mobile Apps have been there much before the advent of smartphones and tablets, even if they were factory installed. The phone book, calendar, and alarm on those half-pound phones with monochrome screens were all apps. However, ‘app’ became a buzz word only after Apple inaugurated the App Store in July 2008 and Google launched the Android Market in October the same year. Nokia joined the bandwagon by launching its Ovi Store in May 2009.
Within the past three years, app communities are building up, software developers around the world are developing mobile apps, companies are providing downloadable apps to access their websites and services, and of late, a new fancy adjective was added to app and ‘native’ apps are being compared to HTML5.
Apps: Users’ and Businesses’ Viewpoints
From a user’s perspective, any piece of downloadable software is an app, be it a game, a compass, or a mail client. He is not bothered if it is a native app or an HTML app.
For an app developer or a provider company though, the difference between developing a native app and an HTML-based webapp is huge, both from the cost angle and the features they provide. At least now. HTML5, though still a work in progress, promises capabilities that can improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices.
Native apps are considered more responsive and functional than their web-based counterparts. One of the primary reasons is that they have direct access to not only the basic hardware like the microphone and speakers but also hardware sensors like the camera, gyroscope, accelerometer and the GPS. A compass, for example, is therefore highly suitable to be developed as a native app.
The development of native apps is slower and more expensive. Since it is written in Objective C or Java, it requires a higher technical expertise and more effort and time, thereby increasing the cost. Since native apps are installed on the OS, and the market today is shared by many platforms, iOS, Android, Windows, Symbian, Blackberry OS, the cost is multiplied.
Another disadvantage for native apps is software update. Though most native apps designed for smart devices these days talk to the internet and regularly check for updates, the user still has to download and install it. Products keep evolving, and the manufacturer has to develop new features and fix old bugs for both a web app and a native one, but they have the extra job of releasing them for all platforms supported. Also, since there would be some non-tech savvy users who do not keep their software up-to-date, the provider has to support multiple versions of the same app.
Web apps, unlike native apps, are easy and faster to develop, are platform-independent, and an update requires as much as refreshing the page or restarting the browser. The developer provides a new version and redeploys it at their servers, though there is an extra cost of storing data and maintaining servers.
However, when it comes to games, native apps rule the front. You possibly cannot have graphic-intensive games like Angry Birds (but http://googlesystem.blogspot.com/2011/05/angry-birds-as-web-app.html) in HTML5. Flash could have supported that, but Apple does not support that on its iOS. Neither would Windows8 in its new IE10. So unless you are writing an app exclusively for Android Honeycomb, Flash-based games wouldn’t work.
Until HTML5 proves itself capable enough to provide the same functionality as Flash and give Adobe a run for its money. Okay, only the Macromedia part of Adobe.
Since a user couldn’t care less with the underlying technology used for their apps, there can be download-and-install apps written partly in HTML, providing the best of both worlds. A pure-HTML downloadable app is slightly difficult, since the app should also know how to render HTML and CSS, and have a JS engine to interpret Javascript, the browsers do that best already. An intelligent app may internally use the browser to display its interface in HTML5 and to connect to the internet, and while providing an Indistinguishable interface as a native one.
Native Apps have been there on desktop and laptop computers since ever, even before the Internet was born. As networks became faster, computing evolved, and people started using multiple devices and collaborating (remotely at times) with fellow users, there has been a paradigm shift towards web apps. There was a time when the browser was used only for browsing, but today, you can create spreadsheets and presentations and edit pictures from within the browser using Google Docs. Email apps like Yahoo’s are rich-clients that give almost the same UX and speed as the native desktop clients. Heck, you can even build up an entire J2EE application inside a browser.
Google Chromebooks rely entirely on web apps, and that has made possible a high performance and low cost, though they have not been adopted yet by many people.
HTML5 can be of assistance to maintain an offline version of your data on ythese web apps, thus giving developers the best of both worlds.
The current specification version of HTML was standardized in May 2000, 11 years ago, at a time when phones and tables did not have browsers. The in-progress specification, HTML 5, shall take into account all those new developments in hardware, software, and processing and network speeds, and shall be designed to provide optimum UX.
For most of the open-source applications, like Google Maps, it is also possible for a third-party developer to create their own HTML5 apps and access web services from within. A native app makes no sense for such applications.
A major problem with phones in using web apps is the small screen. Most of the web apps are first designed for the 14/17/20 inch screens and then re-written for the smaller 4 incher, and deployed separately as a mobile site. Since companies have to anyway re-write, and also because apps are in vogue, they rather build an app for the website and make it available in the various app stores out there.
For developers and companies, it makes more sense to streamline their efforts towards HTML5, on nature of it being cost effective and fast at the same time. There will still be certain apps that will require native coding. Developers need to choose an intelligent ratio between the two only on a need-basis and not just because one is ‘cooler’ than the other.
Snecha,jquery touch, iwebtoolkit are common helpfull for HTML5 device web
Share on FacebookPage views:86