At Mobile World Congress in Barcelona last month I met with Jeff Haynie, CEO and co-founder of Appcelerator. Appcelerator’s main product is Titanium, an SDK which takes HTML and JavaScript source files and compiles them to native apps for several platforms, including Windows Mac and Linux on the desktop, and Google Android or Apple iOS for mobile. RIM Blackberry support is in preview. Appcelerator has recently acquired the Aptana IDE for HTML, JavaScript, CSS, Ruby on Rails, Python and Adobe AIR. The company has also partnered with Engine Yard for cloud-hosted Ruby on Rails applications to deliver web services to clients built with Titanium.

What’s your take on the fragmentation in mobile app platforms and what about other platforms for Appcelerator?

We’re moving from a decade where it wasn’t very fragmented, with PCs, to one where it’s going to be highly fragmented by language, by different devices, and even within devices like Android it’s probably going to fragment itself.

That’s a challenge and an opportunity. An opportunity for consumers because it gives us a lot more choice, but also challenging for companies that have to deliver a product for consumers. So how do you do that? It’s challenging for everybody in the ecosystem, not just the people who develop apps. With any kind of transformation like that we’re experiencing right now, a really large problem becomes a business opportunity. So that’s what our value proposition has been; we want to help companies navigate and build solutions for that fragmentation.

As far as new platforms, today we think it is a three-horse race. A lot of people would call it a duopoly, but it’s clear that there’s going to be at least three to four major platform players, and arguably more than that. Apple with iOS, Google with Android, are going to have a big foothold. I don’t think we can totally count RIM out, there’s a huge installed base there and they have a decent set of products, especially with the new Playbook. And the unknown is what happens with Microsoft, nobody can count Microsoft out. This market is very volatile right now and it’s going to expand dramatically.

Who is your third horse?

Our third horse today is RIM, we support iOS, Blackberry and Apple. We’re evaluating a couple of other platforms. HP with Palm WebOS, for which we’re getting a number of requests from large corporate ISV’s, especially for specialised application use cases like field force automation. Then of course Windows Phone is on the list, we’ll see.

WebOS should be a good fit because it’s JavaScript [the main language of Titanium] but Windows Phone is problematic because there is no native SDK for it, does that block off the platform for Titanium?

They do have a native SDK in the sense that you can build apps for the platform, and we should be able to build support for Titanium on that. It’s a .NET SDK, we would have to build a translation into Silverlight. That’s how we do it for iOS, we translate code into Objective C. We don’t think it’s technically insurmountable. Same for Palm, Palm’s got a native SDK. We would most likely compile to native for WebOS, not JavaScript, to get maximum performance and expose all the native device features.

Tell me about your business model? You are open source, anyone can download the tools, but there is a big jump in price if you want to subscribe, it’s a kind of Freemium?

Yes, it’s the Freemium business model. So far it’s working well. The advantage is that you get a lot of people who can easily understand the value proposition, the technical details of what is in the product, and then make the decision if they want to use the product or not. Most companies have no problem paying for value. The hard part is the time and diligence it takes to determine if this is the software that works for me. Does it work in our organisation, does it fit into my architecture plans, does it actually work? It is easy once you understand that to build a business case. Our product adds a lot of value to our customers, they are willing to pay for that value.

So I think this type of business model works really well for this kind of product, especially if you are in an emerging market where lots of things are changing and there’s a lot of confusion out there. We think our business model is actually very sustainable. We’ve got a free personal edition, and a large part of that is open source, and then we have a more traditional commercial subscription for small and large businesses.

But even with the free edition you can compile and sell commercially?

Yes that’s right, but one of the things we’ve done is we’ve limited the type of company and the rights you get for that. In other words, we want to allow non-profits, or companies that are smaller than 25 employees, the ability to go build a business around our technology. But we also feel that with companies that are larger, we want to make sure that they pay for the value that they are getting.

So there are some restrictions on the free license?

Yes

There’s a big debate around about whether to take advantage of a fast Javascript engine on the devices, which especially for Webkit devices is nice because there is a lot of commonality, or whether to take the route you take which is to transform the code and compile it to native. Why have you taken that route? Might you ever consider running JavaScript on the device?

We want to truly build a native app, and to get the performance and the usability and the expectations of what a native app delivers, and the API access, you need to go our route.

Over the next few years as WebKit, as browsers get better and the rendering speed gets better, as we go to multi-core and quad core on the device, I think that will change. But that is the best of both worlds to us, because to the developer it does not really matter. Will we have a pure HTML 5 solution in future? Probably.

So you might go in both directions?

That’s the longer term vision.

Let me talk about the tools. You made the Aptana acquisition, which is a fantastic JavaScript IDE. How is that product going to change direction? For example, one of their things is to support Adobe AIR which I guess isn’t really in your business plan. Is that dropped now? How do you see the toolset changing?

We’ve got a strategy that says, we’re going to let Aptana continue as an open source project, we’re going to continue to invest in it as the main contributor to that. That will have a standalone brand and a standalone product roadmap, and that’s going to continue. They’ve made the best tools for Ruby on Rails, and Python, and JavaScript, etc, so we’re going to continue to make that investment and that’s very important to us.

At the same time we think we can leverage that intellectual property and that team’s knowledge and actually build a deeper experience around Titanium and the broader application tools that we need.

The other thing we see and have a shared vision for is that as the world moves from one which is browser-centric, with applications living behind the firewall, to one where more applications are physically on the device and there are more cloud services, the development model is going to change. So one of the things that we got excited about was this idea that you could build client-oriented applications and server-side applications in the one environment.

We think that’s very compelling for companies, because typically in the future you’re not going to have a native app without a cloud back end, whether it’s on your own private infrastructure or something like Engine Yard, which we announced a partnership with. That’s our vision. You will see designing and distribution and packaging and testing and other kinds of tools over the next few years.

You didn’t mention AIR in your answer, what’s happening to AIR support in Aptana?

We don’t have any update yet. We’re with Adobe on trying to figure out where we go from here. Obviously we have a competitive platform from Adobe AIR. But we want developers to have the best choice, the best tools possible. So competitively we need to build the best product. If AIR is a better product and people want to use Aptana to build AIR apps, then fine. That means we need to continue to work to make a better runtime for the desktop. But we have to spend a lot of money to support that, so we’re making sure that we’ve got Adobe’s support behind that.

One of the areas where Titanium is lacking is the visual designer. Can you talk a bit about that?

We don’t have a firm date yet, but we believe that there is a lot of value in cross-platform layout, especially as you start supporting lots of different form factors and devices. As you move from a television to a handheld to a tablet, and everything in between, what we’re finding is that people are designing different visual interactions. So it’s how you create an easier experience for designers and developers to collaborate.

We’ve got some ideas about how to do that cross-platform. Titanium today supports it from a code standpoint, but we want to make it easier for developers and designers to be able to design these cross-platform layouts, and to allow components and things like that to be brought together more quickly.

Would you use HTML and CSS for that layout?

It’s too early to tell.

Are you able to give me numbers that would help me understand what your place is in the market for mobile development?

Yes. For mobile development, we have about 20,000 apps in the App Store built on our product. We are trending about 2,000 new apps being built a month. We think that makes us the largest aggregate publisher of apps on the Apple or iTunes marketplace, and Android. We think we’re going to continue to grow at a rapid clip.

I noticed some developers using your tools were not happy about the debugging experience. One of the issues is that you code in JavaScript and do a compilation, which generates other code, and then to debug it you’ve got the challenge of the error being thrown on a different platform and it tracing back to what transformation or what bit of JavaScript triggered the error.

What we like about Aptana is that they’ve got phenomenal tools around debugging and cross-language debugging. So that’s a big win for us. The team is working on that. It’s one of the first integration projects that we’re working on. Debugging can be quite complicated but we know it’s extremely important for any modern tooling.

It will be a JavaScript debugger, so you will be able to put breakpoints on JavaScript code and step into them and do it as if you were in any modern tool.

With Titanium, does anyone ever try to tweak the generated code?

No, what we have is multi-levels of ways to extend the way code is generated. At the lowest level you can build what we call a module, which is how Titanium is actually built.

We’re experimenting with the new release for Android, for example, which has a native SDK. With that you can write C++ or C code alongside JavaScript and that gets compiled in one process. You can drop down into native C++ and do this action, or render this 3GL, whatever you want to do. That’s a nice intermediate step to optimise, much like in C++ you can do an ASM block for tight optimised code.

We’ll continue to improve the tooling, the extensibility. We have a very extensible product already. It’s a very new space, a very new set of emerging platforms, and we’re taking a long view of this.

Steve Jobs has been dismissive of cross-platform tools, arguing that they deliver a less performant and a less integrated result. Is he right?

Yes and yes. I think there is a valid issue.  Something we’ve worked really hard on is not becoming a least common denominator solution. I think Flash has really suffered from that. You can build an app but it looks like a Flash app across five different platforms, it doesn’t expose a lot of the great features. But if you look at a lot of Flash apps they look beautiful, incredible, you could never tell that they were built in Flash in some cases. You can say the same about Web, about HTML 5, there are some incredibly awful web sites out there, and there are some incredibly awesome things like Gmail. So it’s really up to the application, not as much the tool. It’s up to the application designer and the company building an app.

Native compilation is a big part of what we’ve done to try to help this. Exposing the native API and the native access to features is part of the core platform. It’s not that it looks like a native app, it is a native app. Consumers and users can’t tell the different. That’s step one.

Step two is trying to make it easier to build a beautiful looking app. That’s where we’ll continue to add value to the stack, as you go from very basic tools that help you construct any kind of app, but then as you layer on better UI widgets, better cross-platform animation, out of the box, and packaging those so that every app has that kind of usability and experience. The bar is being raised constantly, right? We’re seeing better and better application interfaces, better touch interfaces, and that’s all about the experience.

To me it’s less about the aesthetics its about usability. So I think Steve’s right in the sense that you’ve got to have a high bar, and you’ve got to be concerned about performance and usability and experience, but we think we can provide that.

Tell me about the Engine Yard deal, was that because of Aptana and its Ruby on Rails support?

We’re working together to build some services and products that are going to be optimised for cloud deployment, especially in Ruby. What we found is that there’s a large group within our community that are using Ruby as the back end. More and more people want to do that in the cloud. Given that Aptana has a deep heritage with Ruby and RadRails, it was very natural to us. You’ll see more and more things over this year that will be related to how we optimise that experience, how do we give customers a great out of the box solution for the cloud.

Further observations here.