A couple of words on the Nokia Windows Phone strategy

On 11th of February 2011, Nokia’s new CEO Stephen Elop dropped the bombshell that Nokia is switching to Windows Phone 7 as their only smartphone software platform. There are thousands of blog posts already covering this, so I am not going to write at length. I only have one point to make, which is:

 Developers, developers, developers!

No, seriously. While I see the logic behind choosing WP7, and while I lament the minimized role of MeeGo in Nokia’s future plans, I think that they missed one very important thing altogether. One they can still fix. I am talking about a migration plan for the current Symbian developers who have been told to use Qt/QML and have been doing so. When Nokia has completed the migration to WP7, the developers who have been writing apps using Qt/QML will have to throw all their code away and start from scratch, at which point many might choose a non-Nokia platform to target next, just as well.  This is because (according to http://blog.qt.nokia.com/2011/02/12/nokia-new-strategic-direction-what-is-the-future-for-qt) there won’t be an officially supported Qt for WP7 port.

And for Nokia WP7 devices, there will be far fewer apps available from day 0 if the Qt apps can’t be easily brought over to the new platform, thus hurting WP7 as well as Symbian device sales.

Possible solution? 

Now I am no expert on how the Microsoft .NET CLR exactly works, but with my limited understanding at least, I don’t see why a Qt/C++ application couldn’t be statically compiled into .NET code just like C# and all those other currently available languages are. A QML app would work with a 10-liner C++ loader that pulls in QtDeclarative to run the QML. So technically the idea of Qt Everywhere is just as sound as anywhere else, also this would bypass the perceived fragmentation problem as the target device wouldn’t have to have any Qt stuff pre-installed for the app to work.

This is all I had to say for now. If someone convinces me I got it all wrong, I will update this post accordingly and be glad I was wrong (for once ;)

Update1: Waiting to see what this comment from Elop’s MWC 2011 talk will mean in practical terms:  "The question is, what do we introduce into the Symbian environment to ease the transition to Windows Phone. So that’s part of the mission that we’re taking on now."

Update2: Forum Nokia’s Vice President, Purnima Kochikar, clarifies the Feb11 message in this open letter to the developer community: http://blogs.forum.nokia.com/blog/nokia-developer-news/2011/03/25/open-letter-to-developer-community

While I appreciate his way of re-iterating what was said on Feb 11 (some people still didn’t get the basic points of that day, such as, no they didn’t stop making Symbian devices cold-turkey) and adding some details, I still don’t see anything concrete for developers transitioning from Qt/Symbian to WP7. Maybe the answer will be the reverse of what I was thinking at first: Silverlight for Symbian?

Steve Ballmer

I couldn’t resist putting Steve Ballmer here, sorry. Image courtesy of Wikimedia Commons.

4 thoughts on “A couple of words on the Nokia Windows Phone strategy”

  1. Microsoft doesn’t want Qt, or any other crossplatform tech that would fragment and/or ease migration FROM their platform. It’s not about what’s technically possible or good for Nokia. That’s what happens when you give up control of your ecosystem.

  2. Nokia could have insisted on having Qt-apps that would only be sold from Nokia’s own OVI store on WP7 devices. If this happened, we would all feel less cheated.

  3. I guess they could do it the other way around. Ship a Silverlight runtime for Symbian. Then Qt people would feel even more cheated, but at least they would have “a” transition plan for developers…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>