Building for multiple mobile platforms with one codebase

Individuals may have strong opinions about the merits of Apple iPhone versus Google Android versus the struggling Palm WebOS versus the not-yet Windows Phone 7; but sit them round a table to discuss app strategy and those diverse platforms change from a debating point to a problem. Presuming a web app won’t cut it, how do you target all those devices without the unreasonable expense and complication of managing multiple projects? The native languages are all different; Objective-C for iPhone and iPad, Java for Android and RIM BlackBerry, JavaScript for WebOS, C# for Windows Phone 7.

There are three possibilities that come to mind. One is that all the platforms will eventually allow you to write in C or C++, making this the unifying language, though you still have some fancy footwork to do overcoming library differences. Android now allows this via the NDK, and Palm via the PDK. There is currently no alternative to Java for Blackberry, and Microsoft says native code won’t be possible on Windows Phone 7, but well, you never know.

The second is Adobe Flash. This is an interesting one, because Apple prohibits Flash on the iPhone, but Adobe has a Packager for iPhone that builds native iPhone apps from Flash projects. Another issue is that although Flash is available or promised for all the main non-Apple devices – Apple’s gift of a selling point to its rivals – it is not Flash alone that does what it needed, but AIR, the “desktop” or out-of-browser runtime. This has been previewed for Android and promised for other devices including Blackberry. AIR for Windows Phone 7? Maybe, though I’ve not seen it mentioned.

A third idea is a clever framework that does the necessary cross-compilation under the covers. This cannot depend on deploying a runtime, nor compiling to native code, because these approaches are blocked by some mobile platforms. Rhomobile has the Rhodes framework, where you code your app in HTML and Ruby and compile for devices including iPhone, Windows Mobile, RIM Blackberry, Symbian, and Android. Rhodes includes an MVC (Model View Controller) framework and an ORM (Object Relational Mapper) to wrap database access. There is also a RhoSync server component to enable offline data with synchronisation back to the server when reconnected; and the RhoHub hosted IDE for buildings apps with a web browser.

Rhomobile tells me that Palm WebOS support is in the works. They also promise Windows Phone 7 support, which intrigued me because Rhodes says it compiles to “true native device applications”. Has Rhomobile gotten round Microsoft’s opposition to native code? Apparently not; VP Rob McMillen eventually told me that this will mean a .NET IL (intermediate language) implementation.

The Rhomobile approach reminds me of AppForge, a company which produced the well-regarded Crossfire add-on for Visual Studio and compiled Visual Basic to a wide variety of mobile platforms. Unfortunately AppForge was acquired by Oracle, and its new owners showed callous disregard for existing customers. Not only did development cease; it also became impossible to renew existing licenses. Thanks to an activation component, that also blocked new deployment of existing applications – every developer’s nightmare.

That said, there is no activation requirement for Rhodes that I know of, and the framework is open source, so I don’t mean to suggest it will suffer a similar fate.

What about Java? On the face of it, Java should be ideal, since multi-device support is what it was designed for. It is a measure of how far Java has fallen that we hear far more about the lack of Flash on the iPhone, than the lack of Java. Microsoft says yes to Flash on Windows Phone 7, though not on first release, but nothing about Java.

Java as a mobile runtime needs a strong dose of lobbying and evangelism from its new stewards Oracle if it is not to fall by the wayside in this context. Hmm, AppForge.

VN:F [1.9.18_1163]
Rate this post
Rating: 9.0/10 (2 votes cast)
Building for multiple mobile platforms with one codebase, 9.0 out of 10 based on 2 ratings

Related posts:

  1. Which mobile platforms will fail?
  2. Developers and mobile platforms: lies, damn lies and surveys
  3. Mozilla CEO fearful of closed mobile platforms. So what next for Mozilla and Firefox?
  4. Infragistics: upbeat on Windows Phone but also building for Apple iOS, Google Android
  5. Building Windows – when Microsoft shows its hand

6 comments to Building for multiple mobile platforms with one codebase

  • There’s another Flash-based solution for this, Elips Studio:
    http://www.openplug.com/

    It ports Flex apps to native Android, iPhone, Symbian and Win Mobile apps.

  • What about monotouch? It seemes it is progressing fairly quickly too.

  • José

    Tim, what about Appcelerator Titanium? And PhoneGap? With Titanium you cover iPhone and Android with the plus of desktop and web apps. Not all mobile platforms, but you have the advantage of native code.

    With PhoneGap you have iPhone, Android, Palm, Symbian and Blackberry support.

    http://www.appcelerator.com
    http://www.phonegap.com

  • Thanks for the nice writeup. With regard to the followup comments, Rhodes has a number of key architectural advantages over other frameworks which let you write your apps in HTML plus Javascript

    Specifically Rhodes:
    - is the only framework with support for the Model View Controller (MVC) pattern (you can just write HTML plus Javascript for the view but you can also write a controller)
    - is the only Object Relational Manager (ORM) for smartphones, insulating you from writing SQL
    - is the only framework with sync support and the only mobility sync server anywhere to use native smartphone push SDK (BlackBerry, iPhone) to optimize sync
    - is the only app generator for smartphones: describe your app and its objects and it generates a controller and views that are immediately functional to edit local data
    - features the first mobile Ruby implementation on each smartphone device operating system
    - provides the only hosted service for smartphone development

    Check out http://rhomobile.com/blog for a bit more detail.

    Cheers,

    Adam

  • @Tim

    Nooooo please no Java, its dying because it sucks for UI and always has, the performance is a joke. Sun never achieved their mantra of write once run everywhere, the reality was write once debug and fix UI sizing issues everywhere, a complete joke.

    I think appcelerator and phonegap are quite raw and limited at the moment but I’m sure they will improve with time.

  • John

    @gary
    I had to check the date on your post to make sure it wasn’t April 1st.

    Java is not dying because of the UI and performance. The JVM in 6 is fabulous engineering achievement. We run trading applications on it and the speed is comparable (and often better) than C and C++ apps. The HotSpot VM has been excellent for serverside apps for many years but got a LOT better in Java 6u10 for client side apps.

    Swing is no harder to learn than .NET or any other framework and using the right look and feel it looks pretty damn good as well. Use MiG layout or the Swing Layout libs and you will have no sizing issues at all.

    The tooling for Java: Intellij, Eclipse, Netbeans for IDEs, Maven, Gradle, Ant for building, Hudson for CI, etc etc is vastly superior to every other development environment out there.

    Android use Dalvik as its VM and this is simply Java. Admittedly Java ME should be put down!

    Don’t be fooled by the kewl features of other languages; great development needs great tooling.

    The next gen of languages for the JVM: Clojure, FanDev, Scala, Groovy etc allow you to pick your language as well if you really need something else.