MythBusters: Killing the Top Misconceptions about Appcelerator Titanium

Titanium Myths

In the many years I’ve been working with Titanium and the Appcelerator Platform, I’ve been fortunate to develop a wide range of native, cross-platform apps for clients all over the world.

I’ve also enjoyed connecting with other platform developers — at conferences and meetups worldwide and in various online support forums.

During all this time, I’ve noticed a few common myths about Titanium that keep popping up in various places, and in the technical press, and it’s time to set the record straight and bust these for good!

Myth 1: “Titanium is hybrid”

Easily the most persistent and common myth. I regularly see Titanium compared to other hybrid products like Cordova / PhoneGap. (We’ve been battling this confusion for years.)

Hybrid apps are web apps that run locally on the device. They are built with HTML and CSS and are essentially locally running web sites wrapped in a webview.

This native wrapper provides hooks and connections to native features like push notifications or access to extensions and other native elements. However, the bulk of the user interface remains web-based.

Because Titanium uses JavaScript, it’s often referred to as an HTML + CSS solution, which it most definitely is not.

Say it with me: Titanium is NOT hybrid. Titanium takes JavaScript and renders fully native apps. You never need to create HTML or CSS to build apps and you don’t need to use a webview (unless you want to to display some web content).

EVERY button, label, window and view is a native component.

Titanium is NOT hybrid.

(Say it a couple more times, rinse and repeat.)

Myth 2: “Titanium apps are not as fast as native apps”

Believe me, I’ve seen plenty of apps written in many different languages that don’t perform as well as they could (and I’m sure I’ve written a few in my time).

When it comes to mobile apps, understanding the mobile platform and taking advantage of commonly used native UI components is key to building a highly performant app.

True story — a few years ago I was asked to take a look at an app written in Titanium and running on iOS and Android. There were two separate codebases (I know!), and in both cases the developer had emulated a Tab Group navigation pattern.

Let that sink in — yes, they emulated a Tab Group. On Android AND iOS.

The Tab Group is one of the staples of iOS navigation — it’s baked into iOS and every iPhone and iPad and it’s free — it comes with window stack management, animations to open new windows, and automatic “back” functionality.

When I say it’s “free”, I mean it just works — there’s little to no effort involved in opening a new window in a tab, which means you write less code, it requires less testing and ongoing maintenance and it’s optimised for performance.

With this particular app I was dealing with, the developer had emulated an iOS Tab Group on both iOS and Android, rendering it at the bottom of the screen like iOS.

The problem was, they were emulating everything — from rendering icons and states, to labels, positioning, highlights and even the navigation bar, and the slide in and out animations on both platforms.

Not only that…they were also managing the window stack themselves, handling events like tab focus, and managing which tab was active, which one was opening a new window, etc.

They used animation timings that weren’t like iOS or Android, and the views that made up the Tab Group were overly complex and used dynamic positioning, resulting in lots of calculations when rendering.

The result was a user-interface that didn’t’ feel right — it didn’t feel like iOS or Android — a strange experience that just didn’t feel smooth, slick or snappy.

The client was about to move all development to traditional native development. They were convinced that Titanium couldn’t perform as fast and that going directly native was the solution.

I approached the issue by doing three things — firstly, I removed the custom Tab Group completely and secondly, I replaced it with a normal Tab Group control in Titanium, which rendered itself as a native Tab Group in iOS and a native Action Bar on Android. Finally, I implemented standard iOS and Android transitions to open new windows — so using the Tab Group active tab on iOS, and opening a new window on Android. I ensured I was using all the built-in, native animations that Titanium exposes.

The result was yes, tabs at the bottom on iOS and tabs at the top on Android — which didn’t look the same as the app did originally, but it DID conform to platform standards and wow, what a difference this made to the app performance!

All of a sudden, windows opened smoothly, the UI felt snappy and fast on both platforms, and as a result of this effort, the client not only changed their mind about going directly native, they continued development with me to enhance these apps and build more.

By the time I completed the work with them, they had a single codebase, sharing 95%+ code, had native UI apps running using standard iOS and Android components, and we could build multiple apps for different markets from the same, single codebase.

Those original tweaks took less than a day to implement, but completely changed the performance of the apps and the outlook of the project. Plus, the client’s perception of cross-platform native apps was completely changed.

Like any language and platform, writing well-optimised code that conforms to best-practice and UI standards is key to ensuring the success of your projects.

Myth 3: “With Titanium, I have to use Appcelerator Studio to build apps”

Regardless of whether you have an Appcelerator Platform license or use the free and open source Titanium SDK, you can use any code editor (IDE) you want.

Both the paid and open source offerings come with a powerful Command Line Interface (CLI) that allows you to create and build native, cross-platform apps and publish them to app stores, all from the command line or terminal.

Personally, I’ve been using the CLI for years — despite having an Appcelerator Platform license. My preferred editor is Atom (it changes from time to time depending on my mood). Before that I’ve used Sublime Text and Visual Studio Code and of course Appcelerator Studio too, but for me, Atom + the CLI works great.

Appcelerator Studio is ideal if you want the complete “one-click” package — install it and it’ll take care of setting everything up, configuring your environment and provide you with a fully-functional IDE.

For me, I like the flexibility of the CLI — the ability to script it, add hooks and other commands, and run grunt tasks and other scripts that make it easier for me to create, build and publish apps.

Appcelerator Studio of course has some awesome features like interactive debugging and even a UI designer, but ultimately it comes down to a personal preference and I’m glad to say Titanium is flexible enough to work the way YOU want it to.

Myth 4: “Titanium has to be updated before I can support new OS features OR I have to write native modules”

So we know that Titanium works by taking the individual platform SDKs and wrapping them in an API that makes them accessible with the same code — you create a Button on iOS or open the camera or image gallery with the same code you use on Android etc. This means you don’t need two separate tracks of code, as is the case with some other cross-platform environments.

Of course, there are times when you need to access platform-specific features such as SiriKit or Android Pay. Historically, developers would have to either wait for Appcelerator to add support for these features, or write native modules themselves in Objective-C or Java.

This has all changed with the recent release of Hyperloop, which provides access to EVERY feature of the underlying platform SDK, even if it’s not currently supported in the Titanium cross-platform API.

With Hyperloop you have access to 100% of the underlying platform SDK from JavaScript — you can create your own modules using just JavaScript. You can even include Objective-C, Swift and Java files alongside your JavaScript files and call methods and properties directly within these classes.

This means that when for example, Apple releases the first beta of iOS 11, you’ll be able to use Hyperloop to access all the new features without any updates to the Titanium API.

With Titanium and Hyperloop, you have a powerful cross-platform API and full access to the underlying platform SDK, all from JavaScript.


  1. I’ve been using Titanium when it included the Desktop platforms. I want my app to be available to all platforms including the Desktop. I was using it until the TideSDK Developer (which had the buggy version of WebKit) and I’m one of those who waited for the promise of the fork TideKit that failed miserably. Sadly, the only tool right now to do that is with hybrid apps which, I agree, suffers greatly with performance. I’m still hopelessly waiting for Appcelerator to bring back Desktop support. 😉

    • Thanks for the comment. Personally I’d love to be able to write Titanium apps for desktop — I’m not sure that’s in the pipeline but you never know 😉

  2. Great article, this sure changes people their perspective on Titanium. Another thing that I hear from students and colleagues is that they often tell that Titanium apps do leak memory and that it’s hard to clean up controllers. Maybe that you can add in a myth about that or make a separate up to date article about this topic? This might clear the air for some people 🙂

  3. 1. Titanium IS hybrid, just not the way you define it. The logic runs in a V8 virtual machine on top of the art/dalvik vm). If this is not hybrid, I don’t know what hybrid is.
    2. Titanium apps *are* not as fast as native apps, certainly on Android (on iOS it’s less definitive). I’m developing “Hop Email Messenger” app for Android, and I’ve gone through GREAT length to make it as responsive as it is. And it STILL not as snappy as it would have been if I wrote it native.

    • Thanks for the comment.

      1. Pretty much everyone’s definition of Hybrid is:

      “web applications (or web pages) in the native browser, such as UIWebView in iOS and WebView in Android (not Safari or Chrome). Hybrid apps are developed using HTML, CSS and Javascript, and then wrapped in a native application.”

      Since Titanium renders a native UI that doesn’t require a webview, it doesn’t fit into this category — it isn’t Hybrid.

      2. I’m sure you have your own experiences with Titanium — I have mine, and like others go to great lengths to ensure our apps are responsive and work great on all platforms. Without knowing more about the structure of your app I can’t give specific advice but there’s a few optimisations you can do on Android like using ListViews over TableViews, optimising layouts to reduce view-as-divs style layouts, optimising memory and controller clean-up and other examples.

      Happy to take a look at your code if it helps.

  4. Honestly, I think this platform is falling quickly behind similar solutions like React Native, Nativescript, etc…

    The “not hybrid” solutions in those others have more/current community driven libraries and arguably better access to the native code if you need it. Android most of all.

    • Thanks for the comment. There are some similarities with how other tools do cross-platform, and some major differences.

      For example in RN you have to split your code from the initial index file, whereas in Titanium you can share 95%+ of your code, and choose to split views, or controllers and styles as and when you need to.

      Titanium has a strong cross-platform API and native modules used to be necessary to add custom SDKs or access specific platform features — and with Hyperloop you have 100% access to the underlying SDK with JavaScript.

  5. In Germany a problem is, that some people thinks, everyone can develop JavaScript and now, everyone can develop apps! That is stupid.

    People starts development and with problems is this a problem from Titanium. That is stupid again and not fair :-(.

    And some customers think the same after a stupid consulting :-(.

    And “consultants” bash on own websites and blogs :-(.

    Thank you for this :-).

    • Thanks for the comment. I don’t think it’s a problem just in Germany — JavaScript is a simple and yet complex language — simple in the way it lets you achieve lots of things in lots of different ways — add to that mobile and you have added complexity.

      It’s also a problem that people come from web development and because Titanium and other platforms use JavaScript they think they can load of views with “divs” and “spans” and lots of layout elements, without realising that the more you overload a UI, the more issues you can have (irrespective of whether it’s Titanium or something else).

  6. Myth 2: “Titanium apps are not as fast as native apps”

    It’s true, because Titanium don’t support multithreading

    • Thanks for the comment — obviously it depends on the kinds of apps you are developing as to wether multi-threading is going to be of any benefit or if it’s even relevant.

      (For example, an app that is downloading news items from a remote server to render into a view wouldn’t benefit from multithreading since it can’t do anything without having the data downloaded!)

      In my experience over the past 6 years of building cross-platform apps with JavaScript, the performance I see from the apps I’ve developed is as fast as native. You may have had a different experience.

      Do you currently have a need to do multi-threading in the apps you’re building with Titanium currently? If so let’s connect on TiSlack — it would be good to discuss with the the community — see you there!

  7. But you still can’t develop for iOS using a Windows machine. Or am I missing something in the documentation?

Comments are closed.