Thoughts on Ti.Next

Blog Callout

I announced a pretty significant effort around Titanium last week during my keynote presentation at TiConf Baltimore. We’re calling the next major milestone Ti.Next — short for the next generation platform for Titanium.

If you haven’t seen the slides, you can check them out over at Slideshare.

Project Goals

Titanium has been an amazing effort over the past 4+ years and has grown a great deal. As I write this post, over 145 million people across the planet have experienced at least one Titanium-powered application. You rock!

Very few technologies reach this level of success and I’m proud of all the effort the team and the broader community have put into Titanium to get us this far. If you’re one of the 500,000+ developers that have built an application with Titanium, thank you.

However, when I think about the next 4 years of where I’d like to take Titanium broadly – we need to rethink the current architecture and take into account all the lessons learned and also the fact that the entire marketplace has changed when we first started Titanium. When I wrote the first lines of code for Titanium, Android barely was relevant and the only real smartphone operating system was iPhone (not iOS, that hadn’t happened yet). A lot has changed in a short period of time. Not only is Android a major market share leader with Apple, but Microsoft now has a viable platform, RIM has re-tooled Blackberry, Firefox has just released the first phones with Firefox OS, Samsung and Intel have collaborated to create Tizen and Ubuntu is doing something, still not sure what. And, there’s still the web as a mobile platform – which is growing. And, likely, we’ll see more attempts at building an OS — mobile is just too important.

Like any code base, however, you tend to get some level of code rot after so many years and so many different variations and changes. It’s hard to take something so successful and re-invent it — and still maintain the importance, relevance and stability that our customers and community has come to expect. But great software companies do that all the time. They throw out something that works, for something that works better.

So, I have a few goals for Ti.Next that I’d like to share with you so you can understand what I’m trying to do. I believe Titanium is as much for and about the community as it is about Appcelerator. And that’s what makes it so special to so many people.


I will assume you understand how Titanium works so I won’t try and re-hash the interworkings. However, generally, Titanium’s performance is close to or in most cases as good as hand-written native code. Of course, code is only optimized and as good as the developer who writes it. We’ve seen plenty of cases where bad application logic performs very badly and great code performs very fast. But, we would like to reduce as much of this possibility as we can to make sure that we can optimize as much as possible underneath the covers. Right now, an operation in Titanium (across the “bridge” you’ll hear people refer to it as) can be as much as a 10ms operation. That’s fast, but not too fast for modern CPUs. Our target is sub-microsecond operations — in fact, we think we can get faster in most cases than pure native code (Objective-C for example on iOS) by using a direct assembly (ASM) code generation process with FFI.

This will give us several major advantages:

  • faster execution operations against the CPU
  • much smaller memory footprint
  • no need to keep multiple copies of a user object in multiple memory spaces
  • simplification of thread creation, context switching and memory overheads


Our current approach is pretty novel and something that is patterned after the way node.js works. We believe JavaScript should be the right language to build Titanium, not just apps on top of the Titanium SDK. With Ti.Next, we’ve created a small microkernel design that will allow us to have minimal bootstrap code in the native language (C, Java, C#, etc) that talks to a common set of compilers, tools and a single JavaScript Virtual Machine. We have found a way to make the WebKit KJS VM work on multiple platforms instead of using different VMs per platform. This means we can heavily optimize the microkernel (herein after called the “TiRuntime”) and maintenance, optimizations and profiling can be greatly simplified. We’re talking about ~5K LOC vs. 100K LOC per platform. Big deal, yeah that’s right.

This takes me to the next main goal.


One of the problems with the current development of Titanium (and thus, the extensions and contributions around it) is that you have to understand the language of each target platform — Objective-C for iOS, C# for Windows and so forth. No code reuse exists between each implementation and you can only imagine some of the parity and bugs that sometimes creeps up. It’s hard to manage and expensive.

For the ultimate productivity, we want to get the same advantage that Titanium gives to the community using JavaScript. Imagine that! So, we’re going to make JavaScript the primary platform language for TiRuntime, not just for the apps that you create.

This will open up a huge new set of possibilities that are too numerous to discuss in this first post. But needless to say, the productivity that we will get around building Titanium is going to be breath taking – especially as it compares to how it works today.

Which really impacts the next goal, dramatically.


Our current R&D spend at Appcelerator – which is large (in the $10M+ per year range) – is over 50%+ in Titanium. For a free product, that’s pretty expensive! 🙂 Yes, we love you THAT MUCH.

However, we believe that we can cut the overall total costs of building and maintaining Titanium in ways that we couldn’t do in the current architecture. Today, each new platform is a linear-plus cost equation. Tomorrow, it will be fractional – in fact, each platform could drive down the overall costs to some degree.

By doing this it will allow us to make better use of our current R&D dollars and more importantly, allow us to really achieve the ultimate goal…innovation.


I feel strongly that the possibilities of Titanium are endless and the future is bright with Titanium, especially as we think about that future in a Ti.Next architecture.

Mobile innovation is rapidly increasing, not decreasing. We need to be able to move faster, to do more innovation around Titanium. We have a huge opportunity with Titanium to do things that would be impractical or cost ineffective with hand-built native built code or web-based apps.

In order to make this work, we need to spend more of our current dollars (in addition to growing our investments YOY) in innovations and new R&D vs. maintenance of existing systems. We want to support all mobile platforms — not just the important few. Our mission is for Titanium to be a catalyst for mobile innovation, not one that you have to worry about it staying current with new technologies.

I believe mobile innovation is continuous. I believe we’re just seeing the early days of adoption in mobility as we move from handhelds and tablets to a much broader set of devices that are connected to the cloud and to other devices. Think about this: only around 1.6-1.8 Billion people have access to the web – only about 25% of the world’s population. However, with mobility connected devices, we’ll going to see 75% of the planet moving online and we’re going to see new opportunities that never existed before. This is sort of a BIG DEAL.

At the iOS7 launch a few weeks ago, Apple announced that in the five years of the iPhone’s existence, developers had earned more than $10 billion through the App Store. The figure alone is astonishing. But what’s more amazing is the pace by which the number was achieved – half of it within the last year alone.

TiNext is the future of Titanium. And that future is very bright.

Stay tuned for more soon.


  1. Sounds awesome … unfortunately, I am having to now look at Xamarin as potential cross platform solution at this very moment. 2 main reasons

    – performance
    – lack of support and features on maps

  2. This sounds very interesting but I wonder what the timeframe is because this will be the first release that supports Windows Phone 8 and Windows 8 (is that true?). Before we’ve heard that Win support will come later (first it was communicated first half of 2013) this year and this feels like we’re more looking at early 2014, and then it will probably be a little bit shaky since it’s the first release. I have customers constantly asking me when I can port to Windows Phone 8. I have been telling them later this year but now I don’t really know what to tell them anymore.

  3. With the current Ti 3.1.1 the performance on iOS is on par with Native, I really can’t tell any difference.

    I strongly agree with the article that performance really depends on the architecture and logic of the code and optimization/experience on the developer.

    Curious & looking forward to Ti.Next

    Thanks Guys!

  4. Sounds very interesting, but also makes some concerns. Will the new platform be open source? Will we still be able to use the native modules that we spent much time on building?

  5. I’ll add a question:
    I have a module written in Java, that exposes a Java Android View (for using opengl es). Will I be able to port this module to without a complete rewrite?

  6. Very interesting article, indeed. I’m a mobile developer and Titanium is one of the platforms I was using (note the past tense). This was looking great at the beginning, quick and easy to use with JavaScript and other neat stuff. Nice for small presentation apps for iOS, the first ones I started with.

    But the more I was using it and more complex functionality I required, the less I was satisfied. Say I needed to process downloaded images in background to resize them and create thumbnails. Too slow and impossible to do it in asynchronous thread. Unfortunately Ti JavaScript code still executes in one thread and resizing the images blocked everything so UI events got triggered after processing the images (and users could experience nothing but lags and lags) and this sucks. Q&A didn’t help, nor did the support. Or another time I needed to test and debug on Android emulator. Long waiting time to compile, build and deploy the resources, too slow in emulator (I use 2.5GHZ i5, 8GB ram, SSD disc,…). Or I needed an Alert dialog with numeric input only. Possible only if I wrote a custom module (which was a pain). Other to mention: huge size of APKs and IPAs generated, unbearable debug support and poor performance in many cases, e.g. slow/lag scrolling issues on Android devices.

    I decided to go native. XCode works just fine, I can debug the code very easily code and be more flexible and use everything the XCode/Obj-C platform provides. Same goes for Android development (Eclipse/Java/Genymotion). No more lags, true threading support and much more. I’m happy and my clients are happy that the UI is fast, slick and responsive with smooth animations.

    In my opinion, Appcelerator folks should add async processing (like WebWorkers), as well as some sort of reflection to easily bind to native capabilities. Maybe then I’ll reconsider my decision.

  7. Windows phone has now surpassed iOS in germany. In europe, it has a market share of 10% now and is growing.

    So I think should be focused around the support of the windows platform. Considering the fact that the current stability level for android is about the same as the stability of titanium 1.5 for iOS (ie not very stable), i’d say it will take appcelerator about a year to get windows stable. This means that “real stable” support for windows phone will not come before the end of 2014, which is too late as far as i’m concerned.

    I’d say the focus of appcelerator should be stability and reliability of the core platforms like iOS and android, and add fancy stuff like alloy later. So focus on android now, as real simple apps still crash everywhere now (3.1.3) and need lots of workarounds. iOS has become pretty stable now since version 3.0.0. Then move focus to windows support. Forget about new features.

    • I totally agree with Woens: the development should focus more on support for Windows Phone because also here in Italy (which is one of the most important mobile markets in the world) Nokia Lumia sales have surpassed those of Apple.

  8. JavaScript was thinked to be a scripting language. I believe that it’s actually the main weakness of Titanium.

  9. Put some of that money to quality assurance, this week try to install titanium and the installer did not run, the examples are not compiled when I could compile the ide not find the emulator, including a certification that I bought did not work at the site, was a matter almost laughable.

  10. Any update guys? More than 1.5 years, crossing fingers to move to Ionic or wait for Appcelerator complete something. What is going on?

Comments are closed.