So, You Want a Mobile App

So, you want a mobile application.  What kind of application is best for your needs?  How do you know what to build?

In the end, there are two major ways to implement an application for a mobile device:

• As a mobile web app (Translation: As a web-page that is designed to be viewed on a mobile device) (e.g. mw.weather.com)
• As a device-specific application (Translation: As an iPhone/Blackberry/Android/whatever-specific application) (e.g. anything in the iTunes App Store)

Mobile Web App

A mobile web app is, at it’s core, a webpage or script, living on a server that you control.  This offers a number of advantages and disadvantages.

On the up side, it can be used by any device that has a working web-browser (indeed, you can set the tool up to work on desktop computers just as easily as on a mobile device).  And because the application lives on a server you control, updating the application is incredibly easy – update the local copy, and you have updated the application for all of your users.

On the down side, the application needs a connection to the Internet (because it’s a web-page), and is limited by the speed of your connection to the Internet (which on a mobile device can mean that your data is traveling by digital mule-train).  Some of the speed issues can be mitigated through the use of dynamic web-page technologies such as javascript, which can help reduce the amount of data that is being transferred (because you can download the core once, and then dynamically update only the information that you need), but some devices (notably Blackberries) have limited or non-existent support of dynamic technologies such as javascript.

Device-Specific Application

A device-specific application is an application built to be downloaded to and run specifically on a particular type of device.

The single biggest benefit of this is that you no longer need the Internet to use your application.  This means that your app will be able to work even in those hard to reach areas (because it’s on the device, not the internet) and your application will be markedly faster (because you are no longer waiting on the internet to provide the information).  Additionally, you can more readily take advantage of device-specific features, such as GPS, camera, and microphone (should you want them).

The core problem with building an application for a specific device is that the application is device specific, meaning that you will have to build additional versions if you want to support additional types of device.  A further issue is that distributing updated versions of an application to your team is more complex than in a web-app form (for starters, your team will have to download the updated app to their mobile device).  Finally, while most of the application development and distribution systems are free, Apple charges $100/yr or $300/yr for the privilege of creating applications which can be distributed in-house (ad-Hoc, limited to 100 iPhones on the $100 plan, or Enterprise Distribution to an unlimited number of iPhones on the $300 plan).

So What Is Best For You?

In the end, this is going to come down to you, your wants and your needs.  A couple of rules of thumb can apply though.

If you have to support a wide variety of devices, it will probably be more cost-effective to create a mobile web app.  However if performance matters, creating an application that runs on a specific device will provide a marked improvement in speed and reliability.

If you are dealing with dynamic data – data that will probably have changed every time that the user starts the application (e.g. weather data) – having a mobile application on the device will only provide a marginal performance advantage (since the app will have to download the new data every time it starts up).  If the application deals more with relatively static data (e.g. reference material), a device-specific mobile application will provide much better performance.