Appcelerator Titanium: From a developer's perspective

Thanks for your feedback. Certainly lots of issues that we can and do plan to address. On the tools side, as several people have mentioned below, we are releasing a new IDE this week called Titanium Studio. This release will address two critical areas that you identified in your post: debugging and overall tooling stability. The IDE itself is based on Aptana Studio, which has several years of solid development behind it. Sample projects, code completion, and other frequently-asked features will be included. Titanium Studio ships this week.<p>Certainly there are other areas in your post where we can improve. Know that we are making investments in all of the areas you describe and we certainly appreciate everyone's support as we grow the platform, the community, and the supporting infrastructure behind it.<p>Thanks again for your feedback<p>Best Regards,<p>Scott Schwarzhoff VP, Developer Relations

I had a similar experience with the platform. I was very excited, browsed through the APIs to check the required features were there and jumped in. It then took ages to get the right versions of SDKs/XCode and Titanium installed, which also involved searching though forum posts and patching files. Finally I got the "Kitchen Sink" app working. All was good.<p>I started implementing my app and quickly became flummoxed by the difference between seemingly identical windows (it's all down to "execution contexts" explained here <a href="http://iamwil.posterous.com/when-it-comes-to-titaniuminclude-its-a-trick" rel="nofollow">http://iamwil.posterous.com/when-it-comes-to-titaniuminclude...</a> not in the Titanium Docs).<p>And now Apple have made their subscription functionality the only game in town and that module (StoreKit) will cost a hefty Appcelerator subscription ($2500/yr, IIRC)<p>Bah... I've abandoned my Appelerator prototype and I'm going to try out PhoneGap which looks like it's really improved in the past ~6 months<p>Edit: typo

I created a iOS app in Titanium Mobile as well, and agree on your points. In addition:<p>- Multi platform support is very bad. A lot of functionality is working in a different way or not at all in Android and you'll have to find out most of this by trying.<p>- Stuff breaks with new versions of Appcelerator<p>- Due to the lack of feedback in the compilation process debugging some problems will take hours<p>- Creating a complex state-based navigation other then just a basic navigation controller is quite hard and bug-prone, a lot of it has to do with the sometimes very eager garbage collection (completely overlay a item with another, remove the overlay and the underlying element is gone, because it has been collected).<p>On the other side though:<p>- Development is a lot quicker (allthough you will lose time fixing stupid bugs).<p>- App works just like a native app and is quite fast<p>- A lot is possible, including custom fonts (using them in 3.1 causes a crash, so iOS 4 only, not documented though and caused crashes in the app on iOS3, so be careful, took me a while before I found this), the kitchen sink is a better resource as the docs.<p>For my next mobile app I think i'll use PhoneGap, since HTML is more portable. While I developed this app I had the constant fear that I would come across a bug that would stop me from finishing the product. It's a risky thing to work with, but you can get some great stuff out of it in no-time if you're lucky.

I don't disagree with him but I still think Appcelerator is worth it. Because as annoying as Appcelerator can be it's still quicker than writing your app twice and Apple's devotion to objective-C makes it very hard to carry over code from other platforms.<p>I would give two warnings though (which are supported by the author's piece)...<p>1. You need to make sure your use case is covered in the Kitchen Sink example. If you can't take those pieces and put together what you want to build than you shouldn't bother with Appcelerator (the documentation is pretty useless)<p>2. You need to buy support. The community is non-existent but the staff support is pretty good. A lot of times their advice boils down to "just ignore that error" but that's helpful with a lot of the errors generated.<p>Also note Appcelerator just bought Aptana, a company that makes development software. So clearly they realize there's a problem are are taking steps to fix it.<p>Edit: One last thing in their defense. Though they've been slower than I'm happy with in making their platform easier they have added a lot of new features. Things like Bump, bar code reading, credit card reader support and in-app purchases aren't available elsewhere (though these were just announced so I don't know how well they work yet)

I'm current knee-deep in building a Titanium app for iPhone, and my experience has roughly matched tannerburson's, however, I have had far less difficulty with some aspects. For instance, I am using one line JavaScript IFs with no warnings.<p>The API docs are incredibly sparse, however, helpful enough for the nuts and bolts of dealing with our JSON API, storing to plist files and using the built-in HTTP client. I am currently wrestling with structuring our app such that it fits to one of the paradigms given in the Kitchen Sink; this has been incredible tough. As noted by others, sliding and scrolling behavior is erratic.<p>Our current iPhone interface is a fully manifested jQtouch web app, and I have pushed the performance of the app as far as possible. It isn't terribly slow, however, it one of the main bottlenecks users have in interacting with our service.<p>I originally set out wrapping our jQtouch app in PhoneGap - a simple task. However, given the way that PhoneGap works, the performance was no better than the current web app. I then completely rebuilt the app in jQuery Mobile (Alpha 3 at the time), loaded it into Phone Gap and discovered that the interactions and load time were slower than my original jQTouch app. This isn't to knock jQuery Mobile or PhoneGap; rather it is a reminder that for a full jQuery Mobile or jQTouch app you are looking at loading 140-200Kb of JavaScript every time you open the app. If Nitro ever comes to homescreen apps, this will be less of an issue.<p>The long and short of it is that while PhoneGap certainly gives you infinite flexibility in what the UI of your app can do, you have to be vigilant about keeping your load times down by minimizing frameworks. If you already have built an iPhone web app that meets your performance requirements, load it into PhoneGap.<p>Alternatively, if you want a fast, lightweight app with a UI that mirrors one of Titanium's demos given in their Kitchen Sink, then I believe that the struggle is worth it. All of my commentary is working under the assumption that you have no Objective-C experience.<p>I recommend downloading the app Wunderlist to get an idea of the extent to which one can customize a Titanium app.

This was about 5 months ago, so it's possible they drastically improved it in that time (although it doesn't sound like it). But I ran into the exact same issues.<p>Debugging was a pain because of you were writing JavaScript rather than Obj-C and the line or file on some errors were on were entirely unhelpful.<p>Performance (which you don't notice in the simulator) is poor. I was working with tables on iOS, even after cutting the app down to using 10 rows, people noticed a lot of lag on iPhone 4s (and it was unusable on a 3G or 3). This was with the only scroll events being a scroll position check suggested by the KitchenSink demo they provide.<p>Entirely possible this was something I missed, but while it says cross-platform, you don't really get cross-platform. The difference in UIs between Android and iOS means you're going to be writing quite a lot more code to actually get an app that works on both Android and iOS.<p>[edit] syntax

Colleagues of mine are paid users of Appcelerator's small business offering and have said the exact same thing: no community on the other side of the pay wall either, and little to no developer interaction.

Yeah, it's too bad. I know a guy on the development team, and I think they're doing a great job given the complexity of the task they've taken on, but I can't recommend it for anything other than prototypes or very simple applications.

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

The current mobile dev scene is this:<p>- Android is Java, iOS is Objc + (cocoa nightmare), Windows Mobile is silverlight (If i'm not wrong)<p>- iOS (cocoa) is a pain to learn and develop something useful out of it, plus you have to pay dev licenses to apple anually,etc..<p>- Android store doesn't have the projection Apple store has.<p>- Native wrappers (titanium, phonegap,etc..) are buggy, lack user support, poor documentation, limited.<p>So, choose your poison.<p>What's the solution ? It's freaking insane if you want to have an app for every mobile OS out there at the moment, you need to have at least 2 different teams maintaing code. It's just stupid.<p>Wrappers are not the way to go fore sure, I think vendors should start considering using standard tools like Javascript, or more easy languages like ruby,python, at least for creating more simple tools, that don't require heavy graphic engine and stuff.<p>At least this would help companies reduce their efforts on having teams different for each OS.

Interesting, I experienced similar frustrations starting out with rhomobile and was hoping the grass was greener on the other side.<p>My ultimate complaint with rhomobile is that the "native" apps are running in the web browser. I plan go into further detail in an upcoming blog post / presentation.

We used it to make a simple android app in the last month. It worked and I sure liked writing the app in JavaScript vs Java but we ran into huge issues with Titanium caching resources during the build process that were supposed have be removed or updated and leaving things behind that we then had to track down and manually remove. It basically just takes whatever is in the build directory and tries to package it with little validation for correctness. My suggestion to people using it is to sanity check the code it generates in eclipse or xcode as part of your dev process.

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.<p>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).<p>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.<p>If I really need crossplatform whatsits, I'm thinking flashbuilder or that ilk at this point. Titanium did not impress.

Wow, thanks for this write up, I had been considering trying titanium after an unpleasant experience with phonegap.<p>I went with phonegap for a project and hammered out my application quickly but then spent hours trying to optimize enough that it would run at a reasonable speed. I ended up re-writing as a native app but at least now I know.

So glad to see more people pointing this out. Titanium sounds like a great idea and they market it well, but when you look closer you quickly discover that it just fails to deliver. Sadly they seem too focused on spending VC cash on adding bells in whistles when their core functionality still doesn't work. Here are a few examples.<p>Running their sample app. This is the first thing every developer does, so you'd think they'd have nailed this much, right? Sadly, no. Check out all the forums posts about people struggling to get KitchenSink running:<p><a href="http://developer.appcelerator.com/questions/search/kitchensink" rel="nofollow">http://developer.appcelerator.com/questions/search/kitchensi...</a><p>Some of that is the complexity of getting the right 3rd party developer tools installed. But often projects will randomly stop compiling. Instead of fixing the underlying problem, this is their workaround (it's not just KitchenSink, it happens to your projects too):<p><a href="http://developer.appcelerator.com/question/53821/kitchen-sink-wont-run-what-do-i-do" rel="nofollow">http://developer.appcelerator.com/question/53821/kitchen-sin...</a><p>They don't seem to have anyone who monitors their forums. When core functionality breaks and people report it, nothing gets done about it for months, even when the fix is as simple as whitespace. This was reported in Oct, and a pull request was submitted in Jan.<p><a href="http://developer.appcelerator.com/question/82691/run-on-device-not-working-at-least-for-ios-42-and-sdk-142" rel="nofollow">http://developer.appcelerator.com/question/82691/run-on-devi...</a><p>It was finally fixed last month:<p><a href="https://github.com/appcelerator/titanium_mobile/commit/510fc60f7e3521244bd856c60ad17019876adb77" rel="nofollow">https://github.com/appcelerator/titanium_mobile/commit/510fc...</a><p>Open source means the community should be able to pitch in, but there are 16 open pull requests from the last 2 months, none closed or even commented on:<p><a href="https://github.com/appcelerator/titanium_mobile/pulls" rel="nofollow">https://github.com/appcelerator/titanium_mobile/pulls</a><p>New features are rolled out with sparse documentation and then abandoned. Need to style a bunch of views, try JSS - except it's not documented in detail anywhere. But maybe they dropped JSS and are working on Helium?<p><a href="http://developer.appcelerator.com/question/91331/jss---class-based-formatting" rel="nofollow">http://developer.appcelerator.com/question/91331/jss---class...</a><p>Or not. Helium hasn't been updated in months and still isn't documented anywhere on the Appcelerator site. So who knows.<p>There are many other issues, of course. Ultimately you end up having 3 options: (1) pay them a bunch of money for support, (2) spend more time fixing their software then working on your own code, or (3) just writing native apps for the various platforms (or native web wrappers with HTML core).<p>I wouldn't mind paying for support if the product worked great, but paying to get support for something that's broken to begin with is frustrating. It's ultimately easier to just find alternative technologies.

I have been using &#60;a href="<a href="http://the-m-project.net/&#62;The" rel="nofollow">http://the-m-project.net/&#62;The</a> M Project&#60;/a&#62; for several months while building a web-only mobile app, currently in private beta and so domain-specific as to be useless to the general population. The framework builds on best-of-breed frameworks node.js and jquery mobile. Javascript ftw! The core developers hang out in IRC, or at least jump on when someone pops up with a question.<p>Turns out, they also have phonegap support, so I &#60;em&#62;could&#60;/em&#62; deliver an app, but that sounds like more of a headache than its worth.

Lots of projects want to simplify the app development process, and there are even more startups working on automating the process. Ultimately it's fine for prototyping, but not much else. Performance becomes an issue and you rapidly hit it wall with anything but native apps.<p>It's good to get your feet wet and get excited about the platform, regardless of it being Android or iOS, but at some point you need to just bite the bullet and pick up a good book and start working.

I'm looking forward to the inevitable follow up post on the author's experience with Phone Gap... Has anyone used Phone Gap before and wants to share their thoughts?

We have paid for premium support. Still our experience is similar to this guy, there is lots of bugs and undocumented behavior keep you frustrated

I've been using Titanium for 2 months now while developing a prototype version of our iPhone application (Android later), and while I share the author's sentiments on a number of issues, I'm fairly pleased with the results so far. I'm not an Objective-C guy in the least, but am reasonably good with JS, so it's a great way to go native.<p>That said, some comments: - JS Warnings. It's true that one-line ifs, property existence checks, function closure suggestions, etc. can get a little annoying. My solution is to write JS which is 100% JSLint compatible, which is fair IMO.<p>- Titanium Warnings. These get annoying. I get dozens of "[object TiUIView] has an auto height value of 0, meaning this view may not be visible" warnings which are completely useless and don't identify the offending View for me to fix. Also, I get about a dozen errors like "&#60;Error&#62;: CGContextDrawImage: invalid context 0x0" which give me no indication which is the offending image. Etc.<p>- Performance. While native, our application runs a little sluggish and certain views are choppy when scrolling, and some style properties have bizarre rendering behaviour (layout: 'horizontal', width / height: 'auto', etc)<p>- Minor Revisions. The author is right, some minor revisions introduce pretty bad issues. 1.6.0 introduced some very noticeable performance degradations in TableViews, so we're still on 1.5.1 for now.<p>- Documentation needs work. The API reference is lacking any mention of certain parameters, which is frustrating. The wiki has more detailed information and has essential reads to understand things like TableViews, but I didn't find this resource for several weeks into my project. Many undocumented side-effects exist, like quirky behaviour on horizontal layouts, etc. Here's an example of the kind of confusion which results: <a href="https://appcelerator.lighthouseapp.com/projects/32238/tickets/1437-horizontal-layout-broken-on-ipad" rel="nofollow">https://appcelerator.lighthouseapp.com/projects/32238/ticket...</a> The "headerPullView" feature for pull-to-refresh is currently undocumented magic.<p>- Barcode support is disappointing. Titanium+ introduced Barcode support, but does not support the usual 1D barcode. The additional libraries that exist (TiBar, zbar, etc.) are very difficult to compile in without XCode hackery, and sometimes don't work on the devices themselves, making debugging very difficult.<p>- Bugs in XHR with Content-Type and passing Arrays, requiring workarounds when integrating with Rails. Arrays get sent as "( key1: value1\n key2: value2\n)\n" .. seriously :)<p>- Titanium Developer required me to click "Launch" to start the application until I read Gene Tsai's comment on the original article which gives you command-line aliases to start your application. Awesome tip :)<p>At the end of the day, Titanium Mobile is a great solution, but be prepared to be patient while the platform matures, and to get creative in architecting alternate solutions when your initial approach doesn't work. I'm confident the wrinkles I point out above will be ironed out in time.

PhoneGap and MoSync are the ones to try out for cross platform development, but honestly, it's probably better to design the app in such a way that porting it becomes as easy as possible.

"It’s only syntax/static checking is done via JSLint with a pretty arcane set of rules. Want to write one line if statements? That’s a warning. A for loop without checking for property existence? That’s a warning."<p>Someone hasn't read Javascript: The Good Parts.