I've written a few times about the general dissatisfaction I (and the team at FP) have been feeling over HTML5 as a route for delivering great mobile apps across platforms.

Back in June, I did a short talk at Mobile 2.0 in Barcelona where I presented an approach we've evolved, after beating our heads against the wall with a few JavaScript toolkits. We found that if you're trying to do something that feels like a native app, HTML5 doesn't cut it; and we think that end-users appreciate the quality of interface that native apps deliver. We're not the only ones.

Our approach is a bit different: we take advantage of the fact that the web is a standard part of any smartphone OS, and we use the bit that works most consistently across all platforms: that is, the JavaScript engine. But instead of trying to build a fast, responsive user interface on top of a stack of browser, JavaScript, and JavaScript library, we implement the UI in native code and bridge out to JavaScript.

Back-end in JavaScript: front-end in native. We think this is the best of both worlds: code-sharing of logic across platforms whilst retaining all the bells and whistles. We've called the product which enables this Kirin.

Kirin isn't theory: after prototyping internally, we used it for the (as of last night) award-winning Glastonbury festival app (in the Android and Qt versions) and have established that it works on iOS too.

Now, we're a software services company; we aren't set up to sell and market a product, but we think Kirin might be useful for other people. So we've decided to open source it; and where better to do that than Over The Air, just after a talk from James Hugman (who architected Kirin and drove it internally).

You can find Kirin on GitHub here. Have a play, see what you think, and let us know how you get on.

Comments

[Pedro]

Hi Tom,

Do you have idea, how much your productivity has increased with this approach? How many hours did your team hav spent developing the Kirin?

[Tom Hume]

Pedro

We used this approach for the Android and Qt ports of the Glastonbury 2011 app. The Android version came second and took half the time of Qt, we think much of this was down to our use of Kirin.

Modelling we did up-front indicated that using Kirin on a 3-platform project would save 30% of effort overall, and this feels about right to us.

I don't have a separate estimate for how long Kirin took to develop I'm afraid - we validated the approach in 3-4 days of experimentation and prototyping, but there's a journey between having a prototype and production quality code.