Inside Appcelerator Titanium

Nick Savula
iOS R&D engineer

You’ve been triggered by the fact that Titanium has half a million developers, around 50k apps published and a high position in Gartner’s Magic Quadrant but still can’t believe it? We also can’t, and that’s why we decided to delve into Titanium.
From Dusk Till Dawn trunk shot

What is Titanium?

Titanium is a cross-platform JavaScript runtime and API for mobile development. Like Appcelerator guys say, “Titanium is not an attempt at “write once, run everywhere”. We think there are great, user-experience enhancing features across multiple platforms that developers should be using. We think that native apps should, where appropriate, take advantage of familiar, high-performance native UI widgets. However, we think it is unnecessary that native developers need to learn platform-specific APIs to draw a rectangle, or make an HTTP request.” Titanium tries to achieve great code reuse, keeping native performance and user experience.

While Appcelerator guys struggle on simplification of rectangles and HTTP requests, making something different, customizing or adopting new native functionality can get ugly. The adoption of new framework (or a part of it) will require knowledge of a native platform (Objective-C or Java) to implement the actual module, define the API to access it through JavaScript.

Titanium comes along with “Titanium Studio” – a free Eclipse-based IDE for Windows, Mac and Linux. It also has a bunch of samples on github. Additionally, you’re getting Appcelerator MBaaS (Mobile Backend as a Service) for free, and that’s awesome if you can’t afford back end and need a simple API to manage user accounts and data. Titanium comes in two plans: Developer (completely free) and Enterprise (haven’t found the actual pricing, but they offer analytics, enterprise edition of IDE, performance management, support and some security stuff). Support is chargeable and comes in three different packages.

How Titanium Works

Titanium is neither a WebView-based solution (unlike PhoneGap), nor a JavaScript-to-Native interpreter. You will not be able to see your code while exploring a project’s build directory, only some weird native framework wrappers. Titanium provides JavaScript interpreters for every native platform, native API implementations for these platforms and your JavaScript code compiled for a respective platform. When you launch an application, a JavaScript execution environment is created in native code and your application source code is evaluated. By calling JavaScript function var b = Ti.UI.createButton({title:’Poke Me’});, Titanium invokes a method for native button creation. Meanwhile, a “proxy” object is created that exposes properties and methods of the underlying native UI to JavaScript. Both native (Titanium API) and JavaScript (your code) have proxy objects which serve as a bridge at application runtime.

Let’s say, you want to create ScrollView and display it. With JavaScript it’s as simple as this:

var win = Ti.UI.createWindow({
 backgroundColor: 'white',
 exitOnClose: true,
 fullscreen: false,
 title: 'ScrollView Demo'

var scrollView = Ti.UI.createScrollView({
 contentWidth: 'auto',
 contentHeight: 'auto',
 showVerticalScrollIndicator: true,
 showHorizontalScrollIndicator: true,
 height: '80%',
 width: '80%'

var view = Ti.UI.createView({
 borderRadius: 10,
 top: 10,
 height: 2000,
 width: 1000


Looks easy enough, huh? Wait to see exactly the same thing with Alloy.


Alloy is an MVC framework for Titanium. With its help, you can build interface in .xml and style it in .tss (style sheets) files. That’s actually pretty cool, now you don’t have to write your UI with JavaScript and that is likely to result in more rapid development. The above ScrollView code will be transformed into neat XML markup:

   <Window id="win" backgroundColor="white" exitOnClose="true" fullscreen="false" title="ScrollView Demo">;
       <ScrollView id="scrollView" showVerticalScrollIndicator="true" showHorizontalScrollIndicator="true" height="80%" width="80%">;
           <View id="view" backgroundColor="#336699" borderRadius="10" top="10" height="2000" width="1000" />;

To access your newly created scrollview in .js, simply get it by id: $.scrollView, and, to style it up, .tss markup file:

"#scrollView": {
   scrollType: 'horizontal',
   backgroundColor: '#fff',
   layout: 'horizontal'

Lets see project structure with and without Alloy.

With Alloy
Without Alloy

Alloy looks very complicated at first, but as long as you keep your files in the right place (.xmls in Views folder, .tss in Styles folder and .js in Controllers folder), you should be fine.

One thing to point out about module installation:

  • if you want this module in your project only, just drag the .zip dist to the project root folder and build your project. The build script will do everything for you (unzip and move).
  • for global usage, move the dist to the Titanium folder (Library > Application Support for Mac). When the project is compiled for a platform, the compiler translates XML and TSS files into the JavaScript code and packages the code.
  • So, basically, Alloy is just a way to save you some precious time on development (and bug fixing! Less code – less bugs).

    The downside is that it’s relatively new, so even on Titanium forums you won’t find much info on it. BUT, as for now, Alloy is only supported on Mac, so if you have a PC and want to develop cross-platform apps with Titanium, you’ll have to use good ol’ JavaScript for everything. Disappointing. Alloy is built on Node.js with Backbone.js and Underscore.js support.
    Unfortunately, there isn’t much going on at their github repository lately, so you might want to get over there and make some noise.

    Before using Alloy, you should really think twice even if your entire team is on Macs, because each new member will require a separate one for you to buy.

    App Overhead

    Oh boy! I’ve written my proof of concept app in just two days (environment setup took one of them)! And it runs on iOS and Android! That’s what you’ll probably think after a few days of dancing with Titanium. And that’s most likely where your happy days with it will end.

    As you proceed toward your awesome cross-platform solution, you’ll discover that Titanium API coverage of native frameworks is not that great. There’s Appcelerator Marketplace – a nice place to get Titanium modules (most good stuff is paid), although there are some community modules on github, if you search around. Nearly every serious free module I’ve come across was “almost” production ready, which means they come with a set of limitations, issues and glitches. For instance, the ds.SlideMenu widget worked not so bad on iOS, but for Android it was pure hell, completely not usable – sliding glitches, freezes and layout flaws.

    As for “as good as native” performance… Well, not really. No. Only for some basic stuff, like Table Views with nothing but text, a basic set of UI controls, etc. As an iOS developer, I can say that optimizing Table View with complex cell and network loading is not a trivial task (forget about Collection View), not to mention memory usage optimizations, CPU time and battery life. How can you optimize your code in Titanium? With modules, of course, but that does require you to know Objective-C or Java.

    There are lots of things you simply can’t control with Titanium. If your project is big enough and you start receiving memory crashes, you’re in trouble. How does Titanium handle platform-specific things? Well, most of the time, you’ll have to check for platform: if (Ti.Platform.osname == “android”) to handle differences or to customize UI (with Alloy .tss you can customize it with “TextField[platform=ios]”:{).

    Check out this YouTube video of a sample project on Titanium with the use of the Alloy framework.

    To be fair, the whole development process was made for iOS, and this video was the first run of the app after installing Android SDK, no optimizations or code changes were made. As you can see, it doesn’t work well “out of the box”.

    The compiled binary occupies 11mb for Android and 12.2mb for iOS. The Resource folder contained nothing but a custom image of annotation for iOS. With a native iOS app you could fit a full production-ready app in that binary with tons of resources, Google Analytics, Crashlytics and a bunch of 3rd party frameworks and libs. As for CPU usage, here are some results:

    MapView panning with continuous annotation refresh
    Screen Shot 2014-04-10 at 5.20.48 PM

    Table View scrolling with loading more items from network (rounded images on cells, and HTML text display)
    Screen Shot 2014-04-10 at 5.21.53 PM
    (What can I say, the results speak for themselves)

    and allocation tracker
    Screen Shot 2014-04-10 at 5.38.51 PM

    I’m showing the Objective-C call only here, since Titanium calls are just memory addresses and are not informative. Again, commercial, a rather complex app after about 5 mins of active usage took about 10mb of all heap allocations, while the Titanium sample took whole 50mb.

    Learning Curve

    Is it hard getting started with Titanium? Actually, things are pretty easy, especially with Alloy: you just create a bunch of controls in .xml, style them up, hook up everything to play along in code, and voilà – a demo for an eager customer, tons of applause and congrats. The frustrating part is environment setup, some options like uploading a provisioning profile on iOS are not really intuitive and I didn’t manage to get the Android emulator running due to “PANIC:” errors, none of the solutions suggested helped.

    And, of course, you need to know JavaScript. If you came from PhoneGap or something like jQuery Mobile, Titanium might actually be a really nice choice. For native devs though, it could turn into a nightmare: you should be ready for working-around, ignoring performance issues and situational UI glitches. Debugging can also be painful. Perspective view debugging of Titanium Studio is not that great: I found myself just logging vars to console, in order to know what’s happening. Here’s what debugging perspective looks like:
    Screen Shot 2014-04-10 at 6.23.13 PM

    It is worth mentioning that basic understanding of what happens on native platforms is required to write apps with less bugs and better user experience.

    Ecosystem and Community

    As Appcelerator states, the community is about half a million developers, though searching around for some answers shows that Titanium community is either very passive or very small. At most, you’ll find 2 Appcelerator forum records, 1 Stack Overflow record and a blog post on the point of your interest. As for support, I’ve written to them when I haven’t received a confirmation email for my account (and yes, you do need to register in order to use Titanium Studio), but they didn’t write me back and that was not very nice. Only the next day I’ve been able to login into the Studio with my creds, without any email confirmation.

    Appcelerator guys showcase tons of apps on their customer page, but the main title showing the number of devices that have titanium-powered apps is amateurish. Would you trust an IT company that showcases their success by the total experience of their employees in years? Me neither. Anyways, I’ve got a feeling they put EVERY SINGLE application they have on that page, many of them having 3-star rating or less. Shame on you, Appcelerator.


    First of all, no Windows Phone support. Although it’s announced for Q4 of 2014, if you want to cover all three major mobile platforms, you’re better off with something else.

    Documentation is often inaccurate and outdated, in combination with weak community this could actually be an issue. The API coverage could have been better (for instance, no custom map annotations are supported on Android), the toolkit can be painful sometimes, lots of questions on forums receive a “clean-rebuild” answer. Many of Titanium modules come with various limitations, like no table headers for Android, no shadows for iOS, etc. Animations can be noticeably laggy, especially on Android devices.

    A very serious thing to mention is development efforts. With increasing project complexity, developer efforts increase a lot, which will result in larger timeframes and cost. As mentioned above, Titanium is not WORE (write once, run everywhere), but for a complex project it can turn into a WOFE (write once, fix everywhere) solution.


    The dilemma with Titanium is “Does it fit into my project?” The answer can never be easy here, but there are some do’s and don’ts.

    Don’t write with Titanium if:

    • You have to work tightly with hardware.
    • You have a big project (lots of stuff happening at the same time).
    • You have complex UI (custom animations, transitions, custom UI components).
    • You have to adopt new SDK features (like if a screenshot was taken on iOS 7).
    • You have high demand for performance.
    • You have to support a wide range of OSs and devices.
    • You have to support Windows phone.

    Do write with Titanium if:

    • You are/your customer is short on cash.
    • Very limited time frames/want to make something very quickly.
    • You don’t have to support the released product.
    • You’re proving the concept.
    • You want to quickly push something out to market in order to start building up a community.

    The bottom line is:
    Would I recommend Titanium to my fellow developer?
    Would I recommend Titanium to my customer?