The Ultimate Cross Platform Mobile Development Guide – Part 1

23 Flares Twitter 3 Facebook 0 StumbleUpon 12 Google+ 4 LinkedIn 4 23 Flares ×

Cross Platform Mobile Development

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
  • Xamarin
  • 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

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)

Phonegap is probably the simplest of all the cross platform frameworks to explain – the concept is essentially that each platform implements a web browser and a web view component. As such a PhoneGap app is developed completely in JavaScript, HTML5 and CSS which is subsequently rendered within a web view component. PhoneGap then provides a standard API which allows you to work with features of the device in a JavaScript.

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.

Also depending on your background, JavaScript, HTML5 and CSS are pretty well known and if you have experience with web development and as such it might provide an easier entry into mobile development.

On the down side the main actual language with PhoneGap is JavaScript – whilst I’m a fan of JavaScript I have to acknowledge that building large apps with it is more difficult than a with a language such as C# or Java.

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!

Appcelerator Titanium

Appcelerator Titanium is quite a bit more complicated! Without getting into the nuts and bolts, with Appcelerator you’re writing your app with JavaScript, but instead of using HTML5 and CSS for the user interface you’ll be using a custom API or XML language. The result of this JavaScript and UI API is then compiled into an app that is like a native & JavaScript hybrid.

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.

As with PhoneGap if you’re confident with JavaScript then you already have a jump start with Appcelerator, but there will be a little more learning curve as you have to work with the UI API. Also given that the main language is JavaScript, there is additional complexity in building a large app.

On the positive side the performance and responsiveness of an Appcelerator app is going to be noticeably better than that of PhoneGap, as the UI is essentially native. This means the user interface will feel and handle just like a native app, even though everything you’ve written will be in JavaScript.

There may be a slight impact on processing performance as Appcelerator has to proxy code through to a JavaScript execution engine, but unless you’re doing some fairly heavy processing it should be unnoticeable. There may also be a small impact on app load times, as with any of these cross platform libraries they need loading up – again this shouldn’t be a huge problem unless you need your app to launch in fractions of a second.

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

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.

Generally speaking strongly typed languages such as C# are considered easier to build larger applications with than JavaScript, as you get a lot better early warning signs from the compiler and better refactoring options. If however you’re already familiar with JavaScript you may find Appcelerator or PhoneGap easier to pick up.

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.

Jsauve has made a really good point in the comments section that you can get up and running with Xamarin at a much lower cost (his example is targeting iOS, Android and Windows for $600 per year). This reduced cost means you have to use Xamarin Studio rather than Visual Studio.

Wrapping up

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.

The Essential App Marketing Kit
Subscribe To My Newsletter To Get an Entire Chapter From The Book for FREE
Never display this again
23 Flares Twitter 3 Facebook 0 StumbleUpon 12 Google+ 4 LinkedIn 4 23 Flares ×