iPhone development tools that work the way you do
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.
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.)