After a short historical overview and a short list of growing pains, in this, third installment of the mobile Qt app story, I will focus on what boulders remain in the path of widespread adoption of Qt among app mobile developers. Most of the technical groundwork has been laid down, but to reach a final resolution, it needs to include a bit more than just a healthy base.
Decouple Qt releases from firmware releases
As seen from the infamous PR1.2 delay, a coupled-with-the-firmware release cycle is detrimental to the platform. If multiple devices are on the market, it would mean instant-fragmentation as developers would have to code for the Qt released with the last firmware. This is eating Android alive, too, as various handsets have different upgrade cycles. A separate distribution mechanism HAS to be employed. It will be tricky as with MeeGo and Symbian^4 Qt is part of the OS and many teams will be reluctant to bet firmware functionality on the backward compatibility of Qt. But that is not the only thing that can cause fragmentation if it isn’t true that…
One mobile widget framework is enough
I harp about this regularly (and will continue to do so until I get good news from an official source :), the option to have separate widget frameworks for Symbian (Orbit/uiemo) and MeeGo (DirectUI/MeeGo Touch Framework) is something that is completely against what Qt is trying to accomplish by bridging the two OS-es.