I had a similar experience. I built a iPhone app using the Titanium platform, and decided against releasing it in favor of rebuilding it in Objective-C. I was able to work around the lack of correct documentation, platform inconsistencies, and software bugs for the most part, and was able to get the software to run consistently and reliably on my iPhone 4, but it would randomly crash on iPhone 3's, and iPod touches. The issues seemed to be related to memory management and/or threading. Ultimately, I felt that I would be spending just as much time fighting with the middleware as I would spend writing Objective-C library code, and I would actually be able to debug the library code.

I still value the work I did on the Titanium platform from a prototyping perspective. It did allow me to quickly try a number of things that didn't work, and come upon a workable design. If I could do it over again, I would still prototype with Titanium until I had a design, then port to Objective-C before I actually made things work in Titanium. You can get acceptable performance out of Titanium, if you have a knowledge of the way the underlying SDK works. For example, because I had implemented iPhone and iPad app's before with Objective-C I was able to write the code so that it conformed to the underlying sdk assumptions, in particular tableview code performance wasn't as much of a problem for me as it was for many others because I was aware of how the middleware was likely transforming the code, and was able to construct it to maximize cacheability. I suppose with some platform familiarity and a very simple app, Titanium could be workable.

The decision to port had a couple of other advantages, chiefly that it allowed access to some of the open source mobile plugins that are quite useful, like ShareKit and some of the Augmented Reality code, along with deeper integration and better performance. Switching to Core Data seemed to be reason enough to port.

In the long run, I hope that Apple sees that there is a demand to develop iOS apps in languages other than Objective-C. I would estimate 95% of the iOS code I have written has not been performance sensitive, but has been glue code tying chunks of Apple's SDK together or IO bound background networking code. Being able to use a less verbose language with an extensive standard library and strong C bridging like ruby would speed development without seriously harming performance since sensitive code could still be written in Objective-C.