WebKit: Bridging the Great Mobile Divide

I hate Objective C and I hate Apple's Xcode and I think I hate Apple's AppStore policies even more but the people do love their iPhones. Furthermore, if you've had to deal with development on many different smartphones on the same project, you know how painful this is. You code one version for the iPhone, then you port it to BlackBerry, then Windows Mobile, then Nokia N60, and if you're lucky, Android.

So, if you want to develop for iPhone you either have two choices: develop a web application or go native. Unfortunately, even if Mobile Safari is a fantastic browser, it doesn't yet implement all of the HTML 5 features. Assuming iPhoneOS 3 here, Safari supports the following:

• The new video/audio tags. Albeit using only mp4 containers, h264 video and AAC audio. Furthermore, it does so by opening the video player application, in effect exiting the browser
• It supports app cache. With the proper manifest, your application's assets will be stored locally. Opening the door for the application to run without connectivity
• Support for HTML 5 databases. First is the assets, then it's the data. With both, your application can potentially run without connectivity.
• Canvas. It supports canvas for more complex rendering.
• Workers. Thread workers so that long running JavaScript code doesn't need to lock up the user interface

The only big in-draft HTML 5 (the file desktop API isn't in the draft yet) feature it doesn't support is geolocation. That being said, what if you need access to the accelerometers? Or the iTunes music library? Sorry, you're back to native and coding in Xcode and Objective-C.

Well, a funny thing happened to me the other day while watching this Google I/O session. I was expecting an introduction to the C/C++ kit and that's it. Turns out that was pretty boring. What wasn't boring however was the idea of using a web view and injecting custom JavaScript element in the document's DOM.

That concept introduces a new, more sane, alternative to coding in Objective C and Xcode and supporting many different platforms. Basically, you write an HTML 5 application using GWT. So you're writing with Java 5 syntax in the IDE (and debugger) of your choice for the majority of the application. You only write a small shell containing web views in your iPhone application.

So how about porting to other phones? Well consider the following phones that have WebKit in some variant or another:

1. BlackBerry. Ships with a WebKit based browser since 4.6. That means the Storm/Bold, won't cover most of your users but eventually it will. Please note however that JavaScript is disabled on BlackBerry phones by default.
2. Android. Ships with a WebKit based browser.
3. Nokia S60. WebKit is now the default browser engine in S60 phones. Write a shell using C++ and Qt.
4. Windows Mobile. WebKit is nowhere to be found. Again, not a problem since the Qt port to this platform has WebKit, write a shell using C++ and Qt.
5. Pre. Ships with WebKit. Not only, but Palm only wants web based, HTML 5, apps to be written for its phone using WebKit. They even introduce some new DOM elements to access other services in their implementation.
6. Finally, iPhone, write a shell in Objective C embedding WebKit.

The strategy is the same, use a native application so that you're not jailed by the browser but keep most of your code portable by embedding a web view using WebKit. Furthermore, thanks to GWT's deep JavaScript integration and GIN, you could write interfaces that get bound to the proper native/platform specific implementations automatically at runtime.

So now we actually have a platform for sharing a lot of code between the major smartphones out there. And what if you need those iPhone like visual effects? Well, it's absolutely possible with JavaScript. Consider gwt-fx, it has all the standard iPhone visual effects and more and when you're stepping out of what the standard iPhone controls do out of the box, is actually easier and less verbose to use in terms of code. For your enjoyment, gwt-fx has an effect playground available here.

Ah, NSObject reference counts, how will I miss thou? Well, not at all I must say.