And then came the iPad…
In parallel to all the improvements in .NET, someone else gained a lot of strength by disrupting the mobile and tablet market: Apple reinvented mobile computing and created an application and developer ecosystem that had a very interesting business case for many developers.And they made this by using an “old” (in my opinion quite unattractive) programming language (Objective C) and “native code”. iOS apps are primarily “fast and fluid” – one of the core attributes Microsoft now pushes heavily for its own Metro-style apps. “Fast and fluid” is one of the great and mostly unmentioned selling points for many Apple products: A nice design is one thing, but you need a very good (UI) performance to make the products “feel right”.
This is especially true regarding loading times of applications and response times for touch interactions. These aspects made and make Apple products feel somewhat different and premium.
I think, Microsoft understood this development quite early and considered options to react in a proper fashion. User Experience (UX) became even more important than ever before. Something had to happen with the Windows Operating System, its old-fashioned APIs and missing touch capabilities. On the other hand, the developer ecosystem needed to be pushed into the new world, because Microsoft knew: many of those existing applications need to get a new user interface if they should run on a touch-centric device.
Problem 1: time to market.
Problem 2: .NET loading and UI performance
The solution: Going native
All these factors led to to the resurrection of COM as base runtime technology. .NET/COM interop was a well-known - yet tricky - topic. But .NET and C# had wisely been enhanced with “dynamic” language features to somewhat reduce the interop pain.
It was too tempting for Microsoft: COM was selected to get a comeback as base technology and even as native UI technology to make a “fast and fluid” Windows UI a reality. The .NET runtime has lost this important competition. It will be used as application technology in between the WinRT OS API and the WinRT controls. Not more and not less.
What does this mean for .NET developers, who want to create Metro-style apps?
- Developers will have to learn how to write portable .NET class libraries if they want to use C# to formulate client-side business-logic, view models or validation code. In our experience this will still be 40%-60% of professional applications.
- Developers will use two different type models (.NET types vs. WinRT types) and need to convert between them – even if the WinRT APIs take away a lot of pain.
- Developers will have to get accustomed to different lifecycle models for different objects: .NET objects will be garbage collected, WinRT objects will be subject of the “reference counting pattern” – even if it will be hidden somewhere behind SmartPointers and the like – there will come a time when it is important to understand the difference. The combination of both models will get tricky in certain scenarios.
- And finally: some developers will have to return to C++ in order to extend the WinRT with components. The option to do this with sealed C# classes doesn’t look very promising.
Wrap up
So to wrap up: this is a natural development. The .NET team didn’t manage to become a core Windows technology over the past 10 years. The people responsible for the operating system still trust in “legacy” technology, and regarding the options at hand this seems to be a valid decision.But: The problems of this decision might show up in near future. The “projection” of the COM type system into .NET and Javascript worlds are some kind of magic and technologically very interesting. Yet again: they blur boundaries and differences of quite different worlds - instead of making them explicit. Windows 8 developers will have to live in this “split world” and will have to learn about at least two different technologies when they hunt down tricky bugs…
