Back in March, I posted my Thoughts on Titanium, which we were using at the time to develop Texas State’s iPhone application. Since that time, we’ve become increasingly frustrated with the system, and have finally decided to leave it behind and rewrite the application in a combination of native Objective C code and HTML/CSS/Javascript.

This isn’t a decision we made lightly. I actually resisted it for a number of months, even when some of the other developers on my team were lobbying pretty strongly for it. The promise of Titanium, which allows developers to use Javascript to create native applications for iPhone and Android platforms, was great. Unfortunately, it has never lived up to that promise for us.

The first reason we decided to leave it behind was Apple’s Developer Program License Agreement. When iPhone 4.0 was released, the Agreement was amended to prohibit using intermediary layers like Titanium. The folks at Appcelerator quickly moved to quell their customers’ fears, pointing out that Apple was still approving Titanium-made applications. While it is true that Apple hasn’t lowered the boom yet, these apps still violate the letter of the agreement, and could therefore be pulled from the App Store at Apple’s whim. Further, when RunRev, a company that creates a development tool similar to Titanium, tried to reach an official understanding with Apple, Steve Jobs made it very clear that Apple wasn’t interested. Given this level of hostility to other development tools, staying with Titanium would obviously increase the risk that we’d run afoul of Apple in the future.

The second, and more important, reason was this: Titanium’s engineering is just not good enough for our purposes. It works great for small-scale projects that people want to get done quickly. But as we have tried to build large-scale projects, we have repeatedly run into problems that we would spend hours trying to solve, only to find that there was an issue in Titanium’s code that we couldn’t work around. New versions of the software would cause portions of our code that had worked fine before to stop functioning. Version 1.4 of their framework was released well over a month after they had originally promised it.

As one of the programmers on my team put it: “When I work in [another development environment], I’m 99% sure that any problems I have in my program are because I’m doing something wrong. With Titanium, I’m only about 50% sure.”

To be sure, the folks at Appcelerator have taken on a huge technical challenge, have ramped up quickly, and are working as hard as can be to make their product feature-rich. But after months of frustration, we’re not willing to keep investing in a system that keeps us so far from our programming happy place. Objective C, here we come!

I’ve had intermittent access to an iPad for about two weeks now through work, and finally feel like I have a grasp on what it is, what it’s good at, and what it lacks.

First off, the iPad doesn’t do everything. It’s not a full-on replacement for a computer. In fact, you can’t even get it running without a computer to which you can connect it. It lacks a camera, so you can’t use it for videoconferencing or photography. While it’s better for content creation than the iPhone, thanks largely to its bigger screen and support for Bluetooth keyboards, it includes no facilities for printing out the content you do create. For that, again, you’ll have to rely on a computer.

That said, it does 90% of what people use a laptop for, and does that 90% beautifully. Web surfing is a smooth, fast delight. Dealing with email goes smoothly and quickly. The Calendar and Map applications are lovely to look at, and a pleasure to use. Listening to audio and watching video, while hampered a bit by the monophonic built-in speaker, is likewise a pleasure. The vibrant high-resolution screen makes it great for showing off photography. (In fact, I’ve already heard of a graphic designer friend-of-a-friend who got a job because he’d loaded up his portfolio onto the iPad to show it off.) Writing works great, especially with a hardware keyboard. And of course, there are a wealth of applications designed for the platform that make it even more versatile and capable.

Is it for the person who likes to tinker with computers? Probably not so much. Apple takes great pains to keep the iPad and its related platforms, like the iPhone and iPod Touch, locked down and controlled. On the other hand, this is a device I could give my Mom and expect her to actually use it. If one wants to do the things the iPad does, there’s not much way to do those things better, faster, or more intuitively.

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