A key decision to make when creating an app is whether to choose cross platform mobile development. By the end of this article you’ll have a good understanding of what cross platform mobile development is, what some of the frameworks are and how to choose the right direction for you to go in.
This article is the first in a 2 part series giving some background and analysis of the main options when developing an app for multiple platforms. In part 2 of this article I’ll guide you through a more structured approach to deciding on you best option. (You can find part 2 of the cross platform mobile development guide here).
Just in case were wondering, by mobile platform I mean primarily iOS, Android, Windows Phone, Blackberry
For the most part in this article I’ll be talking broadly about 4 different approaches you can take to mobile application development:
- PhoneGap (which also applies to Cordova & Icenium as they’re pretty much the same thing)
- Appcelerator Titanium
- Native (i.e. developing in Java for Android, Objective-C for iOS, C# for Windows etc)
But to get started lets define some basics.
I could not cover all frameworks, so this article discusses not only how to make the right decision, but the reasoning behind those decision so you can include other frameworks if you so require.
What is cross platform mobile development
A simple explanation of a cross platform mobile app is any attempt to deliver the same app across multiple platforms. However, when more specifically talking about cross platform mobile development we’re really talking about sharing a code base between multiple platforms (this might not mean sharing an entire code base).
Benefits of cross platform development
The main benefits normally associated with cross platform development are:
- Improved reuse of code.
- Less duplicated work.
- Easier to maintain code base.
- Better consistency in implementations.
- Leveraging of existing skills on different platforms.
- Lower development cost.
- Quicker to market for multiple platforms.
Negatives to cross platform development
Given all these benefits, its really tempting to think jump straight into making your app using a cross platform development framework. There can be however, some important downsides when compared to :
- Poorer processing performance.
- Poorer user interface responsiveness.
- User interface that is inconsistent with the operating system.
- Slower start-up times.
- Increased complexity due to additional layer of abstraction.
- Inability to use latest features of the native operating system.
- Additional costs associated with the framework.
- More frameworks equals more 3rd party bugs and nuances.
- Poor interoperability with 3rd party APIs.
Now before you all these potential negatives turn you off completely, I should mention that they don’t all apply to all frameworks and the level of impact may be negligible for some frameworks. What we need to do is weight up all the pro’s and con’s properly and come to the right decision using the right information.
Quick Analysis of Each Approach
I’ve listed 4 approaches above which each have their own positives and negatives, some in varying degrees. Comparing any 2 of these frameworks could take up an entire article, so my aim here is to give a fair overview and comparison of pro’s and con’s of each. I’ve also done my best to avoid technical detail that doesn’t really matter when assessing what platform to choose.
Native development really represents the baseline for all comparisons, and requires little explanation. When going native you’ll essentially be developing in the prescribed way for that operating system – that means:
- iOS = XCode & Objective-C
- Android = Android Studio or Eclipse & Java
- Windows Phone = Visual Studio & C#
This means that your code base cannot be reused across platforms at all, and that you’ll need to have skills in all languages and development environments for each mobile platform you’re targeting.
Note all native development options include some derivative of C/C++ for developing at a lower level. Normally this is for gaming or much higher performance and as such won’t be discussed directly here.
In all cases, anything related to performance is generally at its best when developing natively (such as processing, responsiveness, start-up times).
Phonegap (incl Cordova, Icenium etc)
The big positives to PhoneGap are that the level of reuse is very high – almost all code for creating the views, transitions between views and core app logic is reusable. Furthermore PhoneGap has the best presence across different platforms as it currently supports iOS, Android, Windows Phone, Blackberry, Firefox OS and more.
Another negative is that anything related to performance is going to be the worst of all options with PhoneGap (responsiveness and processing especially). That said processing is generally not that important for most mobile apps, and the responsiveness isn’t terrible – its more that you can notice it if you’re looking for it, but it probably wouldn’t stop you from using an app.
The final big negative with PhoneGap is that it can take some HTML and CSS wizardry to make your app look and feel native – and even with that it may never truly feel native…because its not!
With Appcelerator the level of code re-use is very high, and probably as high as PhoneGap. The big con here is that in order to maintain that 100% level of code reuse you have to program to the lowest common denominator. What I mean by this is that the Appcelerator API provides a way to create a UI for both platforms in a common way, but not all platforms support the same features – so really you can only develop the UI using features that all target platforms support.
Another point to note with Appcelerator is that it currently only supports iOS and Android – so if you need your app to run on Windows Phone or Blackberry its a non-starter. If however, you’re only concerned with iOS and Android its a great option.
Finally and perhaps one of the most annoying things about Appcelerator is that its pricing model is pretty well hidden! For exploration and trying stuff out you can use Appcelerator for free (which is great). But pricing for anything that will be deployed to an app store and get significant downloads requires a significant outlay (read as several thousand $).
Xamarin is in some respects very similar to Appcelerator, except that you’re writing your code in C#. So you write your app logic with C# which can be reused across all platforms. For your user interface you have a couple of options:
a) Using a native designer to create platform specific user interfaces. This means writing different UI code for each platform.
b) Use Xamarin.Forms which is an xml designer much like that of Appcelerator whereby you write the UI once which is then converted into platform specific code.
The result of this is a native app, running with native user interface components.
The level of code reuse is again very high with all app logic being shared across platforms, and depending on your approach the UI could also be shared too. Given that you go for the 100% reuse option with Xamarin.Forms you’ll have a similar issue to Appcelerator in that your UI will be built to a lowest common denominator. You do however, have the option to cater your UI’s for specific platforms.
Given that Xamarin apps are written in C# your should feel at home if you’re used to using C# and .NET. Similarly to Appcelerator there will be a learning curve in getting used to the custom API and Xamarin’s nuances.
Performance and responsiveness will be similar to Appcelerator as the code is basically native – there may be some slight differences but for the most part it should be unnoticeable. Xamarin does however impact initial load times as it has to load its own runtime.
In terms of platform support Xamarin currently support iOS, Android and Windows which gives slightly better coverage than Appcelerator, but slightly worse coverage than PhoneGap.
Finally Xamarin does have a cost associated with it, and whilst being much clearer than that of Appcelerator it is still considerable (generally speaking you’d be looking at over a thousand $). Another down side here is that the exploratory version is far more restrictive than Appcelerator.
This article is the first in a 2 part series giving some background and analysis of the main options when developing an app for multiple platforms. In part 2 of this article I’ll guide you through a more structured approach to deciding on you best option.
I’d love to heart what approaches have you taken when developing mobile apps and why you decided go with that approach. I’d also like to hear from people who are currently struggling with this decision and are looking for guidance.