I just got back home from 360iDev in Denver, one of the best third party conferences on iOS development.
In parallel, another big conference has been going on in Anaheim, introducing big and significant changes to a completely different platform. I’m talking of course about //build/. As you probably heard, if you’re not living under a rock, Microsoft announced both Windows 8 and – more interesting to us as developers – Visual Studio 11, and has made preview releases of both products available, as well.
The good (and unexpected) news is that all the doomsaying about .NET has proven to be false; if anything, Windows 8 strengthens .NET as one of three ways to build high quality apps for its new Metro application platform. It does so by essentially making .NET, C++ and HTML5+JavaScript equivalent tools that can use the same APIs to create apps. Given the choice of those three, what would you choose? Clearly, .NET is the winner here.
XAML, integral part of both WPF and Silverlight in the past, has been promoted to the default UI paradigm for “modern apps”; it is interesting to see that (a) Microsoft is dropping the WPF nomenclature and talking about XAML itself and (b) making XAML UI also accessible to non-managed development using C++. The new UI layer that lets you build Metro apps is backed by WinRT, a managed class library (and subset of the full .NET framework), and together Metro and WinRT are presented as the way forward for building what Microsoft, literally, called “modern apps”. Classic Win32/Win64-based applications are still supported, but relegated to the “old” Windows desktop. It also seems (although Microsoft has not been completely precise in talking about this, so there is still some discussion and interpretation going on) that the Win32 model will not be supported at all on ARM based Windows 8 slates (i.e. not only will x86/x64-built applications not run on ARM devices, which seems obvious; no, there will most likely also not be the option to recompile classic Win32 apps for ARM. To run on ARM systems (and Microsoft is making it clear that they expect all/most tablets shipping with Windows 8 to be ARM based), the new Metro/WinRT APIs will need to be used.
It sounds like this seems to spell the end of traditional “native” Win32 development tools, at least for “modern” Windows applications.
Metro itself looks like an impressive and ambitions “reimagination” of Windows, indeed. Of course only time will tell how successful it will be and how well it will run (in my first attempts running the Windows 8 Developer Preview in VMware Fusion, it certainly feels awkward and clunky in places, and unnavigatable without touch in others), but IMHO one must applaud Microsoft for taking such a bold step.
For developers, creating apps for Metro will be a paradigm shift, much akin to targeting a completely different platform. In fact, watching the excellent Eight Traits of Great Metro Apps presentation, a lot of the purposeful “limitations” of the development remind me of iOS: the way application backgrounding is handled (your app will be killed as it gets off screen) or how Windows Push Notifications will need to be used to give the appearance of non-running applications staying live, updating their tile and providing notifications.
This goes to show, I think, how important it is to develop applications with platform-appropriate tools, not one-size-fits-all solutions. I’ve made the argument before that anyone trying to use Win32-rooted tools to create applications, say, for Mac or iOS is doomed to fail and produce sub-par results. The same, I believe, will now apply to using Win32-based tools to create Windows 8 apps: Your applications will look out of place, and/or be relegated to the legacy desktop.
In the same vain, it is great and refreshing to see Microsoft talk about and stress how important good design, a quality user experience and conformance to the Metro design paradigm is (same video). They really copied the right pages from the Apple playbook here.
So What about Our Tools?
Windows and .NET are a very important platform for us here at RemObjects, and that continues to be the case going forward. The teams here are already hard at work at providing support for VS11, WinRT and Metro, based on previous access we had to internal betas as well as of course the Developer Preview that is now available via MSDN to everyone.
Data Abstract (and RemObjects SDK) will be integrated into Visual Studio 11 soon, and will let you build Metro clients (something which is especially important since the client data access story on Metro/WinRT seems to be pretty thin, otherwise). We’re not forgetting Hydra, either.
And Oxygene will, of course, let you create Metro/WinRT applications, allowing you to build native applications with lots of shared Object Pascal code for Windows Phone 7, Android and Metro – next to, of course, regular Windows and cross-platform apps with .NET, Mono and Java.
I don’t want to promise exact timelines, but we’ll let you know more and will have beta bits for customers to play with, Real Soon™.
Exciting Times Ahead
As most of you know, I’m mostly a “Mac and iOS guy” and have not been a big fan of the Microsoft platform for a while. But what I’m seeing here looks impressive, and while I’m not contemplating to switch
marc
