
After spending a good amount of the past month with the Windows Runtime (or WinRT as it was also known before the drunken “Windows RT” branding bus decided to crash the party), it had occurred to me the other day there is still a big unanswered question mark over how exactly Windows Runtime will evolve.
With some practical development experience under my belt now, I believe I can say with some credibility that the Windows Runtime “framework” in its current state is sufficiently primitive – it works and has the basic APIs and controls you expect, but there’s still fundamentals (*cough* no Flyout control in XAML) and nice-to-haves missing with no expectation this will change by RTM.
Of course that’s expected when you’ve essentially reset decades of evolution which has matured frameworks like Windows Presentation Foundation and Silverlight, replacing it with one that is more modern and simplified. That’s not an issue. But what is worrying is how little we know of how quickly Windows Runtime can “catch up” to its predecessors and evolve over time.
An important aspect of this is the fact that for all intents and purposes Windows Runtime as the framework and Windows 8 as the operating system are interlocked. For example, in Visual Studio 11 when creating a Metro-style app, there’s no “Target framework” for a version of Windows Runtime. There isn’t one. You’re just writing an app for Windows 8. Case closed.
In comparison, this is no different to platforms like Apple iOS and even Microsoft’s Windows Phone which also have this framework-OS tie-in. The APIs and the operating system are tied. However there’s one exception – they can and do deliver more frequent platform update/refreshes.
As iOS has shown, Apple was able to update and release new developer framework APIs with every major iOS release on a yearly schedule. Similarly Windows Phone has done the same with NoDo and Mango updates which has drastically evolved the APIs.
If the traditional 3-year-ish refresh cycle for Windows is to be expected, that’s an awfully long time to wait for updates to Windows Runtime APIs. Not only might the framework limit developers what is possible (or practical) for a very long time, it would also slow adoption of newer technology trends that occur between the cycles (which has always been a problem for Windows).
To get around this issue, I would imagine Microsoft is considering or has considered a few options – each with its own pros and cons. They could be,
- Deliver toolkit-based package – Like the Silverlight Toolkit, which is a separate but frequently updated library of controls and helpers. This is limited to mostly frontend controls and the platform is still limited by the underlying APIs.
- Update Windows Runtime through Windows Update patches or service packs – If patches contained changes to Windows Runtime, it would allow fast and easy deployment of API changes to a large userbase, but it would introduce app compatibility issues if adoption of updates isn’t as quick or widespread as new iOS or Windows Phone releases.
- Quicker Windows refresh cycles – self explanatory with its obvious issues in enterprise deployment and adoption
If Microsoft has chosen a strategy, they’ve sure kept that to themselves and will continue to do so well after the Windows 8 general availability. After all, no consumer would or should care. But now with a developer hat on, it’s a question that beckons to be answered sooner than later. What will happen to Windows Runtime after Windows 8 is “done”?