If you got to attend Float’s Symposium in June, you found there was one issue that was prevalent throughout every presentation: the mobile market is fragmented. The number of variables to consider when developing a mobile application are astounding–from screen size to operating system. Worse, in order to sufficiently cover your user base, you have to take almost all of these variables into account at some point.
From a development standpoint, the fragmentation of mobile operating systems presents a huge challenge. Forget for a moment about getting the application to look good on multiple platforms…how do I get it to even launch? Fortunately, we’re not alone in this challenge and we have a number of tools to help us solve the problem of developing for multiple platforms. In fact, the number of options presents a new challenge: which one is right for me?
We’ve covered a lot of ground with PhoneGap up to this point, but PhoneGap is far from the only solution out there when it comes to mobile cross-platform development. We’ve spent some time with a number of other cross-platform frameworks and wanted to share a broad picture of the current options for cross-platform mobile development. To help give you a picture at the strengths and weaknesses of each framework, we scored each framework out of 3 points in the categories that we feel are important to consider for cross-platform development.
Rhodes
Rhodes is a Ruby-based framework that allows you to build your application a very similiar way to the way you’d build a Ruby Application. It offers support for iPhone, Android, BlackBerry, Windows Mobile, and Windows Phone 7.
Rhodes offers support for a Modal View Controller structure allowing you to efficiently separate the content from the presentation and easily make changes to a view (even simply by updating the data structure). Rhodes gives you the starting points for a handful of different views and you can tweak the templates to fit your needs simply by updating the HTML. The Ruby gets compiled down into bytecode to be executed on the device and each view is presented on the given device’s browser rendering engine.
Noteworthy
Rhodes can be paired with RhoSync which is a really innovative way of handling remote data. Essentially, RhoSync handles all the communication with a remote data server and taking that data and downloading it to the device. All your application needs to be concerned with is communicating with local data. This takes care of making sure your app works the same online as it does offline–a major hurdle for many applications. (It’s also worth noting that you don’t have to use Rhodes in order to use RhoSync.)
If you have Ruby developers in house or your site is already built on the Ruby framework, mobile app development will not be too far a departure. It’s worth noting that the version of Ruby that runs on the device is a stripped down version. RhoMobile has not taken every Ruby gem and made it available for use on mobile. That being said, the project is entirely open source and there’s nothing stopping you from taking the leap and implementing the gem yourself.
Some Points of Caution
Rhodes is primarily geared toward data-centric apps–tables and lists and forms. It is definitely more enterprise-focused. You can add JavaScript to your views to make them more interactive, but Rhodes itself is really only concerned with the presentation of data.
Rhodes claims to appear far faster than apps written with an underlying SDK. This may be partially true: much of the logic within Rhodes apps (building the HTML for the view, handling the data downloaded from the server, etc.) are all executed at byte level making them very fast. However, the data is presented primarily within web views (using native components like, tab bars, when possible). The result is an app that has to load and unload a lot of webviews which occasionally causes blank screens while the content is loading.
Score
(scores are out of 3 points)
| Category | Score | Details |
|---|---|---|
| Device Compatibility | 3 | Supports most mobile platforms including iOS, Android, and BlackBerry. |
| Native UI Components | 1 | Its easy to get some native looking elements, but actually implementing the native elements takes extra effort.* |
| Access of Device Features | 3 | http://docs.rhomobile.com/rhodes/device-caps |
| General Performance | 2 | Suffers from an occasional view flicker or white screen. |
| Community | 2 | Pretty active Google Group but not a lot of activity on Twitter. |
| Documentation | 1 | The documentation, while existant, feels very disorganized. |
| Sample Code | 2 | Code samples embedded within documentation; good, clean samples, but good luck finding them. |
| Data Handling | 3 | Only cross-platform framework with full support for an MVC. |
| Animation | 1 | Really doesn’t handle animation; need to use JavaScript for any animation. |
| View Handling | 3 | The MVC structure makes building/managing views a breeze. |
*Update: Adam from RhoMobile gave some helpful information regarding Rhodes support for native UI elements in the comments. While Rhodes doesn’t really hold your hand through building an interface using native controls from the SDK, its entirely possible using Native View Extensions (only supported on iPhone, Android, and Windows Mobile for now) or simply Native Extensions.
Titanium
Titanium Mobile by Appcelerator claims to take your hard won web skills and turn them into mobile app development skills. It boasts support for letting you use JavaScript, HTML, and CSS. It features a JavaScript API that provides access to native UI elements. The magic in Titanium happens during runtime in it’s bridge between the JavaScript and the native SDK. The bridge reads your JavaScript and uses it to build views that have the same features and performance as an application written in that native language. Currently, Titanium Mobile supports iPhone and Android (with BlackBerry support in beta mode for paid subscribers).
Noteworthy
Titanium provides fantastic support for native UI elements. It does exactly what it says it does: you write your view once in JavaScript and then Titanium takes care of building the UI, using the proper UI elements for each platform. Like Rhodes, Titanium has great support for loading in data from a remote server and building a native-looking view based on that data. You could easily get an application with four tabs each with their own tableview of data set up in a matter of hours using Titanium.
Titanium takes the native UI incorporation a step further than Rhodes; Rhodes includes support for native UI elements like tab bars and mapping, but it relies on using the webview for custom views (although a developer could use a native extension to build this capability). Titanium, on the other hand, gives access to almost every native UI element with support for customizing the look. You can easily build an entire app within Titanium without ever having to leave their API.
Some Points of Caution
If you read closely, you’ll find that Titanium takes your JavaScript and makes an app that looks like it was written using native code. Your JavaScript is compiled to “symbols” and then the the SDK compiler combines the symbols with the Titanium API. While much of the code is mapped to the native code (like the interface elements), there is still an interpreter that handles dynamic code.
Without complete control over how these elements work together and the ability to manage when things are removed from memory, occasionally a view may appear blank while it’s loading. This definitely detracts slightly from the native feel. As always, there are ways to work around it, but you may find yourself spending a lot of time trying to get your app from really good to great.
Score
| Category | Score | Details |
|---|---|---|
| Device Compatibility | 1 | Only works with Android 2 and iOS; doesn’t work in Honeycomb. Support for BlackBerry in beta. |
| Native UI Components | 3 | Supports nearly every native device UI component. |
| Access of Device Features | 3 | Provides JavaScript abstraction for all the common features; includes some lower level network control. |
| General Performance | 2 | Occasionally suffers from blank views while loading. |
| Community | 2 | Active community (although a handful of questions go unanswered). |
| Documentation | 3 | Great API documentation. |
| Sample Code | 3 | The Kitchen Sink app is a great example of all the features of Titanium. |
| Data Handling | 2 | Easily parse through JSON and XML support is pretty good; easy to build views based on data. |
| Animation | 2 | Can animate most UI elements, but don’t expect very advanced animations. |
| View Handling | 3 | Effortlessly manage and customize different views of the application; each window can have its own namespace. |
MoSync
MoSync takes a different approach to cross-platform mobile development in that it doesn’t use web technologies at all. It has it’s own SDK built with C/C++ that gives the developer access to many of the standard C libraries, graphic and media classes, the networking layer, native UI elements and more. At this point, it offers support for the Java ME environment, Windows Mobile, Symbian S60, Android, iOS, and Moblin/MeeGo. BlackBerry and Windows 7 support is coming soon. Just like RhoMobile, MoSync is more enterprise focused and you won’t find a lot applications in the app stores built with MoSync.
Noteworthy
MoSync provides a device profile database that documents the specification, features, and even bugs of specific devices. MoSync integrates this database with the preprocessor so the developer can easily specify code that will only be included on devices that support given features–this is a lot more efficient than a check during runtime for feature support.
MoSync also approaches the simulator differently. One of the rules of thumb of mobile development is always test on the device because you can’t trust the emulator. MoSync approaches the problem differently with their emulator (MoRE). Instead of trying to replicate the device in the emulator, MoSync uses the emulator as their standard and tries to get each device match that standard. Furthermore, MoRE actually can read presets from the device profile database and emulate screen size, available memory, etc. This is a really innovative solution to the inconsistent results that were always present between the emulator and the device…however in order for it to be worth anything, MoSync will need to continue to be really strict on conforming each device to this standard, otherwise we’ll be right back where we started.
Some Points of Caution
The other frameworks make it a selling point of how easy it is to build an app and release it. MoSync really focuses itself on the feature of having a single code base. You may not initially make it to market as fast with MoSync, but your code will get more mileage out of it.
Score
| Category | Score | Details |
|---|---|---|
| Device Compatibility | 2 | Doesn’t have full support for BlackBerry; iPhone support is still limited in some regards. |
| Native UI Components | 1 | Only supports iPhone and Android; doesn’t work in MoSync emulator. |
| Access of Device Features | 1 | Supports some lower level network control, but no support for accelerometer or camera in most phones. |
| General Performance | 3 | Runs smoothly; get a lot of control over how fonts are rendered to the screen. |
| Community | 1 | Hardly any Twitter activity; a lot of registered users in forums, but not a lot of posts. |
| Documentation | 3 | Lots of documentation about framework and an excellent API reference. |
| Sample Code | 2 | Provides a decent amount of sample code; could really benefit from a “Kitchen Sink” type app. |
| Data Handling | 1 | Contains XML parsing libraries, but lacking support for JSON or other data formats. |
| Animation | 2 | There are plans to include support for OpenGL; because its written in C, there is support for some drawing and simple physics libraries. |
| View Handling | 1 | Doesn’t provide support for an MVC; requires a little extra effort to create views for data. |
PhoneGap
PhoneGap wraps a mobile web application exposing access to device features through a consistent API; it uses JavaScript as an abstraction layer between your mobile Web app and the device. PhoneGap currently supports iOS, Android, BlackBerry, webOS, Windows Mobile, Symbian, and Bada.
Noteworthy
The community for PhoneGap is impressive. I’m not referring to size so much as I am referring to the rate of growth. 4928 posts in 2009, 9561 posts in 2010, and already, as of the first week of July in 2011, there are already over 9000 posts for this year. This is just a picture of the PhoneGap community and how fast it is growing. If you decide to jump into PhoneGap, there is a very vibrant community waiting to help you.
PhoneGap uses straight up HTML/CSS/JavaScript. There is no interpretation of your code (generally makes for less unexpected results on different platforms); PhoneGap literally loads your app into a chromeless web browser. Further, the PhoneGap API runs on a very extensible plugin architecture. If PhoneGap doesn’t already support the feature you need, you can easily write a plugin yourself (in fact, there’s a good chance its already been written and is available for you to download).
Some Points of Caution
Don’t expect to write a web app that works beautifully on your desktop browser and to be able to drop it onto your phone and have it run the same way…especially if you’re trying to use JavaScript-based animations. We’ve had a lot of experience in working with optimizing mobile web apps so take a look at some older posts on the blog for some more help with that.
Furthermore, PhoneGap does nothing to emulate the native device UI (although, as always, there are plugins and customizations that bridge this gap a little bit). You could emulate the UI with HTML and CSS but what we’re finding is that a lot of people build their app for the iPhone, and then use the same UI on the Android. The iPhone UI makes no sense to an Android user. Don’t do that.
Score
| Category | Score | Details |
|---|---|---|
| Device Compatibility | 3 | Supports most common OSes including iOS, Android, and BlackBerry. |
| Native UI Components | 0 | No native UI support. There are forks that do offer some support, however. |
| Access of Device Features | 3 | JavaScript provides great abstraction class for all common device functionality. |
| General Performance | 3 | PhoneGap itself performs great; performance issues arise from poorly written apps and slow devices. |
| Community | 3 | Very vibrant community; lots of activity on forums, Twitter, and blog articles. |
| Documentation | 2 | API reference has gotten a lot better; could still stand to clean up wiki. |
| Sample Code | 2 | Good sample code for PhoneGap API, but not a lot of support from PhoneGap for building good mobile apps. However, there are plenty of blog articles. |
| Data Handling | 1 | Left completely up to JavaScript and device’s implementation. |
| Animation | 1 | CSS animation works great on iOS devices; leaves a lot to be desired elsewhere. |
| View Handling | 0 | Completely in the hands of the developer how the app is going to manage views. |
Conclusion
Below is a summary of each platform and whether it offers adequate support for a given area. (Scored 2 or better in that criteria)
| Category | Rhodes | Titanium | MoSync | PhoneGap |
|---|---|---|---|---|
| Device Compatibility |  |  | | |
| Native UI Components | | | | |
| Access of Device Features | | | | |
| General Performance | | | | |
| Community | | | | |
| Documentation | | | | |
| Sample Code | | | | |
| Data Handling | | | | |
| Animation | | | | |
| View Handling | | | | |
The first step in choosing a mobile cross-platform framework is determining the needs of your app. If you’re looking to make a app that simply presents data in lists and detailed views, take a look at Rhodes or Titanium. If you’re looking for some more advanced control over views and how content is being drawn to the screen, take a look at MoSync. If you’re looking to build a custom interface that can take advantage of your Web development skills, take a look at PhoneGap. These are definitely not hard and set rules–just guidelines to help you make an educated decision. It’s also important to evaluate what skills you have. If you’ve never touched Ruby before in your life, Rhodes may not be the best direction.
Although gaming was out of the scope of this post, there are even more mobile cross-platform frameworks out there, like Corona, Unity, or even Adobe AIR, that are more tailored toward games. They provide more timeline or scene-based development. It all depends on your needs.
We’d love to hear about your experience with these mobile cross-platform frameworks and hear about some lessons learned or other tips.
Related posts:
‘Make no mistake: your app is not translated to Objective-C or Java, it is run through a bridge that builds views using the native interface elements for the device at runtime’
This is completely wrong – Titanium compiles your Javascript to a native Objective C or Java project; the iOS project can be opened, modified and debugged in Apple’s Xcode or and it’s the same for an Android Java project.
Steve-
Thanks for helping me clarify that point as I did misspeak (and it is now fixed in the post). In the case of the iPhone, Titanium compiles your code to symbols–not Objective-C code. Titanium uses the symbols to determine what parts of the API your app depends on; much of the code is mapped to the native code, but there is still an interpreter that helps dynamic code work. I did not mean to imply that the code was left as JavaScript–it is compiled down to symbols (or class files for Java). However, as far as I know, you can’t edit the Objective C code that your JavaScript was mapped to–you can only edit the JavaScript. So debugging in Xcode isn’t really going to help as much as a native app since it will only be able to tell you the symbol the error occurred in…not the line of code.
Those ‘blank’ dots for PhoneGap are things not address by the framework, that is not what it is designed to do. It acts purely as a bridge to device capabilities through JavaScript.
However if you wish to have nice view/animation/data handling/ui look, wrap a SenchaTouch app in PhoneGap.
The problems with all these frameworks is that you are at the mercy of the framework to support *any* new functionality. As an example: right now iCloud APIs are available to all iOS developers, everyone else is going to have to wait, depending on your market that may or may not be an issue, but it is worth noting.
I also see cost as important when looking at any cross-platform development solution. It would have been nice to see that addressed.
Thanks for your point Kevin–there are some aspects of cross-platform development that not every framework attempts to cover. In the case of PhoneGap, it has a specific purpose: to let you build a mobile web app and give it more capabilities than a standard web app by exposing more device features.
Exactly, so rating it on Native UI Components, Data Handling, Animation and View Handling is moot.
I suppose I should have made clearer that I’m not attempting to rank one mobile framework higher than another overall (that’s why there aren’t “total scores”); its attempting to show that different frameworks excel in different areas and the best choice is entirely dependent on your needs.
For example, PhoneGap would likely not be the best choice for someone who is looking for a fast way to get to market for iPhone and Android with a native-feeling interface, so it scores low in that regard.
I’ve developed an app using Phonegap – beware – there are many pitfalls on all platforms. Be prepared for dozens of trivial quirks (not necessarily the fault of phonegap, often the OS’s quirks). I got the app working in iOS and Android, but Blackberry was a different story. IMHO Blackberry development with phonegap isn’t worth the hassle.
@Daniel – No worries, and sorry if that sounded too negative – I found the post really useful.
I am the new tech writer at Rhomobile, and I would like to improve the docs. Could you send me an email? Although I could make a good guess at what you feel is “disorganized,” I’d like to get your suggestions and opinions. Thanks.
I am also at davstrom@mac.com.
Thanks for your thorough review. It should really help all of us in this space and customers too of course. Was great to see your appreciation of the value of MVC. Was surprised to see the “1″ in native UI. You can actually use any kind of native control using a Rhodes “native view extension”. That said, we believe that with modern styling libraries such as jQuery Mobile and Sencha available UIs done with the webview (but of course in a native app and surrounded by tabbars, nav bars, and toolbars) creates actually BETTER user interfaces.
Also have you looked at the Rhomobile docs page recently (http://docs.rhomobile.com)? Take a look. We have been making a huge priority of documentation expansion and revision lately.
I’m surprised to see “animation” warrant its own top level category. If the intention is for this to be used in building highly interactive games then no, that isn’t really the focus of Rhodes. Nevertheless we do have a webinar that shows how to do 2D animation with the HTML5 Canvas object. Which means it isn’t quite “just write it yourself with JavaScript”.
We have seen occasional apps that have a lot of JavaScript libraries with “view flicker” (caused by the delay in loading those libraries). We have not seen this with lighter weight libraries (such as jQuery Mobile). We are switching the “default shipped styling library” to jQuery Mobile (from jqTouch) in Rhodes 3.1 later this month. I hope you will consider reexamining a few of your assessments then.
Overall, great review. Its clear that you really tried the products in question and have a deep appreciation of the problems that they are trying to solve.
Thanks for your comment, Adam.
To explain a little more about the score for Native UI controls: As I used Rhodes, I was comfortable its implementation of the native view extensions and was appreciative of the fact that I could even use an Interface Builder file for an interface if I wrote the native extension. However, I got the sense that using native controls from the SDK is not the core focus of Rhodes. There is something to be said for being able use the interface elements from the native SDK (the actual elements…not just styled HTML) and Titanium definitely wins in this regard. Again, not every app needs or even wants the native controls from the SDK, but for those that do, its worth delineating the difference in implementation between Titanium and Rhodes.
I’m glad you asked about animation. I was not referring to animation with gaming so much as interface animation. In my opinion, simple animations to callout changes in the interface is a big part of mobile. Sure, there’s the standard pushing and popping views or the sliding up of a modal view controller (which Rhodes handles fine), but some of my favorite apps have a lot of subtle animation in their interface. Rhodes itself doesn’t seem to give any support towards that. A developer could of course use CSS3 or the HTML canvas to do some of these things, but the developer will likely run into cross-platform performance issues. However, I recognize that this doesn’t necessarily doesn’t fall within the scope of the Rhodes framework and that Rhodes expects users to take advantage of the features of HTML5 and CSS3 to achieve some of these visual effects.
Daniel, awesome and very detailed post about Cross-Platform.
Have you ever considered haXe? http://haxe.org/doc/intro
There is a awesome community support behind haXe and pretty much any target supported with some really interesting outputs out there that people are creating. From the iPhone to HTML5 (WebGL too) including Flash applications.
Hi Daniel
Thanks for a good post. Our MoSync team has worked day and night to improve on the thinks you point out.
You can now use HTML5/JavaScript with MoSync. So if you are a developer you no longer have to choose between HTML5 or Native Apps. If you want to use 100 % web technologies you can do that.
Making HTML5/Native apps with MoSync makes development very flexible. You can mix and match pretty much any way you want.
I hope you try us out again
Just a quick thank-you for this excellent write-up. This is just the info I needed.
_j
That was a very thorough review. Thanks!