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.

That requirement is starting to fade, though, as new toolkits and development platforms make it possible for programmers to avoid studying Objective C to create iPhone applications. The frameworks take code written in languages like good, old-fashioned JavaScript or newfangled Ruby and give the user complete control of the screen, just like a native application. It still makes sense to learn Objective C if you're programming a fast-moving 3-D game or something that wants to squeeze every ounce of performance from the battery-powered wonder, but everyone else can avoid returning to school now.

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. ]

Rhodes, PhoneGap, Titanium, and Corona are all good tools. Although there are differences in capabilities, your choice will probably rest with the one that supports your favorite language. That's the entire point of working with these frameworks. If you know JavaScript, Lua, or Ruby, you can create something on the iPhone very quickly.

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.

PhoneGap comes as a ready-to-run project that pops up a UIWebView object and points it to the index.html file you've created. You do all of your programming in HTML and JavaScript. The iPhone version of WebKit buried in UIWebView lets you browse through the files.

This solution is not as powerful as the Ruby client-server bundle from Rhomobile. There's no place to put the "server side" code, and the operating system acts like a very dumb Web server. This is not as limiting as it may seem if you can code all of your business logic in JavaScript, but it'll be difficult to turn the result back into a classic Web application. The protected code that would normally run on the server alone is now blended with the client code in JavaScript. If there are few concerns about security and fraud, you'll be satisfied with your iPhone application. But it's not simple to write something for both the Web and the iPhone.

The PhoneGap project is written in Objective C, but it loads your HTML and JavaScript to a UIWebView object.

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 project relies on the WebKit implementation for much of its cross-platform success. Both Android and the iPhone rely on the same open source toolkit to render HTML. The earlier versions of the BlackBerry don't use WebKit, so if you're targeting these BlackBerrys, you'll need to rewrite your JavaScript to handle cross-browser issues. It's probably easier to just limit your applications to BlackBerry OS 4.6.

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.

Appcelerator Titanium If the idea of developing your application in HTML and JavaScript appeals to you, there's no reason to limit the fun to smartphones. The Titanium platform from Appcelerator comes in two flavors: the mobile version for handsets and a desktop version for Windows, Mac, and Linux. The two platforms aren't exactly the same, though, because the desktop version lets you write code in Python and Ruby, but the mobile version only accepts JavaScript.

Appcelerator also makes the claim that "~200 Lines of Code, 0 Objective-C" in its demonstration application somehow produces "1 Native iPhone app." This claim to produce iPhone-native apps may be a bit truer than with the others because the system is meant to be more than a mirror of Web development. While PhoneGap is designed for Web browser developers, Titanium includes a number of exclusive packages. You may be writing JavaScript, but much of what you're doing is stringing together objects from the Titanium namespace. The application I built with PhoneGap could run in most modern Web browsers, but the one I built with Titanium needed the Titanium libraries.

These libraries are much more extensive than those in the other frameworks. If you want to add any of the standard menus or window-swapping tools common on the iPhone, you need the features in the Titanium library. There are tools for creating windows, menus, and all of the common widgets. These routines behave like iPhone widgets should, too. When you open up a new window, the old one scrolls to the left and the Return button appears. It's quite professional and took me only seconds once I looked at the sample applications -- a ridiculous fraction of the time I've spent laboring to develop the same level of polish with HTML, CSS, and JavaScript before. (With Titanium, you'll rely heavily on the sample apps. The documentation is a bit simple and doesn't include much description of the parameters.)

Titanium lets you string together native iPhone components with JavaScript.

The role of HTML and CSS here is a bit diminished. While you can certainly mark up pages in HTML and use all of the AJAX tricks with your pages, the simplest solution is to avoid it. Many of the examples from Appcelerator begin with HTML files that include just a few lines that fire up the JavaScript that does the real work. If you write CSS, it will affect the HTML that you add but not the controls created by Titanium. They'll follow Apple's UI guidelines. I wouldn't be surprised if the CSS file in your project is completely empty and the HTML has just a few lines that invoke the JavaScript.

Much of this could change in the near future because the mobile platform is still in a closed beta program. The company is rolling out new features frequently; it added a number of new widgets in version 0.5 released just a few days ago. The latest includes access to the accelerometer, the camera, and the geolocation data, all available in JavaScript.

The current version produces applications for only the iPhone and Android, but the structure should allow Appcelerator to move to other platforms in the future if it so chooses. The fact that Titanium can work directly with JavaScript instead of HTML and CSS means that it may even port neatly over to older phones that don't use WebKit. That's speculation, though. Appcelerator's road map is clearly focused on the iPhone and Android.

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.

The Rhomobile, Nitobi, Appcelerator, and Ansca tools make it dramatically faster to create applications. The results are often more standards-compliant than using Objective C, but like any other tools, how you use them varies. If the App Store reviewer enjoys the final app, the odds for success are much better. By making it easier for JavaScript, Ruby, and Lua programmers to concentrate on designing the app, not learning a new language, these tools offer a head start.