When Apple opened up the iPhone to developers, O'Reilly books noticed a big jump in sales of its long-neglected titles on Cocoa and Objective C. These elegant dialects never caught on outside of Apple, but when the iPhone SDK appeared, the world started studying up again. If you want to work in Rome, learn Latin.
The toolkits also offer a promise of cross-device development, a process that is both surprisingly efficient and a source of endless little disappointments. In theory, your software will run on an iPhone, a BlackBerry, an Android handset, and in some cases even a Symbian phone or a Java ME phone. In practice, the fonts are never exactly the same and little glitches appear from time to time. If you write your code with big strokes, the pictures will look the same, but anyone who frets over the details will find plenty of struggle.
I took four of these toolkits -- Rhomobile Rhodes, Nitobi PhoneGap, Appcelerator Titanium, and Ansca Corona -- out for a spin, wrote some code, and came away certain that it was easy to create menu-driven mechanisms for browsing data using any of them. If you want to give the user a nicely tuned interface for a database, it's pretty simple to whip together an application in no time.
[ If you are unable to view the table and screen images in this article, please click here. ]
Rhomobile Rhodes If you love Ruby or have Ruby code to port, then Rhomobile's Rhodes framework is a good path for bringing your code to mobile platforms. Rhomobile bundles a byte code version of your code with a tiny Ruby interpreter (version 1.9) to produce "native applications." Rhodes supports all of the major platforms, including iPhone, BlackBerry, Windows Mobile, Symbian, and Android, although I only looked at the iPhone result.
It's probably not worth arguing whether a byte code interpreter is truly a native application; that debate is best left to computer science theoreticians. They're certainly more native than Web applications running on the local browser. They usually behave with as much snap as a truly native package, so practical people don't need to worry much about this argument.
The Rhomobile development process is just like building a Ruby on Rails Web application. The phone is both server and client. It has a split personality and is always talking to itself.
The Ruby on Rails developer will feel right at home. You craft your user interface in HTML with embedded commands in .rb and .erb files, then fire them off by typing rake in the command line. You can also use Xcode on the Mac and Eclipse when developing for other platforms. The Rhomobile scripts compile the Ruby code, bundle everything together into an application, sign it, and fire up the simulator for you. The interaction and debug cycle is pretty quick.
The database is not MySQL or an embedded database, but Rhom, an object mapping tool with some basic queries. It's not unlike some of the stripped-down databases like CouchDB that are becoming common. Rhom runs on the phone itself, but it interacts with RhoSync servers using AJAX calls, a technique that allows the local database to back up and update itself with distant servers. This RhoSync tool is also a Ruby on Rails application that you can install on your server. It can serve data to Rhodes applications.
I struggled through several basic glitches on my Mac. The application was pretty sensitive to the characters used to end lines, a problem that went away once I forced my editor to go with Unix endings. There's also no simple mechanism for handling 404 errors. The application just crashed whenever it couldn't find a page. It works better if you stay within Xcode. But I found work-arounds for all of the glitches and built some simple applications without problems.
While the goal is to build a home that will be very familiar to the Ruby on Rails programmer, the Rhomobile world is not the same as Rails. If you love to do clever meta programming using the eval instruction, you'll be frequently thwarted because Rhomobile bends over backward to prevent developers from adding new features or functions. Apple wants to thoroughly scrutinize each application before it launches, and functions like eval make it impossible to, well, evaluate the code beforehand. So Rhomobile has left eval out of the Rhodes framework.
Rhodes is also a bit lighter than many of the traditional Ruby on Rails frameworks. Rhomobile left out XML and Web services, for instance, to save space. After all, the application you create is constantly talking to itself, so there shouldn't be the same need to work with outside standards. If there's no XML parser in the client layer, then don't use XML on the server layer. Tags are the equivalent of arteriosclerosis here.
Rhomobile is also adding new features that let the Ruby/HTML programmer interact with the iPhone's capabilities. It's built out the links to the geolocation information, the contact manager, and the camera. The date/time manager and the ring tone manager are coming.
You can build Rhodes apps from the command line with rake, but I found that the Xcode integration was easier to use.
Keeping the client as light as possible makes sense in the resource-challenged environment where every parse sucks away precious battery life, but it undermines one of the features. If you have pre-existing Ruby code that uses XML, you'll need to work a bit harder to port it to the iPhone. It's not always simple. You might be required to integrate an XML parser or strip out XML formatting code.
The Rhomobile tools are just the beginning. Rhomobile is also building RhoHub, a hosted development environment that lets you create smartphone apps on the Web.
The Rhodes framework is a great tool for Ruby programmers, and it may even be a good option for someone who isn't familar with Ruby. While I encountered a number of rough spots, the integrated server mechanism can be tempting enough to force someone to learn Ruby. And though the cross-platform promises are just meant to ease porting to the various smartphones, you should be able to move your applications to the general Web with little trouble.
Rhomobile is gradually emerging out of the early beta-like stage and setting prices. As version 1.2 is released, the company will set a firm price for creating an application with Rhodes and a price for linking it to a RhoSync server.
Nitobi PhoneGap The PhoneGap open source project started as a bit of a hack by some programmers at Nitobi, but it quickly attracted enough attention to make it a real competitor. The folks at Nitobi are working on both enhancing the open source version and finding a way to add commercial features.
The PhoneGap project does pass through some of the data that wouldn't normally be available in the iPhone 2.0 browser. The newest version of Safari has built-in connections to the geolocation data -- which PhoneGap included before it was available. PhoneGap also hooks into all of the major parts of the iPhone API, including SMS, contacts, raw files, the camera, and the accelerometer.
The PhoneGap project knits together a good number of programmers with a wide range of talents. Most of the activity is devoted to the iPhone, although there's some focus on Android and the BlackBerry.
The biggest problem with using PhoneGap is the way that Apple will reject some but not all applications developed with it. (Check out my experience.) Many programmers feel that Apple rejects the PhoneGap code almost automatically, accusing PhoneGap apps of linking to some private APIs or somehow misusing UIWebView. Many theorize that Apple may just be trying to cripple cross-domain development. No one can be certain, but there is a long list of accepted iPhone applications that began with the PhoneGap starter project.
Ansca Corona At this writing and perhaps for a long time to come, Flash code is ignored by the iPhone. Flash developers, though, now have a way to put their scripting skills to use on the iPhone: by using Ansca's Corona SDK. You write Lua, and Corona turns it into an iPhone app.
This framework may be the most accessible to many Flash and game developers because Lua is often used in these worlds. Flash Lite games, for instance, should translate relatively easily, although adapting them to use the accelerometer and the multitouch screen will take some work. The Lua language includes a number of basic features that makes animation simple.
Ansca adds several new features to the language designed specifically to help animators. The transition and easing methods will help calculate all of the positions for tweening objects in the display, something that helps set up animations. It won't handle complicated curves, but it will work with linear, quadratic, and exponential transitions.
The framework handles all of the details of initializing OpenGL and the Objective C, making it easier for Flash programmers to create iPhone applications without learning about pointers or malloc. Not every part of OpenGL is available through Lua, though. Three-dimensional extensions are still in the planning stages. You're limited to 2-D games, just like most Flash developers.
Corona's Lua is made for sending sprites dancing across the screen.
The event code is also focused on single touches. Every object floating across the screen can have its own event listener that makes it simple to detect a hit, but there's no mechanism to handle multitouch events like pinching and spreading the fingers. Ansca is also still experimenting with distinguishing between dragging and tapping events.
I think that the developers of casual games will love this tool because these games are usually coded in Flash and limited to two dimensions. While some developers might want to wait for full three-dimensional access to OpenGL, I've found that my favorite games on the iPhone are limited to 2-D. While the screen resolution is wonderful, it's not good enough for realistic 3-D; depth can only be fudged by having objects move. It's funny, but my favorite games on the iPhone tend to look like the arcade games from the '80s. If that's what you want to create, you can do it quickly with Corona.
Four good tools The amount of success you'll find with any of these frameworks depends entirely on what you're trying to do. None of these SDKs is ready to produce something as sophisticated as Super Monkey Ball because all of them are limited to two-dimensional applications. If you want 3-D, you'll have to do much of the work yourself.
They also require a certain amount of overhead, and this slows down the applications, although not as much as you might think. The developers of Corona, for instance, are paying close attention to the size of their interpreter. They are proud of the fact that it is only 200KB, dramatically smaller than Flash in part because it doesn't have the same need for backward compatibility.
Corona is probably the best bet for two-dimensional games. I wouldn't want to tackle many games with PhoneGap, Titanium, or Rhodes, although a sophisticated AJAX hacker would be able to do anything that could be achieved with a browser.
PhoneGap, Titanium, and Rhodes are best for letting the user page through menus to browse databases filled with information. They handle many of the basic animations and transitions, and you provide the data and the basic layout. These frameworks are also good if you want to produce an Android application at the same time. Rhodes currently promises the most cross-platform support, although I wouldn't be surprised if PhoneGap and Titanium start catching up.
It's still too early to make a decision based upon price. Neither Corona nor Titanium are quoting costs yet. PhoneGap is an open source project with sponsor Nitobi standing ready to offer professional support. Rhomobile Rhodes is free if you distribute all of the source code to your application with version 3.0 of the GPL. If you want to retain the source code you write, you can buy licenses based on a percentage of revenue. Enterprise users can also buy licenses by the seat.
The technology itself is solid and very functional, but the politics are complicated and shrouded in secrecy. Emulating one language in another is an old trick that programmers have been using since the days when punch cards were bigger than the iPhone. But even the keepers of the mainframes in their air-conditioned temples didn't enforce regulations like Apple does, and these rules are the trouble.
No one knows what Apple is afraid will happen if a user downloads new software for the emulator without Apple's permission, but it's clear that the SDK requirements forbid developers from adding new features or grabbing new code from the Internet. The company routinely rejects some but not all of the applications that use emulators. (Again, see my personal tale of rejection.)
The companies behind the products in this review are taking different tacks. Rhomobile embraced Apple's goal of thorough testing and stripped out the eval function from the Rhodes implementation of Ruby's interpreter. The company has also worked closely with Apple to make sure that the applications built with its tools can't change their functionality. Rhomobile says it's had no trouble with rejections as a result.
Some of the developers using PhoneGap have started campaigning publicly in hopes of getting Apple to understand the advantages in the PhoneGap approach. For instance, read about developer Mike Nachbaur's initial and subsequent dealings with Apple's App Store.
There are counterarguments that frameworks like these speed the approval process by reducing the chances of your inadvertently implementing a user interface that violates Apple's guidelines. Objective C developers often run aground when they try to do something themselves and find that their own solution isn't correct. (See Jared Brown's story, App Rejected, and the Macworld forums for examples.)
Programmers using toolkits like these don't make the same beginner's mistakes. While Objective C is quite a nice language, it's also not clear that it's the right tool for anything but high-performance games. Pointers are dangerous items even in the hands of excellent developers. Memory management and threading can be quite confusing. These toolkits remove many of the land mines from the paths of the developers and save them some grief. The software industry builds layers like these because they make everyone's life easier. Emulators and methods like eval are excellent tools. Apple would do well to open themselves up to a wide range of modern languages.