Quite frequently we are asked to build iPhone apps by businesses and individuals around the Hunter region. The request is a response to Apple's success in the Australian marketplace for smartphone sales, however it is a self-limiting request.

Android device usage (both phones and tablets), and other platforms are excluded when iPhone-specific native applications are developed. These alternate platforms are gaining popularity primarily due to their low cost. To plan an online project that runs on one platform only to the exclusion of all other platforms is becoming increasingly less advisable in the current marketplace.

The world of mobile device application development is rapidly evolving, and there is a range of options to consider when planning a project that will be used on mobile devices:

• Smartphone-friendly websites
• Web apps
• Native apps using a single code base
• Native apps using native code

Smartphone-friendly websites

This option is the least expensive for online projects as it builds upon well-established technologies (HTML, CSS, web servers, content management systems).

The benefits of this option are:

• There is no appstore/marketplace submission process
• There is no approval process delaying the launch of updates
• All smartphone devices should have a similar experience without major work

The trade-offs of this option are:

• An active internet connection is required (this is becoming less of an issue as networks bolster their coverage)
• The amount of content smartphone web browsers can cache is small, so the project may feel sluggish in comparison to a native/offline app due to resources being downloaded
• Marketing the online project requires innovation as many people expect to find new 'apps' via their device's app store or 'marketplace'

Web apps

This type of project builds upon common online languages - HTML, CSS, and Javascript. It is usually aided by an existing framework to handle common functions such as loading content, transitions between screens, and displaying data in a template. This type of project can run offline similarly to a native app.

The benefits of this option are:

• There is no appstore/marketplace submission process
• There is no approval process delaying the launch of updates
• All smartphone devices should have a similar experience without major work
• Static assets (like images, stylesheets, javascripts etc) can be nominated for offline storage, making the project feel more like a native app

The trade-offs of this option are:

• There are many frameworks upon which to build your web app - choosing one that is going to be around in 12 months is important
• Documentation for many frameworks is either missing or incomplete, and paid support is expensive
• Marketing the online project requires innovation as many people expect to find new 'apps' via their device's app store or 'marketplace'

Native apps using a single code base

This type of project allows us to write the program logic for an app using a common programming language such as Javascript. The code is then translated in to native code with the use of a software package such as Appcelerator or PhoneGap.

The benefits of this option are:

• Reduced development time compared to writing native apps in the programming language each platform requires (ie Objective C for Apple iOS, Java for Google Android phones)
• Provides the ability to submit the project to an app store / marketplace to enable customers to download the app using a familiar method
• Provides avenues to use the device's built-in hardware (camera, GPS, tilt sensors, compass, etc)
• Provides a smooth and responsive user experience
• Database information, images, and files can be stored offline

The trade-offs of this option are:

• Depending on the translation software package chosen, certain built-in hardware may not be accessible to the app, or may not behave in the same way
• Updates to the app must go through an app store or marketplace submission process, which often involves a slow approval stage (and the potential of the rejection of your app)
• Development resources (pre-written code) for single-code base app development is less prevalent than native code resources
• Code to provide functionality outside of the translation software's intended use-case scenarios is sometimes controled by the translation software's owners and requires an expensive fee to obtain. This means that 'brick walls' can be encountered during development that can be costly to resolve.

Native apps using native code

This method of building apps provides us with the greatest flexibility to utilise each device's full potential, however it is also the most costly and time consuming. Native code is used to develop functionality for each device.

The benefits of this option are:

• Provides full access to use device-specific functionality
• Provides a smooth and responsive user experience
• Native code is available online to help fast-track the development process
• Documentation is far more prevalent and of a higher quality
• Development support is easier to find and engage
• Well established programming languages are used
• Database information, images, and files can be stored offline

The trade-offs of this option are:

• Writing and maintaining multiple code bases is time consuming and expensive
• Updates to the app must go through an app store or marketplace submission process, which often involves a slow approval stage (and the potential of the rejection of your app)

In summary

Depending on your budget and the requirements of your project, one of the solutions above will be recommended. It is important that anyone wishing to develop a mobile-device project recognises this rapidly changing landscape.