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