Downsides of using Appcelerator Titanium (or equivalent)?

Question

At our company there is a huge push for cross-platform (iOS and Android) development. Appcelerator Titanium is being considered (and seems to be the only thing that's being considered) to achieve multi-platform development without extra development time.

Everyone here can think of reasons to use Titanium. For reasons against using Titanium I guess the performance of the resulting "native" app from Titanium may not be as good as an app written in Objective-C for iOS. How significant would the difference be? Are there other reasons to not use Titanium (or equivalent)?

Note: I may write Titanium but reasons may not only be Titanium specific only. All reasons in support for coding in platform language (e.g. Objective-C, Java) qualify.

Bestiality

Answer 1

The Good:

• Can create iPhone apps using very simple Javascript.

The Bad:

• Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api

• "Native Widgets" are used, but only nominally: there's a layer of logic and abstraction between them and your code; and this layer changes their behavior and reduces their speed. The difference is visible in the Showcase apps.

• API docs are perpetually out of date. (no process for refreshing).

• A wiki was created, which is becoming out of date. Editing only
  allowed for employees.

• Github projects do not have wiki enabled.

• Appcelerator isn't true open source: they do not accept contributions from the community: The titanium_mobile project on github has a long list of open pull requests.

• The help forum software has many technical & design weaknesses.

• Email notifications from the help forum often do not work.

• Staff rarely answers questions in the Q&A forum. Haven't been seen
  in months.

• Showstoppers appear continuously in "all the little gaps":

• Correctly displaying images on the iPhone 4

• Correctly loading images in a scrolling list

• Although the platform does simultaneously support iOS and android,
  the library/framework does not. A lot of runtime testing (if/then's) is needed in apps that will work on android and iphone.

• Continually releasing new products but not fixing existing products
  and website problems. The "new" products are announced while in beta and release candidate phases.

• "Chat with Sales" app not attended to.

• Appcelerator does not take down outdated training videos.

• Stretching the truth and bait-and-switch with pricing: a 30% sale
  only applies to yearly memberships, not month-to-month. The blog
  posts & marketing materials do not state this. Only upon checkout is this shown.

• [Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
  results for a search is trashed: each page of results orders its hits from oldest to most recent, at the bottom of the page. Go to the next page of results (i.e. 51-100), and again, the 1-year-old hits are
  first, with 6-weeks-old at the bottom.

My Unanswered Questions:

[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff and receive sub-par treatment.]

Results:

Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.

Astrograph

I'll give Rachel some credit in that this post is a year old, but a lot of this complaining is about the company, and not the product. Things like "Native Widgets are used, but only nominally", are just inaccurate. – Submarginal

One complaint about the product: is that using it behind a proxy since the introduction of NodeJS is a nightmare. We were evaluating this as a potential tool. And while off company network it was fine, behind the proxy it was less than useless. Reaching out to support was not helpful, since they didnt seem to have experience dealing with Proxy based issues. – Hockey

There has been substantial work done on fixing all proxy-based issues. Those should be fixed now, but should anyone run into one, please contact me directly. – Abreact

I would like to offer that many of these reasons are also quite out of date at this point. We are quite open-source, we do take many, many community pull requests, we take issues reported by Apple extremely seriously, the documentation has received a serious overhaul since this was posted, etc. – Abreact

Answer 2

How significant would the difference be?

AFAIK, Titanium will generate Objective C, so unless their stuff is woefully inefficient, I wouldn't expect speed to be a major issue.

Are there other reasons to not use Titanium (or equivalent)?

Well, that depends on how you define "equivalent".

Personally, when I get into cross-platform apps, I expect that I will use PhoneGap. That's for one reason: standards.

With PhoneGap, you're writing HTML, CSS, and JavaScript, as if you were writing an HTML5 offline app. All PhoneGap does is turn that into an installable package (e.g., APK for Android) and give you opt-in proprietary APIs for getting to device-specific stuff. Their expectation is to simply fill in the "gap" between what HTML5 on mobile supports and what native apps on mobile supports. Heck, it's even in their name. :-)

As a result, what you are writing is the same sort of tech you would use for a Web-based app, and it may even get to share some of the client-side code. You can use whatever you like from mobile frameworks (e.g., Sencha Touch, jQuery Mobile). And, if someday app stores support HTML5 offline apps, you might even be able to drop PhoneGap altogether, if you're not heavily dependent upon the device integration features.

Titanium lets you write in JavaScript, but the standards compliance largely ends there. You're using proprietary APIs for everything, including the whole UI. Personally, I'd rather back a more popular horse -- HTML5 in this case, more so than PhoneGap specifically. If for no other reason, it'll be way easier to hire HTML5-savvy developers than Titanium-savvy developers.

Neither PhoneGap, nor Titanium, nor any of the plethora of other options (e.g., Rhodes, Flash/AIR) give you all of the device capabilities. These engines will vary in their extensibility -- I know that PhoneGap has a plugin model, that Flash/AIR is pretty much only what you get from Adobe, and I'm not sure about any others.

Titanium has one advantage: you get a near-native UI, instead of an HTML-based UI. (I say "near-native" because some of their widgets do not necessarily have native equivalents on all platforms, so they roll their own as needed) For some apps and some audiences, that alone may tilt things in Titanium's favor.

Mouthpart

there is a plugin model for Appcelerator. – Pirandello

you get native controls that are platform specific – Pirandello

@Aaron Saunders: As I wrote, you sometimes get "native controls that are platform specific". Android does not have a native button bar, toolbar, or "cover flow view". I am not saying that the Titanium implementations of those necessarily look bad on Android, but you cannot call them "native". – Mouthpart

Having worked with a proprietary one, if you're going to go the route of cross-platform, please either use titanium or phone-gap. Don't use anything closed-source. Having said that, CommonsWare is right on here, I'd just add 1 caveat: if you're going to be doing phone-heavy stuff, or you have really picky designers, then go native, you'll have the full power of the platform, if you're just doing website type things on a mobile device and you want an app, I'd suggest phone gap as well, just because of the standards - exactly like CommonsWare said. – Platoon

Answer 3

Titanium/iOS specific answer, my 2c.

Native iOS vs Titanium

PROS

• It's nearly as fast as native for most things.
• The time needed to write a working prototype it's way shorter.
• If you need to integrate javascript legacy code or libraries it will work provided that it doesn't use the dom.
• Your javascript code needs to be well spaced and to include semicolumns where needed or the compiler will complain and eventually abort the build.
• You can use Coffeescript or any other language that compiles to js
• Automatic memory management is top notch, getting the same results in objc is always time consuming and sometimes debugging intensive.
• You can write your own modules in native code to extend Titanium's capabilities.
• It's open source.
• They recently changed their support offering removing the 5 app limit, much more affordable.
• You can change a view js code while running the app in the simulator, you will see the results when you reload the view you're editing. That's a boon :) (exception: there's no way I know of to reload the code in app.js)

CONS

• Debugging is a pain. Haven't tried out Titanium Studio yet, it might be a big improvement.
• Adding too many views tends to degrade performance faster than using native code.
• The Titanium Developer app on Mac has plenty of interface glitches and you might find yourself restarting it pretty often.
• In some versions the print to console debug statements are broken.
• You will often stumble into cross-platform abstraction leakage.
• Support on the forums is a bit light, many issues you will encounter are not big but still annoying.
• Need to pay attention to JSON correctness, the included parser tends to be picky. Using eval is always an option.
• Compile times and loading in the simulator are not that fast, titanium objc is pretty big.

Attica

Second this for 'Debugging is a pain'. I jumped in on a Titanium mobile app development and the code is buggy on Android in unexpected ways. Java.lang.NullPointerException all over the place with very little to guide me towards how to fix it. Will add my own answer to this post when I have more experience to work off of – Allargando

Answer 4

Compared to Xcode, Visual Studio & even MonoDevelop, Titanium Studio feels slow (real slow), buggy (restarting several times each day, even reinstalling a few times) and of course you've got to deal with JavaScript... We found that the pain of developing in Titanium was too great, especially when you have competent iPhone & Android devs around so -

We looked long & hard into the best option for cross-platform dev & ended up using Mono - Touch & Droid. It's been great, we do actually share 80% of the code between iPhone & Android, & we're just beginning a port to WP, which is going well (again sharing 80% of the code). Of course it's not a miracle fix - you still need to know how to develop for each platform. I've even grown to like C# almost as much as Obj-C now :-)

Obviously, some will disagree.

Gropius