A couple months back, my team at work started working with Appcelerator’s Titanium, an open-source system for developing iPhone applications that, instead of requiring one to learn Objective C, wrapped up the iPhone APIs so that they could be accessed from familiar web languages.

The version that was current at that time made it very easy for people with web development backgrounds to create native iPhone applications. It did so by opening a web view for every screen of the application and then letting one author HTML, CSS, and Javascript that ran within that context. By layering native controls on top of those web views, one could make decent-looking applications quickly in a way that was intuitive for those of us who live and breathe these technologies already.

Unfortunately, this was not an efficient approach. Having so many web views in an app caused it to run slowly and take up a good deal of memory. Additionally, apps written with HTML/CSS instead of more traditional methods tend not to look quite right, since they make less use of native controls and use more web-like design.

Appcelerator’s solution? With their latest releases, they’ve changed the architecture pretty dramatically. Instead of basing everything on web views, applications now use native controls exclusively, only falling back to web views when you’re actually doing something on the web. The application UI is created entirely in Javascript, and HTML and CSS now have very little, if any, place in an application.

The upside to this is that performance has been improved by an impressive amount. Apps written in Titanium are generally as responsive as apps written directly with Objective C and Apple’s tools. Additionally, all of the UI elements are now dynamic, so that one can make adjustments to on-screen objects at any time — not just when a window is initially rendered. Managing the scope of variables makes a lot more sense in the new version than it used to, and requires far fewer chintzy hacks to pass data from place to place.

The downside, sadly, is that Titanium loses a portion of the ease-of-use that made it attractive for us to begin with. All of the UI we had done with HTML/CSS now has to be rewritten using native controls, which are a good deal more cumbersome. Essentially, one is writing much more directly to the iPhone API, but just using Javascript instead of Objective C to do so. (Which is still a win, in my book, as I have a pathological hatred of having to manage memory for myself.)

We’re currently pushing forward with the transition to the new way of doing things, and probably have about 40% of our prototype app rewritten for the new system. The new version feels generally tighter and more professional, but is definitely taking longer to write than was the case with the old methods. And while I’m still very impressed and happy with Titanium as a product and feel that the tradeoffs were the right ones to make, it does now feel much less like iPhone programming “for the rest of us.”