Cross Platform Applications
Having an app is a very effective way of getting information out to your users on the move. However there are several device platforms (iOS, Android, Windows Phone, Blackberry etc.) to build apps for. The percentage market share of each platform means we decided to be inclusive and support as many platforms as practical.
IDC produce reports of market share, the data for 2011 and 2012 is shown below.
From this data, we conclude that support for iOS and Android is essential and makes 90% of the market. We also support Windows Phone as it is the only other platform with an expanding market share. Full details from IDC report.
There are several broad approaches to building cross platform apps for mobile platforms. Each has its own advantages and disadvantages as described below.
Cross-platform HTML5 app
A HTML5 app uses web technology and the devices built in browser to present data to the user. It allows apps to be created quickly in a similar way to creating a website. This can then be wrapped in a framework that allows the app to be packaged into something that can be sold in the app stores. The technologies and frameworks used to make this approach possible includes: PhoneGap, Applicaiton Craft, Appcelerator and many more
The advantages of this approach are:
- The speed an app can be created.
- The consistency of the look and feel of the end result (app on android looks the same as app on iOS).
- Tthe reuse of existing skills a web developer has to create the apps.
HTML5 allows access to some of the more standard device features: 3D Graphics, Geolocation, multimedia etc. It does not allow (yet!) access to the some of the low level sensors (Accelerometer, Gyroscope, Compass) we make use of in our GIality solutions.
Building native apps is the process of building an app for one platform. It uses built presentation framework of that platform you are working on (Cocoa Touch in iOS, XAML on Windows Phone and XML in android). This type of app allows full use of the power of the device: it can make use of all the sensors and can produce richer user interfaces that are consistent with the rest of the device.
The disadvantages it that you must make separate applications (probably in separate languages, probably maintained by different teams) for each platform you want to support.
Our approach: Xamarin Studio
As a small company with a small development team, we looked at what we could do using the different approaches described above and decided we wanted the rich user interface and speed of native applications (we do a lot of 3D work), but we didn’t want to maintain separate code bases for each project.
Our approach has been to use Xamarin technology to create native applications using a common language and a shared code based. We use C# (a language that many developers are already skilled in) to create code that can be run natively on Android, iOS and Windows Phone. We write a native user interface for that application in whatever technology is appropriate for that device.
Working with Xamarin technology is the MonoGame project. This creates a 3D environment based on the API of Microsoft XNA. The Monogame team describe this as:
MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro.
This allows us to create out 3D visualizations in C# writing XNA code and the game to be ported from platform to platform with very little extra work required.
Final thought: native experiences driving innovation
Scott Hanselman in his article on Apps Are Too Much Like 1990s CDROMs And Not Enough Like The Web, points out (amongst other things) that new experiences currently only possible in native apps, like the 3D experiences of GIality apps, will eventually become a web standard and become possible in a standard web app.