Windows Runtime must come to Windows Phone

I’ve been trying Windows Phone 7 in its latest “Mango” version over the last couple of days and mostly enjoying it. One thing I am not impressed by though is the range of apps available. Have a look at the Marketplace – Microsoft may claim 30,000 apps, but given how unexciting even the “top” selections are, you can imagine how bad the bottom ones must be. Microsoft I guess has been guilty of accepting almost anything to puff up the numbers.

What would fix this? Sell more phones, of course; but also improve the platform for developers. Windows Phone 7.x is not a bad platform: you get Silverlight, XNA, C# and Visual Studio.

By contrast though, the Windows Runtime (WinRT) shown at the BUILD conference earlier this month is a platform mobile developers can love. Here are what seem to me three great features:

  • Three first-class languages and programming platforms – C#/.NET, JavaScript and HTML 5, C++ and native code. All three are strategic platforms. I particularly like the native code option, as many mobile developers like native code and it is a weakness of Windows Phone 7.
  • Asynchrony built into the platform. This is a smart move: make every API call that might cause a delay an async-only call. On top of that, build easy async programming into the languages. The result should give apps a responsive user interface almost by default; developers will need to make an effort to freeze the UI.
  • Contracts which integrate apps with the operating system and with one another. There are five contracts: search, share, play to, settings, and app to app picking (for example, file selection).

Microsoft’s Windows chief Steven Sinofsky says Windows 8 is for tablets but not for phones. But he has to say that, because if Microsoft announced that the current Windows Phone 7.5 is a platform without a future, it would further dampen enthusiasm for the product.

Is there any reason why WinRT should not come to Windows Phone? A few:

  • Windows Phone is currently built on Windows CE, a cut-down version of Windows, whereas WinRT runs on top of the full Windows API.
  • The Metro-style UI is designed for tablets rather than phones.
  • Finally, the existence of Desktop Windows is presumed in the current Windows 8 design. If Microsoft has not had time to work out a Metro-style UI for something, you simply use the Desktop version.

All of these are good reasons why the arrival of WinRT on the phone will be delayed, but none are insuperable. Long-term, I find it inconceivable that Microsoft will persevere with a different programming platform for the phone and for tablets.

What are the implications for Windows Phone developers today? Well, WinRT and Metro borrow from the phone OS, so the porting effort should not be too bad, except in the case of XNA, a .NET wrapper for DirectX which WinRT does not support.

Of course this post is entirely speculative, and I have no insight into Microsoft’s plans beyond what is publicly stated, so there might be other compatibility options when and if the time comes.

And it is time that is Microsoft’s biggest enemy. Fumbling tablet computing has been a costly mistake, and the big question is whether anyone will care how good some future Windows Phone will be, if the ecosystem which Nokia likes to talk about is firmly established as Android vs Apple.

One thought on “Windows Runtime must come to Windows Phone”

  1. Hi Tim, after /BUID/, I think that on some WP vNext (8?) there can be also WinRT on top of WinCE, and similary as there are desktop/classis apps for Win8, there can be silverlight/classic mode side-by-side with WinRT/C# (even possibly formally converted by VS IDE?, some things changed quite lot, so who knows) and also WinRT/C++CX + HTML5/JS (almost exactly the same thing as PhoneGap does just now, but baked into core in fact). For WP, there can be seamles integrationg between SL apps with WinRT, as they are not fundamentally different as desktop mode for Win8. Its nice time of changes today :-), and … PhoneGap is great quick prototyping thing, allowing fast time-to-market followed by “platform native” rewrite in case of base app success… Just I am curious about PG tooling … installing soon 🙂

Comments are closed.