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 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.
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 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.
(scores are out of 3 points)
|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.|
|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 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
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.
|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.|
|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 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.
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.
|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.|
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.
Some Points of Caution
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.
|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.|
|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.|
|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.|
Below is a summary of each platform and whether it offers adequate support for a given area. (Scored 2 or better in that criteria)
|Native UI Components|
|Access of Device Features|
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.
If you are trying to decide which cross-platform framework would work best for your organization’s next mobile learning application, feel free to contact us by selecting the button below.