Appcelerator Titanium: From a developer's perspective

I've used the android API 2x. I think it's quite rough to get Titanium installed, it's easy to misconfigure, and it's not a huge pile of time saved over just writing the logic twice. Just give up if you think you have to instruct a 3rd party on how to configure android + titanium on mac. It's a beast.

It feels like there isn't anyone there on the forums. I'm sure as hell not going to pay 2k+ a year to experiment further when the documentation is shoddy (it rarely explains what things do, I had to read source to get doc on the video player).

And the dashboard project doohicky is stupid as hell. Just make some command line tools already, or really really commit to a GUI that works well and supports things like rename. I shouldn't have 4 projects named the same thing because I didn't open an XML file myself and edit it.

If I really need crossplatform whatsits, I'm thinking flashbuilder or that ilk at this point. Titanium did not impress.

There's a difference between reading it and accepting it. More and more people are moving away from JSLint because of the Cry Wolf syndrome - real errors hidden in a sea of warnings based only on the "opinion" that they tend to be harmful coding style.

https://github.com/jshint/jshint/

My biggest beefs are: the fact that the build system is a complete black box that fails without a good indicator of what it takes to fix it, and inconsistencies in how events are handled, 'swipe' and 'scroll' being prime examples of events that either don't work as expected, or work in unexpected ways.

I completely agree with your last sentence. I don't begrudge them opportunities to monetize their platform, but I can't help but be frustrated at watching new functionality being added on top of piles of bugs.

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.