[Cross-posted from blog.davemdavis.net]

WebVsNativeIn my recent post, A Mobile Web Strategy, I covered some of the architectural decisions that go into building a mobile website.  I glossed over the process of choosing whether to a mobile web application or build a native application because I wanted to cover the other topic first since it tends to be less controversial.  The debate on mobile web vs. native application incites passion in most developers.  It is my intent to take an objective stance during this post.  I will save my opinion until the end.

Native Applications

A native application runs directly on the hardware of the device and not in the device’s web browser.  These applications are usually delivered and updated from an app store. Here are some pros and cons of building native applications:


    • Native applications are able to access all the hardware sensors on the device.
    • Native applications can work offline and may not need a connection.  Data can be cached locally.
    • You can usually get better performance out of native applications since they run closer to the hardware. This tends to provide better user experience.
    • Most platforms offer native applications the ability to perform tasks in the background, even when the application is not running.
    • Native applications can be more readily monetized.  Most stores offer infrastructure for handling purchasing transactions (for a cut of the cost).


    • Changes to the application require redeployment of the applications (but most stores handle this gracefully).
    • The application certification process can take time for your deployment.
    • Native development requires developers skilled in working with the different platforms.  Depending on how many platforms you need to target this may require many different skill sets.

Phone Gap

A caveat to the last con:  there are frameworks out there that allow you to build native applications by writing an application once, usually in HTML/JavaScript, which gets compiled into native applications. Phone Gap is one such framework.  The downside to these frameworks is you tend to develop to the lowest common denominator. For example on Windows phones you may not be able to take advantage of live tiles. This may be OK if the features you need for your application are available on all the target platforms and have been incorporated into your framework of choice.  Also keep in mind that these applications tend to look generic and don’t embrace the design metaphors of the different operating systems.

Mobile Web Applications

Mobile web applications are web applications that have been optimized for mobile devices.  These applications may be smaller versions of their desktop equivalents or completely different applications that provide functionality that makes sense for mobile devices (consider data bandwidth, power consumption and usability on a small form factor).


    • Broader pool of developers – most web developers are able to shift to mobile web development with minimal learning curve.
    • Plethora of open source frameworks to help speed up development.
    • Mobile web applications are able to be modified without having to release to a web store – all users access the latest build without having to manually update the application.
    • Runs on most platforms, including non-smartphone devices.


    • There is still work to determine device capabilities, including which versions of HTML/JavaScript/CSS will work.
    • You are limited in which device sensors you can access.
    • Very limited offline/background processing (requires HTML5 at a minimum).
    • You are responsible for implementing monetization infrastructure.

My Two Cents

These are just some of the things to consider when creating your mobile strategy. My preference is building native applications but I am not against mobile web development. The situation should dictate which approach you should take.  Don’t build a native app just for the sake of building a native app. In the past most smartphone users avoided using the web browser.  The experience was not ideal.  As more sites are redesigned with mobile in mind this is steadily changing. So it is up to you to build out compelling applications that make the user want to come back.

One of my pet peeves is when a native application is a shell for web content.  There is no value add except that it gets you in the app store and provides you a way to update your application with deploying a new version.  In my experience these types of applications lack a robust user experience.  They just don’t perform as well as pure native applications. The opposite is true too.  Don’t make me install your native application when I visit your site on a mobile device.

Whichever approach you choose, you should make sure that it’s the one that best suits your needs.  Build out a compelling solution so that users want to use your application. As I noted in the last post, A Mobile Web Strategy, consolidate as much functionality as you can behind a service layer.  This allows you the most functionality in making your choices.