13 Flares 13 Flares ×

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.

13 Flares Twitter 2 Facebook 0 Google+ 11 LinkedIn 0 Email -- 13 Flares ×