Why Windows Phone needs WinRT

Pretty provoking title, uhm? 😉

But pretty fitting for me, as well! Some days ago I posted a tweet saying that I believe Windows Phone needs an adoption of WinRT:

In this article I want to go into more detail and explain why I think this is true.

Windows 8 and WinRT

First things first: Windows 8 is coming around the corner, believed to be published in late summer or autumn 2012 (btw: what do you think about „Windows Metro“ as name for the final? ;-)). The beta („Consumer preview“) will come soon at the end of February. Win8 employs a new programming model for a new kind of apps: „Metro-style apps“, that are touch-first. Metro-apps can run on either Intel or ARM hardware and thus span functionality from tablet over notebooks/ultrabooks to desktop PCs. The old Windows desktop remains as part of the „Intel version“ of Windows 8, but will likely not run on ARM.

The Metro-app programming model comes with a core component called WinRT (Windows Runtime). That’s kind of Win32 API for the new (Metro) world. It’s an integral part of the operating system core and not an on-top layer like Silverlight or .NET. Instead it’s native and exposes OS functionality to developers. While calling Win32 API from managed code involves things like P/Invoke, WinRT components can be called in natural way from every supported language. Metro-apps on top of WinRT can be built with XAML/C#, XAML/VB, XAML/C++ or HTML/JavaScript, games are supported through DirectX/C++. That’s a huge deal for developers, who get great flexibility to develop Metro apps. Furthermore, they can author their own WinRT components in C#/VB or C++ and use them from every supported WinRT language, even JavaScript. Thus for example they are able to implement a WinRT component in C# which holds the core business logic and use this component naturally from a JavaScript Metro app. Way cool!

Windows Phone till now

Ok, let’s come to Windows Phone. While it has great reviews (I use it as primary smartphone system, prefering it over my iPhone 4), Windows Phone is still falling behind in sense of marketshare. Approx. 2% (or less) in the US is not where Microsoft believed to be after 15 months. There is a lot of buzz and fanboy war on each side of the smartphone community why this situation is real and if it will change. For sure, with Nokia Microsoft now has a superb partner for developing phones which attract people by design and functionality, but are manufacturers the real problem?

For me, Windows Phone faces 2 main problems:

• Hardware diversity: Consumers want to have a choice. They want to choose between budget phones over midrange devices up to the so-called „superphones“ on the market. Android has a great diversity in phone hardware and it sells really well. When you look at Windows Phone, you can’t see much diversity. Microsoft prescribes a relatively strict corset for hardware partners in terms of screen resolution, CPU, RAM, internal memory, interfaces, cameras, sensors and so on. Windows Phone devices don’t differ very much. And I would say the Nokia Lumia series are the first (Elop: „real“) Windows Phones that can attract people by design. For sure, diversity has its benefits and downsides. Developers don’t love it – no consistency means you must develop for the lowest common denominator or accept that your app doesn’t run everywhere without compromises. Android faces this problem and that’s one point why the Apple app ecosystem is way more attractive to users. It’s also why I think it’s a good choice from Microsoft to ensure consistency of the Windows Phone hardware, as well. But they have to loosen the rules! Budget phones need other hardware than superphones and in terms of market share Microsoft should take this into count. I know: practically specs don’t mean much for the overall experience. Look at Android: multi-core (handwarmer) CPUs and headspinning screen resolutions don’t make a good experience, in fact they can be rather harmful for the user experience. But customers aren’t really aware of this and that makes Android phones attractive. Microsoft could be the first to integrate the advantages of both the iPhone and Android phones – let’s hope they take the chance!
• Apps: For me the app problem is of equal or higher value to the hardware diversity. While the Windows Phone Marketplace lists ~60.000 apps and is steadily growing, the main target platforms for app developers remain Android and iOS. Small companies are thinking twice if they should invest into a 2%-market-share-platform or just go with 90% on 2 other platforms. It’s kind of a doom loop: customers aren’t buying Windows Phones because relevant apps are missing… developers don’t make apps because customers are missing. While 60.000 apps sounds well and the marketplace is rapidly growing, many really important apps from Android/iOS are missing. Apps that people are asking for and which make people decide for one platform or the other. App statistics don’t say anything about the quality of the apps and in my experience Windows Phone is massively falling behind the other platforms, especially iOS.

WinRT on Windows Phone? Could this be? How could it help?

The first thing I thought when I saw the BUILD keynote and the introduction of WinRT was: ok, that’s cool… the next step should be to bring this to Windows Phone. In fact, there are rumors that Microsoft plans to swap the current Windows CE kernel from Windows Phone with the NT/MinWin kernel of Windows 8 in Windows Phone 8, codename „Apollo“, which is supposed to be released in autumn 2012.

What implications would come with such a step? First, it would be important in terms of inside development of Windows at Microsoft. One codebase means less costs and while Windows 8 is made for mobile devices like tablets as well, it would definitely make sense to have the same core OS functionality on Windows Phone.

Second, wouldn’t this consequently bring WinRT to Windows Phone? In my mind, in the mid-term this could ultimately happen. As written before and stated by Microsoft several times: WinRT is an integral part of the core operating system. Now if you get the core OS to another platform, what will happen to WinRT? In my mind, it would become part of the other platform (Windows Phone) as well! Now of course, WinRT isn’t part of MinWin (the kernel, read: the core of the core OS). But with MinWin in place, closing the gap to WinRT would be much easier. Perhaps it will not bring the full WinRT that you see for Windows 8, perhaps there are additional/adopted features and controls which are better suited for phones. But it would have the main APIs and main functionality (imho ~80% could be a level).

I believe that having the Windows kernel and WinRT on Windows Phone would give the platform an extreme boost. Let’s take a side look at Android and iOS for one moment: here you have one platform for consumers and developers that spans phones and tablets. A clear advantage of those platforms! WinRT could do the same for the Windows platform: phones and tablets… but in addition: notebooks, ultrabooks, desktop PCs – you get the point! It would be an extremely high opportunity for app developers. It would break down a wall for developers of Windows 8 Metro-apps to bring these apps on the same technology stack and the same languages to Windows Phone. Imagine: with WinRT on Windows Phone it would be possible to write HTML5/JS apps as well as XAML/C# apps and native XAML/C++ apps. Any doubts in the impacts to the Windows Phone ecosystem?

Silverlight on Windows Phone

Ok, I think that’s a pretty cool imagination. But wait: aren’t there 60.000 Silverlight/XNA apps on the Windows Phone Marketplace? What about those apps? Cut off and forget?

I believe there is another possibility. I think Microsoft could manage to build up a kind of „compatibility layer“ in parallel or on top of WinRT for Windows Phone to ensure backward compatibility, at least for a while. This layer could contain Silverlight and XNA as programming models in addition to WinRT and its supported languages. I think it will be hard if not impossible for Microsoft to develop such a thing without changing API behaviors and without cutting functionality. On the other side: what’s the option? I don’t think it’s a practicable way to cut all Windows Phone apps and scare off all current Windows Phone developers and consumers.

What do you think? Hot or not? Possible or insane? Call me a fool, I’m accustomed to this 😉