There is a lottery whenever you download an application for your Symbian Samrtphone. I don't mean the lottery of whether you'll be able to re-download the app (although that can still be a concern); I don't mean the lottery of getting the right platform variation in terms of 3rd or 5th Edition or something even older (although that can be a concern as well); nor am I thinking about the “will the security certificate still be in date” when I install the app (seriously – who thought that expiring apps would be a good idea?)

No I'm thinking about the mix of C++ and Java applications that any Symbian software store has to contend with. While it's well-established in many computer platforms that you can use multiple languages and it should be indistinguishable to the user (i.e. it should just work), that's not really the case with the majority of Symbian Java applications.

First up, I'm not saying this is always the case. There are apps out there written in Java that really do make good use of the Symbian platform. The Gmail client has always been in java, and a number of developers could make java applications fly.

But I'm not looking at the exception – I'm looking at the majority of apps that you find in these stores. And this majority appear to be generic Java applications, churned out to fit into the Java platform with no consideration of what S60 and Symbian can do.

From the programmer's practical point of view, this is understandable – Java and J2ME is meant to be a 'write once run on everything' approach. They can address countless more machines than a single platform. But it does this by going for a lowest common denominator approach. You get a basic menu, a full screen input box whenever you need to enter information, and a number of other standard screen elements. You also have a graphical window you can use, but then menu handling and button control is up to the end user, and the UI can look like anything they want it to.

Is Qt the answer?

And here's the problem... you have a class of application that fills the app store with a tool that sometimes does the job, but fails to look good, fails to interact well with the UI of the phone, and becomes an unrewarding experience. In my recent review of Smart Trivia, there's a glaring fault in the Java code that does not display the picture of a flag, while asking “which country's flag is this?” To my mind this is an app that has never been tested by the developer on an S60 device – it's an elementary error. Yet it's still there in the Ovi Store, it's still counted by Nokia in the “pieces of content available” and it's still being used, in a tiny part, to sell the Finnish hardware.

Is there any indication of what you as the customer are getting? Beyond the 'carefully chosen by the developer screenshot' and text? Nope.

It's hard to spot a solution. Apple and Android have a playing field with only one strictly controlled environment (although Android 1.0, 1.5 and 2.0 are showing worrying signs of compatibility issues already) which keeps it under control. But Nokia, right now, have a mix of everything for their product lines and in the Ovi Store.

The future may well be sorted in terms of what tools are available for developers but is it going to help this disparate nature of apps? Probably not. Future C++ and Java will be replaced by... C++ and Qt. And of course there's more fragmentation in the store as S40 and S60 will be joined by the Maemo platform. How will developers address this mix? The fear is that they're going to do exactly what they're doing now with the multiple smartphone platforms – and standardise on the lowest common denominator for their coding efforts.

Or will web rule and Nokia's bet on Widgets benefit?

Will that be Qt? Nokia must certainly hope so, but the fractured platform strategy that leads to Java being the “second class” app on an app store is already evident in Nokia's line up and muddled signals to developers and the market aren't helping the issue. For the bedroom coder will it be a choice of Qt S60 or Qt Maemo for their application? Will there be some sort of 'compromise' that forces the respective UI on top of a basic app design? And will that somehow degrade the app in the eyes of the buyer?

Yes, there are Nokia widgets, but that requires a specific focus and packaging for a device. They will be promoted but will it be enough? On the horizon there is “cloud computing”, which would allow development effort to be focussed on server-stored code for people to access via their web browsers. The winner might not be native code on a device, but just an HTML5-compliant web browser that will ship on our smartphone...

-- Ewan Spence, Nov 2009.