Titanium 1.0: The “App for Building Apps”?

The less-than-golden age of mobile

For over a decade, mobile developers have toiled in the trenches — largely unseen and at times feeling somewhat misunderstood as we wrestled with new tools and technologies, trying to determine which ones are going to make it and which ones to avoid.

We’ve built the super “to-do” list apps, the “print my email via Bluetooth” apps, defined new gaming categories, and much nore — all the while enduring the pain of the rise (and fall) of new device launches and SDKs.

We’ve seen platforms that were so popular it seemed that they just could not fail all but disappear and new platforms emerge that challenged our way of thinking.

Through it all we have held on to the belief that mobile was important.

It’s kind of felt like buying that piece of property in Orlando before anyone else knew that Mr. Disney was going to build a theme park just down the road — all the while wondering if the effort and investment was worth it. Vindication is ours if for no other telltale sign than the fact that when you explain to someone at a cocktail party that you write mobile software and they say “cool” rather than “huh?”.

Mobile Opportunities Abound

Mobile is hotter than ever today with a market boasting great devices and platforms, improving networks and applications. Lots of applications. Like the master marketers at Apple say, “There’s an app for that” — covering just about anything you might want to do. Of course, there are many more applications yet to write — and thankfully that means something more than just mobile Facebook applications and Twitter clients!

Despite the increasing popularity of mobile platforms, making money in mobile still carries a fair amount of risk.

Selling apps through the various app stores works well for some — though with application prices ranging from free to five or ten dollars typically, mobile software has really become a “huge volume” game for many developers. And volume means supporting lots of customers. Across different platforms. And mobile networks. This can be not only painful but expensive.

If only writing and supporting mobile applications were more simple and less costly — let’s have a quick look at the mobile development landscape.

The Classic Approach

The traditional means of building a mobile application has been to download (or purchase!) the tool set and latest SDK for your chosen platform. Once the toolset is installed, you set about learning the ropes of creating user interfaces, connecting to data storage, sharing data across the Internet, etc. Once the basics are understood, you then move on to writing and eventually supporting your application.

The language skills require for today’s mobile environments vary — today the popular platforms break out like this:

• Android — Java
• iPhone — Objective-C
• Symbian — C and Java
• BlackBerry — Java
• WebOS — JavaScript, HTML, CSS
• Windows Mobile — C, VB, C#

Each of these “native” environments carries it’s own risk and reward profile.

As the mobile space has become more popular, an increasing number of companies, including “house-hold brand names” are getting into the game — and in an effort to have their brand seen everywhere they want to be on multiple platforms. The challenge to development shops in this classical development approach is the need to maintain multiple skill sets — often leading to subcontracting or outsourcing development work for a particular platform.

As a long-time mobile developer, I certainly am not complaining about this outsourcing model — writing software for other companies has helped me buy bread and cheese to feed my growing family over the years. And it is often rewarding work — an experienced mobile developer can bring a significant amount of value beyond “just coding” to their clients. However, this out-sourcing model is not always the most favorable approach for the content owner or brand-name who wants a presence on multiple platforms and doesn’t have the means to manage multiple sub-contractor relationships.

The (very brief) Middle Age

In an effort to “simplify” the development experience and narrow down the skill-sets required, we have seen the emergence of the “hybrid” application. This flavor of mobile application development centers around the open source WebKit browser engine which is at the heart of iPhone and Android devices — and is finding its way into other platforms as well.

The general approach here is to create a “native” application which contains a “web widget” which in turn executes Javascript, using HTML and CSS for a user interface. The benefit of course being that you can leverage web skills rather than platform- or SDK-specific skills and to the degree that a compatible build of WebKit is available, a single application can target multiple platforms. Palm has bet their existence on this web-development skills model with their WebOS equipped devices. If this idea is new to you, we’ve given some coverage to these ideas in previous articles:

• The pioneer — PhoneGap
• Old dog, new tricks — Palm’s WebOS
• Building Hybrid apps — Android
• Building Hybrid apps — iPhone

The challenge to this hybrid approach is that it does not always create the highest-performing application. For example, sometimes an application can require multiple instances of the WebKit engine — and that doesn’t come without a performance hit. Marshalling data in and out of the WebKit/JavaScript environment can also consume cycles — and in mobile, every CPU cycle counts. So, what are we to do about that?

How do we get the benefits of “write once” but get to run a real, honest-to-goodness native application without the necessity to have everything be JavaScript and WebKit engines at run-time?

Many months ago we had a look at Arno Puder’s XMLVM project. XMLVM takes the approach of de-compiling byte-code into XML and then re-constituting the code to another platform. Kind of a “beam me over there, Scotty” approach to covering multiple platforms. I’ve seen it in action and its pretty cool to watch an Application written for Android run without source modification on both iPhone and WebOS.

As Arno and his team continue to flesh out platform and feature support, there is one other tool that is really picking up momentum, doubling their registered developers in just the past 10 weeks, namely Appcelerator’s Titanium 1.0.

The Titanium Way

I used to put Appcelerator’s Titanium tool in the category of “a commercial PhoneGap”. Historically, their technical approach has been similar, namely the “leverage WebKit and build a native application” model.”

But Appcelerator has always had large ambitions as evidenced by the siginficant resources available to developers. Their tools are developer friendly. For example, they have made deployment of applications considerably easier than the roll-your-own approach. Signing an iPhone application within Xcode takes a little know-how and not a little bit of patience. Well, it seems as though they have turned the corner a bit and hit the gas to attempt to pull away from the crowd.

With the recent introduction of Titanium 1.0, Appcelerator has graduated to a model where they cross-compile JavaScript/HTML/CSS into native code for iPhone and Android — no longer relying upon the WebKit engine at run-time.

Development is still done in JavaScript, HTML and CSS, however the resulting application runs much faster because the code is translated to “equivalent” native code, including access to device level features such as GPS, accelerometer, Camera — even UI “gestures”. See the image below for a glimpse of their architecture.

Titanium 1.0′s architecture

The key element here is a Javascript to Objective-C/Java “bridge” which converts the JavaScript code and maps calls into the respective SDKs. They have targeted iPhone and Android so far and plan on extending coverage to other platforms such as BlackBerry and Nokia/Symbian.

Clearly writing an application with a single and capable toolset such as JavaScript/HTML/CSS delivers benefits to the development team in terms of a more narrowly defined set of skills required — and arguably a faster development cycle all together, but Appcelerator claims some impressive run-time performance increases over “hybrid applications” as well:

• A 10x improvement in application launch time — no WebKit instances to bootstrap.
• Nearly instant screen transitions versus transitions that are typically 1-2 seconds with the prior releases — less WebKit juggling.
• A 3-5x increase in CPU utilization — native code runs faster than interpreted JavaScript within the one or more WebKit engines employed by the “hybrid” approach.

If these numbers are solid across all flavors of applications and platforms and their API coverage is solid, this is a significant step forward for mobile developers — old and new alike.

The Bonus Feature

If you’re saying, that’s cool, but I still like my classic SDK approach to writing mobile applications or perhaps you’ve become very comfortable with PhoneGap — both of which are very valid positions to take, you might be interested to know how Appcelerator has upped the ante for developers who choose their platform.

Appcelerator applications have built-in analytic capturing, allowing developers and application publishers to profile application usage.

Interested in knowing which menus or features were selected in your application? Built in. Or how about knowing which geo-sensitive searches are taking place — i.e. where your users are when they are using your application? Built in. Tinfoil hats anyone? Don’t fret — all location-based data can only be captured with the user’s permission.

What application publisher would not want to know how often their application is being used? And how users are navigating from one feature to the next? Is the application used beyond the first week? At a dollar an app, we live in a disposable application market, so this kind of data matters to publishers and advertisers.

All of this usage data is available via a soon-to-be-released portal allowing publishers the ability to see this usage data with varying levels of history.

Committed to their open source roots, Appcelerator’s Titanium 1.0 is available in a few different flavors. The “Community Edition” is available free of charge — each application displays a splash screen with an advertisement. Any ad revenue generated by an application is shared between Appcelerator and the developer — not a terrible deal.

If your application is not suited for this advertisement-driven model, you can choose from a couple of different fee-based options ranging from the “Independent” program at a cost of $499/year up to the SLA-based support for the Professional developer program at a non-trivial cost of $199/month per developer. Appcelerator is also looking to offer premium services such as training and developer communities, further demonstrating their commitment to this space.

Time will tell if they can pull this off — mobile has its risks. Choosing new tools can certainly be risky — it is not uncommon for applications to outlive the tools that created them. If Appcelerator can deliver on these promises, they will be a major player in this space — and a likely acquisition target by a bigger fish such as Oracle. Imagine the world’s most popular open source database (MySQL) in the same stable with potentially the most broadly used mobile application development tool set. With analytics. Built in. Crazier things have happened.