UManitoba uses a development platform called Titanium developed by Appcelerator. This is a javascript based framework that allows us to develop our application using a single code base and deploy our app to multiple mobile operating systems.

We currently deploy our app to Android and Apple based devices. With Titanium we can create very rich “native” applications which allow us to provide the best user experience possible.

For a more in-depth discussion of the various methods to mobile application development see below.


There are three principal architectures used in mobile application development to date. I’ll try to give a short explanation of each along with pros and cons. My list of pros and cons are not necessarily exhaustive.

  1. Mobile web apps.
  2. Hybrid apps.
  3. Native apps.

Mobile Web Apps

These are apps of varying complexity that are written using standard mobile web technologies such as HTML 5 and Javascript.

They may or may not be able to access device features like GPS, PIM, BBM, etc.


  • mobile web apps can target every smart phone device with modern web support. Blackberry OS 7.0 or greater, Android based smart phones, all iOS (Apple) devices, Windows  devices, etc.
  • Relatively straight forward to design and implement as developers use modern web technologies such as HTML 5 and Javascript.
  • potentially short time to market relative to other options (hybrid or native)
  • potentially cheapest option available as some technologies are open source.


  • user experience is relatively slow due to the use of a web engine to render the app
  • don’t have the same level of access to device capabilities like other options. For example access to camera, filesystem, contacts, other sensors may be limited or not available at all.

Why you might not want to choose this option?

If you are looking to create a feature rich, highly interactive mobile app that you hope to engage users for long periods of time then this option may not be ideal.

Why you might consider this option?

Your mobile app needs to target the largest possible audience. As many devices as possible Android, iPhones/iPads, Windows devices, Blackberry devices, Kindles, etc., etc.

Your mobile app does not need to access or use many device capabilities like file system, etc.

Your mobile app may not necessarily be very interactive, its more informational in scope. Perhaps it has a form or two.

Speed is not important, you are not building a mobile game.


Hybrid Apps (like UManitoba)

Hybrid apps use a combination of web based technologies along with native api in order to address some of the short comings of mobile web apps.

Some hybrid architectures perform complex compilation and optimization schemes in order to create truly native app binaries while others provide “hooks” to native api in a similar fashion to some mobile web app technologies.

The overall goal of Hybrid technologies is to be able to use a common code base from which to deploy a “native” mobile app to all devices available.


  • Targets almost all major device manufactures, depending on framework used.
  • Write once deploy to many device types as a native app.
  • Native access to device features like GPS, accelerometer, Calendar, push technology, file system, without the need to go through an interpreter like Web Apps have to.
  • faster user experience due to being a native app, some frameworks are better then others in this regard in my opinion.
  • like mobile web apps, more cost effective since there is a common code base, using more commonly known web technology.


  • development is more complex due to the need to tweak the codebase for specific device types.
  • Potentially need to learn new languages such as Ruby & Rails, Lua, C#. Which will increase cost and time to market of apps.
  • Cost to license some frameworks could be prohibitive, some are open source while others are not.
  • Due to the hybrid space being relatively new, technologies are not as mature as Native languages so certain components may not be available to the developer.
  • As new device features and native api are developed there is a delay in those new features becoming available to hybrid developers, not always but usually.
  • they are slower then truly native apps. Most Hybrid frameworks have some degree of interpreter between the UI layer and the device layer. Even the frameworks that claim to create fully native apps have some sort of bridge or interpreter. Some are worse then others.

Why you might not want to choose this option?

You don’t have a lot of developers who are skilled in the languages necessary or perhaps I only have one or two web guys/gals.

You need to target all the major mobile device manufacturers such as Window, Blackberry, Amazon, Apple, Android products, etc.

You do not need to create a feature rich mobile app which requires access to GPS, filesystem, push, camera.

Why you might consider this option?

You have a few super skilled web guys/gals or people who have the ability to learn the computer languages necessary, but you don’t have an army of them.

You have an app that will be highly interactive, built for a specific purpose which requires the app to be fast, responsive and needs to access device features like camera, GPS, filesystem, push, etc.

You have a budget but its not huge so you really need to find efficiencies so that you can build the best app possible given my budget constraints.

You need to target the main players in the mobile space but you really don’t need to hit ALL of them.

Speed is important, perhaps you are building a mobile game.

Native Apps

Native apps are those apps written using specific programming languages, design and developed for a specific device. Apple devices (iPod,iPhone,iPad) use iOS,  Android OS is a Java based operating system that has become the most widely adopted platform in the smart phone market to date. Blackberry uses another Java based operating system for their devices, while Nokia has adopted Windows Mobile as their operating system.

Native apps are written to harness all the device capabilities in the most efficient way possible for a specific device platform. Thus native apps are typically the best choice if a developer needs to have the best end user experience possible and maximize the capabilities of a device (i.e. games).


  • native apps are written for a specific device type thus they should be able to provide the best end user experience available for the given platform.
  • native apps have the best and most efficient access to device features (hardware layer access).
  • typically the fastest type of app you can make.
  • access to most current API and developer software from device manufacturers.


  • need to maintain a code base for each device type
  • potentially long time to market for apps due to developers having to learn multiple relatively complex languages (Objective-C and Java)
  • high cost!
  • need to maintain your mobile app store portals on Google Play and Apple App Store, etc.

Why you might not want to choose this option?

You don’t have an army of developers with the experience necessary to write native applications for each operating system you need to deploy too (Apple developers, Android developers, Blackberry developers, etc).

You do not have the capacity to manage multiple code bases long term.

You don’t want to have to manage multiple, if any, mobile app sales portals like Google Play Store and/or Apple app store.

Application speed is not super critical.

You don’t have a big budget.

All you want to do is write a mobile app that will be used as an informational tool for sales and marketing purposes, you don’t have a big budget, you need the app up and running in a short time frame and you have don’t have the capacity to constantly update the tool either.

Why you might consider this option?

You have the developers and budget necessary.

You have the infrastructure to support native mobile apps long term.

You don’t care about supporting and maintaining multiple code bases.

Speed and efficiency is crucial.

You want the best possible mobile app for each device operating system you care about.




Leave a Reply

Your email address will not be published. Required fields are marked *