Cross-platform development for mobile is hot; and numerous approaches are vying for attention. One notable contender is PhoneGap, an open source project which uses the browser and JavaScript engine already present on a device as its application runtime, but wrapped as an application and with the possibility of writing native code extensions. PhoneGap was created by Nitobi, and I spoke to Notobi’s president and co-founder André Charland about the project. We discuss the technical and business merits of the PhoneGap approach, how it compares to native code, and the significance of Adobe’s recent announcement that PhoneGap support is integrated into Dreamweaver 5.5.

What is the rationale behind PhoneGap?

It’s quite simple, we do PhoneGap to build cross-platform applications using web technologies, HTML 5, CSS, JavaScript. One of the reasons the project got off the ground was that when Apple released their iOS SDK back in the day, it was all Objective C. We thought some people might like this, but probably a lot of people would want to use HTML and JavaScript. We got that working and we could call their APIs natively from JavaScript, then we realised we could get it running on all the other platforms, Android, Blackberry, then Symbian, then WebOS.

There’s all these handsets out there and smartphones and different operating systems, and you can either build externally, and try to hire an agency to build all of them which is very expensive, or you can try to find individual developers and bring them up to speed, which takes a while and also is expensive, and those guys are hard to find.

How many people are working on PhoneGap and how does this open source approach make sense for you business-wise?

Nitobi has 20 engineers, and half of them are working on PhoneGap a lot of the time. There’s a core contributor community of about 60 people, so obviously most of those are outside Nitobi. The next biggest corporate contributor is IBM, who have a team of 5 people pretty much full time working on PhoneGap and contributing back. That’s all public, you can see that if you go look in our GitHub repo. We’ve had contributions from Sony Ericsson early on, we’ve had contributions from Palm who are now HP, for the WebOS stuff, there’s plenty of people porting and very interested in PhoneGap.

Then the business side of it, we like to call it the Mullet business model [laughs]. The business up front is typical open source support and services and training, the standard kind of approach, lots of open source companies are using that model. Then the exciting part in the back is a platform as a service called PhoneGap Build,  which lets developers compile, build, debug and then deploy their applications in the cloud. So it eliminates all the headaches of setting up and configuring six different SDKs and all the different smartphones.

It does all that in the cloud, you send up HTML and JavaScript, our servers spin off and compile all the different binaries for iOS, Android, Blackberry etc, and you can then test the apps on devices, send to the app stores, or in certain cases like Android you can send them directly to your end users. That will be a typical cloud service with a subscription model and also pay per use.

That service is currently in a relatively private beta that we launched right at the end of last year, and traction has been really amazing, I think we’re close to 8,000 apps built today on that platform, and about 6,000 developers working who are signed up for it, and we’re targeting commercial release later this year.

Most of a PhoneGap application runs on whatever the browser and JavaScript engine on the device happens to be. Doesn’t that mean there are inconsistencies and unpredictable behaviour?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries.  There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that,

We have looked at an option around PhoneGap where we don’t leverage the native WebKit. Say we ship something like QtWebKit as part of PhoneGap. We’re still entertaining the idea, but we want to wait and see what we can do with what’s resident on the phone, because we get a lighter download. It’s something we consider, but I don’t think we need to go there yet.

Appcelerator Titanium takes a different approach how would you compare it to PhoneGap?

In the Titanium world you’re writing JavaScript that talks to the Titanium API, they have an open source side but at the end of the day it’s their API, whereas PhoneGap APIs are W3C compliant. We’re looking at DAP [Device APIs] and HTML5, to create a situation where the HTML and JavaScript you write for PhoneGap, a lot of that will just run in the browser too, as long as you’re not using some hardware API that you get access to in PhoneGap but not in the browser.

PhoneGap today, we have iOS, Blackberry, WebOS, and Symbian. Titanium has iOS and Android, Blackberry’s been in beta for some time now. So I guess those are the two core differences.

Then depending on how much you value open source or not, our community is a lot stronger and a lot more active, we have a lot of outside contributors to the project, it’s not just a Nitobi game.

Also there’s the tooling story around PhoneGap. All those JavaScript libraries, those are JavaScript libraries that people are familiar with, they are familiar with the development model, they can continue to use those skillsets directly for browser development. And then also from the IDE standpoint you can continue to use [what you want], whether its Eclipse, Visual Studio, TextMate, Vi, Dreamweaver – you saw the recent announcement. So you can continue to use these tools, it’s definitely a more open platform.

What is the significance of the Dreamweaver announcement? How is that going to affect PhoneGap development?

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

Were you surprised that Adobe as the Flash company was willing to build PhoneGap into one of its products?

Well, I wasn’t surprised by the announcement because we obviously helped them a lot with it! I mean, I have known Adobe and folks there for a long time, they invited me to be on the Adobe AIR launch tour back in 2007, 2008, talking about how to do JavaScript development in AIR for desktop. Adobe has had some support and interest in the HTML market for a long time. I am sure they have internal battles in there that I have no idea about. Obviously for them Flash is incumbent, but I don’t see it as an either/or scenario for them, I think they should embrace both equally, and continue to push that forward.

What do you think about the issue on iOS, where the new Nitro JavaScript engine doesn’t work with the embedded WebKit that PhoneGap uses? Is it something you are trying to address with Apple?

Apple is kinda closed from a developer reaching in perspective, so there’s not a lot we can do. They are aware of the issue, I know there’s a bug report, but I think that will work itself out in time, I mean it’s not really the end of the world but a nice-to-have feature and we want to see performance continue to improve. I’m sure it will at some point, for the reasons I stated earlier, companies are really competing to make the best platform for web technologies; the mere fact that they put in that technology in the first place is a good indication of what they’re thinking, longer term.

I have to take the fact that it’s not in the SDK in WebView at face value, that it didn’t make it into the build and they had to ship, but we’ll see what happens.

In situations like that we just have to wait and see, and so far every time we’ve done that we’ve been pleasantly surprised. You know, a few years ago people were asking us what our solution for Blackberry was going to be, and then they went and bought a WebKit company and WebKit is on Blackberry now, and it’s a much better world for everyone. Not just for PhoneGap, for everyone who’s a web developer.

What about Microsoft? It’s putting IE9 into Windows Phone. Are you likely to support Windows Phone?

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

So we could see some nice integration with Visual Studio?

Yes, exactly, and you know JQuery is already supported in Visual Studio so get JQuery Mobile in there, and hopefully some PhoneGap support, and then we’ll really have a great development story. Microsoft’s excellent at building developer frameworks and tooling. If they just get their browser up to speed, it’s going to be awesome, so we’re going to talk to them about that and work with them on some of their stuff.

What about local SQL – most devices have SQLite but Microsoft has SQL Server CE?

We’ve actually written an open source framework called Lawnchair which is an abstraction layer over all the different SQL implementations on these devices, so that’s how we’re dealing with that for now and it’s working great.

I think that will settle down. They’ll be some competition and people will try to differentiate and they they’ll have to come back around some de facto standards will emerge.

The native guys tell me, PhoneGap’s all very well but they’re never going to achieve the level of integration, the level of performance that we can get with native code. Do you think that gap will narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture.

There’s native plugins already out there for things like XMPP, for mapping you can use MapKit from your PhoneGap app, people have built native UI for scrolling large layouts, tab bars, that sort of thing. So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Qualcomm told me some SnapDragon stuff, they’re trying to hardware accelerate all sorts of features of WebKit for Android devices. You’ll get the same performance writing JavaScript code as you will with native code.

Today the story is different than it will be six months from now. It’s happening all the time. The bigger picture view is that if you’d told me seven or eight years ago that I’d be using a browser-based email client for my everyday use I’d have laughed at you.

PhoneGap is on version 0.94 at the moment, and some people would hesitate before using something that is lower than 1.0. When do we get a 1.0 release?

That will be there this year, within the next few months. The project is tracking quite nicely, 0.95 will be out in a few weeks, we’re hoping to get 1.0 out for OSCON in July but we’ll have to wait and see. The project is moving quickly but the market is also moving [quickly] and it’s a battle to keep up.