A common question we’re being asked is: ‘I want to support iPhone and Android – is there a way we can use a multi-platform framework so it only needs to be built once?’.  Here’s our take.

The idea of using a multiple-platform framework is very appealing. Without one you need to build and test everything at least twice. It’s also easy to forget the impact on application maintenance – every change becomes a risk that the change is only applied successfully to a single platform, or introduces a regression bug on one of the platforms. As you add more platforms this becomes a death of a thousand cuts.


For games a cross-platform framework is a successful and proven route.  Most games are written in C/C++/OpenGL, which have support across Android, iPhone, Palm and Nokia.  Games can be built using a cross-platform framework because they have much less integration with the underlying phone platform – ie the interface for Angry Birds on the iPhone is almost identical to that for Angry Birds on Android.  Typically game interfaces vary completely from the interface standards of any particular platform.

The most popular cross-platform game frameworks are:

– Cocos2dx.  Game code is all built in C++, which can run natively on both iPhone and Android.
– Unity3D. Game code is written in .NET which is converted into native code for the platform when published from Unity.
– Corona.  Game code is written in Lua, which is automatically translated to C++ when published from Corona.
– Unreal UDK. Game code is written in UnrealScript, which is a language that’s specific to the Unreal engine.
– Flash.  Game code is built in ActionScript, the standard Flash language. There are currently performance concerns, hopefully these will be resolved in a future release.

Note that of these, only Cocos2dx and Unity3D let apps communicate with native code from the platform.  Without this the developer is limited to the features provided in the cross-platform framework – for example Flash apps currently have no means of integrating with Apple Game Center.

None of the major cross-platform game frameworks support Windows Phone 7 or Blackberry. This is due to the Blackberry being Java-only and having limited graphics support , and Windows Phone 7 only supporting applications built in .NET. (Note that the Blackberry PlayBook does support C/C++/OpenGL, which means so should the new RIM QNX platform next year.)


A more interesting scenario is building an application. For simplicity’s sake we’ll define an application as an app that uses native UI (‘native’ controls are the parts of the user interface provided by Apple/Google/etc that can be built into any app – for example the spinning date selector on the iPhone).  Why native UI is vital is a blog post to itself, suffice to say that we believe that at this stage only apps built with native UI feel ‘right’ on a device.

This immediately limits us to a small handful of cross-platform frameworks – rhomobile Rhodes, MonoTouch/MonoDroid and Appcelerator Titanium (alternative approaches that don’t support native controls include the options suggested above under gaming and PhoneGap)

Our view is that whilst these frameworks can work in two particular situations, you have to be very careful that the project you’re building fits into one of them.  The first situation is for extremely simple applications – you can go slightly more complex than http://isitfridayyet.org/ – but not much! (eg no audio streaming)  The other situation is where you have a development team that’s deeply knowledgeable about both the cross-platform framework and both the underlying platforms, and is therefore able to use the framework in a very judicious manner and combine it with native code where appropriate.


Appcelerator Titanium has been gaining the most uptake and mindshare, so we’ll focus on that.  As mentioned above, for very simple applications the framework can work well out of the box, but as soon as you start getting into more complex applications the framework falls down for a few reasons:

– Building and documenting a high-quality, new API and development environment is an extremely difficult task. Appcelerator is doing a decent job, but the resources put towards it so far are nowhere near what Apple, Google and Microsoft have available (though their acquisition of Aptana is a positive step)
– Some of the abstractions are leaky.  For example you can’t 100% understand what’s going on in Ti.Media.AudioPlayer on an Android phone without understanding the Android MediaPlayer framework.
– There are features missing in the cross-platform frameworks.  This is exacerbated by the constant and fast evolution of the underlying frameworks.
– Native UI components are different between platforms – for example there is no Android equivalent of the iPhone UINavigationController.
– UI standards are different between platforms from a usability perspective. A simple example is the presence of a back button on the Android, vs. having to use a soft button for back on the iPhone. Another example is the interface standards for deleting items from and re-ordering lists are quite different between iPhone and Android.
– Performance is lower.  Whilst the performance of method calls within Appcelerator JavaScript is a similar magnitude to that in Objective-C, our research has shown when they cross the barrier they execute ~20 times slower.

Nevertheless, there can be value from the cross-platform framework.  Apart from the API they provide, which despite the issues listed above is fine in some situations, there is another useful technology which is cross-platform binding.  The binding framework in Titanium is called Kroll, this allows shared logic in a common language (JavaScript) to invoke native classes (eg Java/Objective C) written separately for each platform, and vice versa for call-backs. These native classes can be supplied by the Titanium API or can be custom classes built by the developer (for example a custom UIViewController representing a screen).  Another example of a binding framework is Lua Wax, allowing a single set of Lua code to be leveraged across both iOS and Android.

In this case they key is using the framework in specific situations where it adds value and to build common business logic, whilst staying away from parts of the framework which fall down for the reasons listed above and not being afraid to write code natively.  The framework becomes a glue that can contain business logic, configuration, etc, and help reduce duplication.


Whilst cross-platform games development is very possible, cross-platform applications development is much harder and the strongest candidate framework (Appcelerator Titanium) only adds value in specific circumstances.