On my work, technology and related stuff....

Posts Tagged ‘web apps’

1 comment

 

This is probably one of the most commonly asked questions by folks looking to mobilize their business (probably right after what mobile platform to target).

While I have discovered a lot along the way from my own experience as a (native) mobile developer, I must add the disclaimer that this blog is also a result of discussions with a lot of smart people in this space. I thought it would be worthwhile sharing it to a potentially larger audience.

Definitions

 First , a brief definition of the two- [Mobile]Native Apps are mobile applications that can be downloaded and saved onto your mobile device from where they can be loaded to run natively on your device. [Mobile]Web Apps are mobile applications that are hosted on a remote server from where they are loaded and to run within a web browser environment on your mobile device.

The list below is by no means exhaustive. It is an attempt to highlight the major advantages of the two

 

Why a Web App?

 

                       1) “Develop once, Run everywhere”

 This implies that the web app is for most part platform agnostic. This has been widely touted as the selling point for web apps, however the statement is not entirely true. HTML5 is still in the process of standardization (http://dev.w3.org/html5/spec/Overview.html ) and as we know all too well, despite standardization efforts, ,there will undoubtedly, be variations in browser implementations across platforms. These variations will impact the behavior, performance and appearance of your web app on the various platforms. Still, while I cannot quantify this statement, one can infer that the development effort/cost will be lower than building native applications independently for each of the platforms of interest.

                      2) App is primarily “network data driven”

By this, I mean that the app communicates heavily with backend data servers for its various functions. Communicating large volumes of data across a bandwidth constrained wireless network is not practical (unless you have a cheap, unlimited data plan – if there is such a thing!). In this case, hosting the app in the network in the proximity of the servers will alleviate the problem.

                      3)Application developers want to “be in greater control”

Today, the fate of the apps is dictated (to a large extent) by the terms and conditions imposed by Apple App Store , the Android Marketplace or any of the other app storefronts. As an example, Apple’s “subscription model” imposed major restrictions on in-app purchases made from native apps  which led many app developers to remove the “Buy button” from their apps.  Web apps will allow you to bypass those restrictions allowing consumers to directly make purchases from their web apps. This provides developers the flexibility they need to deliver the desired service to their consumers without being encumbered by policies set forth by the application store owners. That said, while there isn’t a concept of a “web app storefront” today, one can envision that something like that would be in place when web apps become more ubiquitous. So it remains to be seen if there would be any restrictions that can impact the services rendered by web apps.

 Why a native app?

 

                      1) Performance, Performance, Performance!

This statement probably needs no further explanation. If performance is an important criteria, which is typical of  game apps, then native app is the way to go

                      2) Superior User Experience/ Interface

Native Apps leverage the hardware acceleration support for graphics available through specialized GPUs and use customized/optimized platform-specific  graphics libraries , thereby resulting in a vastly superior UI experience that is hard to match by web apps using JS/HTML/CSS. I earlier mentioned “Develop once, Run Anywhere” as an advantage for web apps- However, if UI is an important consideration for your app, then note that the  same “one size fits all” model will result in a sub-standard  user experience on certain platforms  and this would be unacceptable to users who are used to a particular level of user experience on a given platform.

                         3) Support for Remote Notifications

Most platforms provide some sort of remote notifications framework (eg- Apple’s PUSH Notification Framework, Android’s C2DM ) that allow registered apps to receive asynchronous from their application servers via centralized notification servers. Only native apps can register for push notifications. If this is a requirement for your app, then native apps are definitely a better fit. Alternatives for web apps like SMS or emails are not as seamless or compelling.

                     4)No Network Connectivity

If your app does not require network connectivity for its various functions, then offering it as a web app would impose that unnecessary requirement for it to run. Of course, HTML5 supports Application Caching that can be used to locally cache apps and run it even without a network connection. So this is probably not an issue, but the level of support may vary depending on the browser’s HTML 5 implementation.

                    5)Better Hardware Access & Control

Native Apps can access and control platform hardware resources like camera, accelerometers through native APIs exposed by the platform. This can be leveraged to build unique, compelling features into the apps. Although HTML5 is aimed at standardizing access to various hardware resources on the platform, the level of support is likely to be “inferior” compared to the options available to Native Apps – and by ”inferior” I mean that the platform vendors are more than likely to support access to a particular hardware  resource natively prior to supporting it on their browsers.  In some cases, the vendor may choose not to (for security reasons) provide access to certain hardware resources via their browsers. Besides, the level of hardware access support can vary across browser implementations.

In Summary..

There is a place for both types of apps out there. The choice greatly depends on the objective of the application and the targeted audience.