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.

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.

Microsoft Opens Mobile App Store to Developers

Apple Preps iPhone SDK Release: Users Hope for Brawnier Business Apps

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

1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams