Cross Platform Tools Report

visionmobile.gifVision Mobile has a new, free, large report on cross-platform developer tools. They bravely conclude that  "cross-platform tools will become “business as usual”".

Incidentally, only today, I read about AppSpotr a cloud based app generator and how it doesn’t live up to expectations of developers, end users and clients. This is typical. Some of the cross platform tools seem to have large developer bases but these are the people evaluating them which isn’t the same as those using them in non-trivial commercial apps. As Vision Mobile themselves uncovered, there’s a significant amount of experimentation and churn.

However, I do agree with Vision Mobile when they say… "Now is the time for well-funded vendors with great tools to prove themselves and establish a firm beachhead."

I think that many cross platform tool vendors have under-estimated the complexities of being able to provide a fully featured tool that provides, technically and visually, more than a web site might provide. It’s a huge undertaking to map to the majority of APIs, cross platform, while retaining a native look and feel. It’s also an ongoing undertaking because APIs change and new devices become available. This needs huge funding to do it well. I don’t believe it’s impossible but we are long way from it being "business as usual".

As I previously mentioned, I think it might be necessary to move away from HTML and Javascript in order for tools be suitable for professional use. I also have Tips for Assessing App Generators if you are considering this path.



verious.gifAs the mobile development market matures, will will start to see commercial ideas more normal on the desktop/server applied to mobile. One such idea is Verious which comes across as a ComponentSource for mobile… with a twist. The twist being that potential buyers can request and vote on components

Verious lists iOS and Android components and SDKs. If you wish to sell components, they takes between 20 and 40% commission – currently set at 20% until December 31 2011.

In past years, tools and components for mobile weren’t viable because there simply weren’t enough developers. However, I think we have reached a tipping point where supplying the tools can become a business in itself.

The End of Orbit and MeeGo Touch Nokia UIs

nokia.gifNokia’s developer-related press release yesterday was mainly about solely using Qt going forward to develop for Symbian and MeeGo. This applies both internally at Nokia and to 3rd party developers. In the future, the built-in phone applications will be written using Qt itself.

However, having read a post by Gorkem Ercan (who works at Nokia on the Java platform), I think Nokia’s changes are as much about UIs as they are about tools and operating systems.

First, lets look at what we have previously been told. Symbian^4 was to have a new UI called "UI Extensions for Mobile", previously codenamed "Orbit". This is the new UI to match (or beat?) that provided by the iPhone and Android. The new UI (pdf) was built using Qt and looks something like this…


One problem with the UI was that it was going to totally supersede the S60 Avkon UI Framework thus making all past 3rd party applications incompatible. This sort of made sense because you don’t want both old and new style UI apps running in the same phone – it would look a complete mess.

At the same time, Nokia was working on a new UI for MeeGo called MeeGo Touch. Again, this was created on to of Qt. The developer guidelines show it looking something like this…


Referring to Gorkem’s post we are told that "Orbit UI and its sister MeeGo touch now vanishes and Qt and the new Qt Quick becomes the main developer focus for Nokia’s internal and external developers."

As Gorkem puts it these UIs "did not provide a superior solution to a technical problem". In other words, they were not good enough. This has serious implications. It also explains why MeeGo has been delayed.

So what’s the future for Nokia’s UIs? Here are some observations and thoughts.

  • The previous Orbit and MeeGo Touch efforts were too separate. Although Nokia proclaim the benefits of cross-platform development using Qt, the UI part would have used different libraries for Symbian and MeeGo. As a third party developer (or even a developer at Nokia), this isn’t what I want if I need to move my app between the platforms.
  • The example images above are surprisingly similar. Any re-worked Symbian/MeeGo UIs might also be similar. If they are, why can’t they use the same developer API but display (adapt) differently on the different devices/OS platforms?
  • Taking this further, a more radical approach might be to have the same UI on Symbian and MeeGo. Nokia has proven it’s difficult for them to create just one great UI so why double the problems (and costs)?

Many Nokia N8 users are celebrating that they were told yesterday that their Symbian^3 devices will be getting incremental improvements that will take them to what would have been Symbian^4. I currently don’t see how this can happen technically without allowing both new and old UIs to co-exist on the same phone (which is messy) or breaking support for older (Symbian) apps. I suspect it will be the latter now that Symbian won’t be a development option. I suspect the compatibility promise will be just for apps developed with Qt.

Update: After I wrote this, Gorkem updated his post to say… "The good folks on Forum Nokia has informed me about MeeGo touch. Appearently, MeeGo touch is not going away immediately in Harmattan, however it is not the recommended UI toolkit.". I am not sure this changes much. "not going away immediately" and "not the recommended" seems to imply it will eventually disappear.

Need for RAD Tools

rad.gifRecently I have had a spate of individuals, as opposed to companies, contact me about possibilities for mobile development. Many of these people know nothing about mobile and nothing about IT. Almost all of them have been inspired by the possibilities and opportunities provided by the latest smartphones. Some people have some great ideas while many others are so far removed from what’s possible today.

While individuals’ enquiries don’t tend to be that useful for me (they tend to have little or no funding and no realisation how much development costs), they do demonstrate a need to create applications in simpler and cheaper ways.

I think tools could be greatly improved. I am not talking about runtimes or 3rd party frameworks here but tools that developers such as myself use on a day to day basis. As I have previously mentioned, while runtimes or 3rd party frameworks are ok for some applications, they tend to fall short of what’s required for most serious commercial applications.

Take UI and application framework tools. Symbian, Java ME and Microsoft have some visual tools that allow you to build up UIs and frameworks. In comparison the iPhone and particularly Android UI tools are currently poor. Even the Symbian and Microsoft tools could be greatly improved and extended to allow visual creation of applications from commonly used (and more importantly pre-tested) code building blocks. There are opportunities for people to create this stuff.

iPhone HTML Tools and Apps

phonegap.gifA short while ago, I wrote how there’s a huge potential market for a fully featured cross-platform application generator. What tools that are available, are either functionally incomplete or don’t support many platforms.

However, this doesn’t mean they can’t be used to write certain types of application. One requirement I am increasing getting is from small/self publishers and brands who want to publish information (usually on the iPhone) without actually interacting with any phone specific features.

This can, of course, be done on the web without an application but you lose the discoverability that’s provided by an app store. However, some might argue that, with 140,000+ apps, iPhone apps have also lost the ability to be easily discovered. Coincidentally, Taptu’s (the mobile search people) latest metrics show there’s growing life in the mobile web.

It’s possible to use one of many (paid for) online iPhone app generators to auto-generate an application. However, in many cases you will want more control than the templates provide.

It’s actually relatively easy (and free) to create a more customised app for the web or for the phone. Start by looking at jQTouch. It’s probably the best plugin/library that allows you to write html pages with an iPhone look and feel. This will get you a great mobile web app with minimal effort.

If you need an installable application as opposed to a web application then take a look at PhoneGap. I was once wary about using frameworks like PhoneGap and Rhomobile because of the problems with Apple rejecting applications because they were using 3rd party frameworks. Since then, lots of lobbying has made PhoneGap (v 0.8.0) officially permitted on the app store so I now take it more seriously.

It’s possible to use jQTouch within PhoneGap. There’s a very recent tutorial at tutsplus. Also, if you are quick, there’s a whole O’Reilly book online (for review) at the moment on building iPhone Apps with HTML that includes a great chapter on including jQTouch within PhoneGap.

509 Bridges the App Web Gap

5o9_logo_web_S.pngLast year I mentioned how 5o9 had developed a solution that allowed BlackBerry and Windows Mobile device location to be made available to web sites. Since then, things have progressed and they now offer a range of multi-platform tools for mobile developers.

5o9 told me that their view of the future is that for mobile to really take off the web has to know the end-user better. This means that web browsers need better access to phone features.

If you go to the 5o9 web site you can learn more. However, what it doesn’t say is how this technology works and how it might be integrated into your mobile solution… so I dug deeper.

The 5o9 solution is a simple mobile application that can share critical meta data (without the need to type it in) with any web app in the world. It works by extending the HTTP protocol with new customizable HTTP_X headers. At the server side the data is accessed via php, perl, asp or whatever you like. In addition, menus options can be added to the browser.

5o9 actually provides a set of complementary tools…

  • A web browser helper application that injects extra http headers containing phone information (location etc) into a http request, that can be read at the server. It also improves the UI of the browser to make it more contextually aware just like a mobile application. The web browser UI is also programmable from the web server side with existing server-side skill sets.
  • The simple application I mentioned is auto generated via the online ‘Maggie’ tool. You get the auto generated source code that allows you adapt (for example brand) it to your own needs. End users can install multiple mobile (Maggie generated) apps and they all communicate to the web server via the browser helper object.
  • JSAPI for Windows Mobile, Symbian and iPhone solutions allows you to write Javascript to access the device side capabilities. You can see how this works by going to and do a view source.

The licensing model is currently free for Windows Mobile & BlackBerry. Customised versions for all platforms are available for $5k per platform (you get your own brand and specific data sets, plus more contextual menus). Real time encryption and content acceleration starts at $15k per server. If you are an ISP or MVNO and want a site license to install it on everything then they can accommodate that as well

Some people think that the future of mobile is the web. Until such time, technologies such as those offered by 5o9 can be used to bridge the gap.

3rd Party Mobile Development Tools

redfive.JPGIt’s sad to see Red Five Labs have ceased business activities. They used to produce a .NET runtime for Symbian phones. This allowed development of Symbian applications using Visual Studio .NET.

The fate of Red Five Labs is similar to Appforge. It’s difficult to make money from developers who are used to using free tools. The alternative of paying for the runtime on end users’ phones also isn’t viable. Generally, it’s difficult to make money from 3rd party mobile development tools, especially as the OS vendors and handset manufacturers are already providing them for free.

Meanwhile, there are (too) many ‘write it in html’ type tools that promise to create iPhone and Android applications but they really are too simplistic to create many types of commercial application. The demise of Red Five Labs and Appforge also shows the risk with using these third party tools. How long will they be around to support you?

Nevertheless, I believe there would be a huge market for a cross platform application generator. What I mean by this is something where you can write once and deploy (native) to many platforms and still retain the OS look and feel. Also, something that covers the majority of the native APIs. Such a thing wouldn’t be easy to produce. For example, just look at the difficulties (and timescales) Nokia is experiencing adapting Qt for Symbian and Maemo (see my related posts below).

Maemo Harmattan

maemo.gifI have been reading the rumours about Nokia’s Maemo Harmattan. Assuming this for real…

"Maemo was indeed headed for at least one Nokia phone. In fact, they say the eventual plan is to use Maemo to phase out S60 all together"

I have been a fan of Nokia Tablets ever since I purchased the 770. I always thought having a phone in the device was the missing element. Without it, it’s just a gadget for Geeks. With a phone inside, it could become something to challenge the iPhone and even S60.

While this news is welcomed, I do worry that this will be yet another phone OS. I suspect Nokia’s plan is to try and make Qt the main S60 development environment. There are clues in Symbian Foundation’s plan to make Qt’s Orbit UI a replacement for the current Symbian Avkon windows controls. Once this is done, in the very longer term, it might be easier to move developers over to Qt on Maemo.

All this sounds good in theory but my thought is that having Qt as a layer of abstraction over S60 and Maemo might not give developers enough control. Other frameworks/runtimes have shown that there will always be a substantial number of things that will necessitate coding directly on the platform. Then again, maybe Qt might be the first technology to break this trend.