
Appcelerator Titanium: From a developer's perspective - tannerburson
http://tannerburson.com/2011/04/03/Thoughts-on-Appcelerator-Titanium.html
======
sschwarzhoff
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.

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.

Thanks again for your feedback

Best Regards,

Scott Schwarzhoff VP, Developer Relations

~~~
tannerburson
I appreciate your comment, and it's great that you're reaching out to the
developers using your platform. I'm excited to try out the debugging features
of Titanium Studio, and hopefully it's more transparent in the steps it's
taking to build an application as well.

Your second paragraph rings a bit hollow though. I'm sure you all are
committed to growing the platform, I'm sure you're making investments. What
software company isn't trying to move things forward? But as a user, I frankly
don't care about how much better things will be. I just want to get things
done, and the current state of your product makes that difficult. Worse than
that, the current track-record of development (as witnessed by may comments
here!) doesn't show a lot of progress.

I earnestly look forward to seeing improvements in the near future, as I have
an application to deploy and support!

~~~
sschwarzhoff
Well, we just released Titanium Studio... with debugging. How's that for
moving things forward? And sample projects and code are included, with a ton
of new features coming in the full release later this quarter.

We have about 2,500 apps being built per month now. This number is increasing
by about 50% month over month. In total, we have over 15,000 apps in the
various app stores. That puts us as #1 go-to mobile development platform
behind Apple and Google. Seriously.

Obviously, we'd love it if everyone was successful, but we're 50 people and
running flat out. And that last round of $9M in funding? It's gone to QA, to
acquiring Aptana, to adding 5 engineers in the past 6 weeks on Android, to
quadrupling the amount of content out there (have you checked out our latest
guides? They're awesome! <http://wiki.appcelerator.org/display/guides/Home>).
There's a ton in there... and most have been written by the community!

Look, I'm not saying that we're perfect. We have LOTS to do. But we're a
platform company that's listening intensely to developer needs on a very
frequent basis and making big investments in the areas that need the most
help.

So, yeah, Q&A needs a forum. Our API needs more parity, we certainly need to
be more responsive to the 100 or so questions coming at us every day. But
c'mon, if you're going to build a _real_ native app in no time, a platform
that has 3,600 methods and processes in use by 130,000 active app developers
must have something going for it don't you think? Try Wunderlist. Try GetGlue.
Try ScoutMob. These are all top apps written on Titanium with small dev teams.
None of these apps were built with a support subscription, btw. Stick with it
and you'll see just how much can be done with the platform.

Give us another shot with Titanium Studio and the other cool stuff that comes
out this quarter. We'd love to see you back as a Titanium fan...

~~~
mattjaynes
Thanks for letting us know some of the backstory there.

It may be just me, but reading your comment makes me more worried about lack
of focus there than less... It just seems very frenetic.

I've been developing on Titanium for several months now (as a paid subscriber)
and more and more the decisions and priorities of the company really puzzle
me. It seems like Appcelerator mostly ignores a shaky foundation while
excitedly piling more 'features' on top of it and using tons of duct tape to
try and keep it from collapsing before the money runs out.

The most compelling evidence for this is the pull requests being ignored for
long periods of time. How can we be excited about a platform that is so slow
to even accept help from the open source community to improve it? Meanwhile, I
frequently get calls from Appcelerator trying to get me to buy in-person
training and even a new 'certification' program. Really?! That's where your
putting your resources rather than the actual platform supporting your
'platform'?

I really really want to like Titanium and be a fan, but right now it seems
like asking me to please be a Microsoft fan. At this point I'd probably
recommend MS over Ti. That's not a compliment :(

Please please please focus on your core experience. Ignoring it will
drastically damage your reputation among hackers (as you can already see
happening) - and hackers are the ones who decide which platforms to use (and
which to abandon).

I would gladly pay several times more than I am now for an 'A' quality
platform. Money is not an issue for many of us developers, but quality will be
the deal killer here. I've many times wished that I could even pay a bounty to
fix certain platform bugs.

Please please focus on your core.

Sincerely,

Someone who'd really really like to be a fan

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

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 [http://iamwil.posterous.com/when-it-comes-to-
titaniuminclude...](http://iamwil.posterous.com/when-it-comes-to-
titaniuminclude-its-a-trick) not in the Titanium Docs).

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)

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

Edit: typo

~~~
wahnfrieden
Titanium is much, much more tolerable and sane if you ditch Ti.include and use
its CommonJS Ti.require() instead.

~~~
drewda
Is that what screws up global events (at least on Android)?

------
fijter
I created a iOS app in Titanium Mobile as well, and agree on your points. In
addition:

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

\- Stuff breaks with new versions of Appcelerator

\- Due to the lack of feedback in the compilation process debugging some
problems will take hours

\- 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).

On the other side though:

\- Development is a lot quicker (allthough you will lose time fixing stupid
bugs).

\- App works just like a native app and is quite fast

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

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.

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

I would give two warnings though (which are supported by the author's
piece)...

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)

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.

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.

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)

~~~
tannerburson
I haven't bought support, so I can only speculate based on their community
forum, and public bug tracker. With that out of the way, unless paid support
gets custom code deployed to them fixing core platform problems, I don't see
it as being a solution.

In it's current state I couldn't recommend Titanium to anyone. I hope it
continues to improve, and get better, as both the idea and implementation have
a ton of positives, it's just almost unusable right now for anything big
enough to really see the benefits in the multi-platform support.

~~~
TomOfTTB
I'd be interested to know what you consider the core platform problems because
I've never run into anything that couldn't be worked around.

Don't get me wrong. I sympathize. I lost several nights of sleep because I was
so angry after a day of using Appcelerator that I literally couldn't calm
myself down enough. There were days when I'd decided to not only stop using
Appcelerator but to make it my life mission to tell other people to stay away
from it.

But those days passed and eventually support (and a lot of manual error
checking) got me through.

~~~
jeff18
Here's two "show stoppers" that made me stop experimenting with Titanium.

1) If you have a custom UI, dragging the window around is painfully slow and
erratic. Resizing the window is actually so slow it's unusable.

2) The built-in zip function doesn't seem to work with files over ~200 MB on
Mac OS X.

I tried reaching Titanium, failed, and moved on.

~~~
wahnfrieden
I think most of us here mean Titanium Mobile when we say just "Titanium."
Their desktop platform seems to have received much less attention from them,
and is of much more questionable benefit than the mobile one, which doesn't
have many alternatives whereas on the desktop there's Qt and all sorts of
other things available.

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

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.

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.

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.

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.

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.

I recommend downloading the app Wunderlist to get an idea of the extent to
which one can customize a Titanium app.

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

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.

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.

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.

[edit] syntax

~~~
tannerburson
I haven't found on device performance to be too terrible for latest gen iPod
Touch and iPhone 4. It's definitely inconsistent in places though.

You're dead right on debugging, it's pretty much guess and check, all the way
through. Painful puts it mildly.

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

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

~~~
tjarratt
Based on what little I've seen, this sounds accurate. Both Android and iOS
have a large amount of features and controls that developers are used to
having access to - distilling that down into a simple codebase can't be easy.

It will be interesting to see if any early adopters continue to support
Appcelerator; I'd love to see what their product looks like in a year or two.
At the moment, my work is a little too complicated and urgent to want to
rewrite anything for an immature codebase.

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

~~~
clojurerocks
This was my experience as well actually. I looked at phonegap appcelarator and
rhomobile for a while but it seemed that there was such a steep learning curve
that you could just build things in the native platforms and have full access
to the everything rather then having quasi access via webkit.

All three really were a letdown frankly. Right now im learning Jquery Mobile
which oddly enough is kind of cool. Its got a decent community behind it. ANd
its jquery so its somewhat more generic.

------
phatbyte
The current mobile dev scene is this:

\- Android is Java, iOS is Objc + (cocoa nightmare), Windows Mobile is
silverlight (If i'm not wrong)

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

\- Android store doesn't have the projection Apple store has.

\- Native wrappers (titanium, phonegap,etc..) are buggy, lack user support,
poor documentation, limited.

So, choose your poison.

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.

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.

At least this would help companies reduce their efforts on having teams
different for each OS.

~~~
protomyth
You have to pay Microsoft too. What exactly do you find that makes cocoa a
"pain to learn"?

~~~
phatbyte
The concept of Outlet was very strange to understand at first, I never knew
what should I connect to what (iboutlet, ibactions), then, the cocoa classes
methods are big and enigmatic sometimes. I also found that creating a simple
tableview with simple content is frustrating, because you have to link so many
different steps, you have to create an object for table view, create delegated
functions for counting and adding items, create a mutablearray, link it to the
tableview, reload it everytime you need to display...and I'm not talking about
adding images and stuff.

I'm pretty noob at cocoa, but it's a very hard learning curve because Objc and
cocoa have so many specific standards that are strange if you came from other
languages.

------
jonathanwallace
Interesting, I experienced similar frustrations starting out with rhomobile
and was hoping the grass was greener on the other side.

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.

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

~~~
jamroom
You need to clean your build directory whenever you change resources (i.e. add
new images, delete old images). It makes the build take a bit longer but
you'll have no issues. So i.e. just delete the contents of the
Resources/build/iphone directory and then rebuild the app from Titanium.

~~~
andymoe
Oh, I know how to solve the problem. I just think the tool could use work.

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

------
pdenya
Wow, thanks for this write up, I had been considering trying titanium after an
unpleasant experience with phonegap.

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.

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

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:

[http://developer.appcelerator.com/questions/search/kitchensi...](http://developer.appcelerator.com/questions/search/kitchensink)

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):

[http://developer.appcelerator.com/question/53821/kitchen-
sin...](http://developer.appcelerator.com/question/53821/kitchen-sink-wont-
run-what-do-i-do)

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.

[http://developer.appcelerator.com/question/82691/run-on-
devi...](http://developer.appcelerator.com/question/82691/run-on-device-not-
working-at-least-for-ios-42-and-sdk-142)

It was finally fixed last month:

[https://github.com/appcelerator/titanium_mobile/commit/510fc...](https://github.com/appcelerator/titanium_mobile/commit/510fc60f7e3521244bd856c60ad17019876adb77)

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:

<https://github.com/appcelerator/titanium_mobile/pulls>

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?

[http://developer.appcelerator.com/question/91331/jss---
class...](http://developer.appcelerator.com/question/91331/jss---class-based-
formatting)

Or not. Helium hasn't been updated in months and still isn't documented
anywhere on the Appcelerator site. So who knows.

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

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.

~~~
skue
Forgot one other _big_ issue that no one seems aware of: Appcelerator tracks
your development with their tools. Titanium Developer transmits analytics data
every time you create/import/edit/delete/compile/test/install/distribute a
Titanium project on your system.

To see the specific calls, just download titanium_developer and grep for
Titanium.Analytics.featureEvent. If you do use Titanium and want to disable
this, you should build a new version of Developer after adding the following
line to tiapp.xml:

    
    
      <analytics>false</analytics>
    

One last note: I don't make these points just to be mean-spirited.
Appcelerator clearly has some talented programmers and great technology. But
silent tracking isn't okay, and clearly someone at top needs to help them
focus the talent they have.

------
pinoceros
I have been using <a href="[http://the-m-project.net/>The](http://the-m-
project.net/>The) M Project</a> 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.

Turns out, they also have phonegap support, so I <em>could</em> deliver an
app, but that sounds like more of a headache than its worth.

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

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.

------
erik_p
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?

~~~
jamroom
We moved to Titanium from PhoneGap around 5 months ago - PhoneGap was just too
slow for many options and did not support the low level audio functionality we
needed. It may be better now though, but we haven't looked. Titanium has
actually worked really well for us so I'm a bit surprised by so many
developers having issues on here. Our app is coming out in about a month and
is fairly large, with a custom UI:

<http://www.groovydisk.com/>

------
nexneo
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

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

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.

\- 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 "<Error>: CGContextDrawImage:
invalid context 0x0" which give me no indication which is the offending image.
Etc.

\- 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)

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

\- 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:
[https://appcelerator.lighthouseapp.com/projects/32238/ticket...](https://appcelerator.lighthouseapp.com/projects/32238/tickets/1437-horizontal-
layout-broken-on-ipad) The "headerPullView" feature for pull-to-refresh is
currently undocumented magic.

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

\- 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 :)

\- 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 :)

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.

~~~
wahnfrieden
> 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"

Can you elaborate on this? What is the Content-Type bug? What do you mean by
"passing Arrays" -- how are you serializing?

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

------
s00pcan
"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."

Someone hasn't read Javascript: The Good Parts.

~~~
wahnfrieden
The JSLint step is optional. I build my Titanium projects via the commandline
(I don't use the IDE thing at all) which bypasses JSLint. I use the more
reasonable JSHint as integrated into vim, not as part of the build.

This is the line that builds and runs my project:

    
    
      /Library/Application\ Support/Titanium/mobilesdk/osx/1.6.0/iphone/builder.py "simulator" "4.2" /Users/jehlke/workspace/titanium/Manabi "org.manabi.mobile" "Manabi"
    

You just need to setup the project inside the Titanium Developer app, and then
you can invoke it with this command from then on.

