Windows 7 had one application scenario – desktop apps. Windows 8 has two application scenarios – desktop and Metro. Metro is the start menu, but also a shell in which app containers execute.
Note: Metro developers can build native apps in JavaScript, C#, VB, and C++. They can leverage HTML, XAML, and Direct3D, respectively. They uniformly access system devices and services through the Windows Runtime (WinRT).
So, here we go:
Metro applications are different. Metro development is different. Desktop development is still present, of course. Desktop development is still powerful, of course. However, here are my (personal) top 10 reasons why Windows Metro development smokes Windows Desktop development:
Reason 1 – Hardware Acceleration
Metro applications benefit from hardware acceleration out-of-the-box. Build your application and you get the GPU, free of charge. Moreover, metro developers get a library of animations that are not only tuned and accelerated, but also provide consistent effects across the platform.
Reason 2 – Connected Standby
Connected Standby is Windows 8’s version of Windows 7’s Sleep. Like Sleep, Connected Standby delivers a battery life experience similar to off with a split-second resume time. Unlike Sleep, Connected Standby allows Metro apps to keep their data up-to-date while in standby. More.
Reason 3 – Roaming Settings
Metro applications can store files and settings locally. However, Metro applications can also roam them to the cloud and, therefore, across Windows 8 devices. This is enabled seamlessly. Developers can develop immersive apps without having to deal with some cloud service out there.
Reason 4 – Play To Contract
Windows 8 enables comprehensive support for DLNA devices. Metro developers can take advantage of this support through Play To, a contract allowing their applications to extend its media, like sound and video, to devices on the user’s network. More.
Reason 5 – Search Contract
Like Windows 7, Windows 8 users can search applications, settings, and files. However, Windows 8 also allows users can also search data inside Metro applications with the Search Contract. Without first launching an app, users can search directly from Windows 8. More.
Reason 6 – Settings Charm
There’s one less wheel to reinvent in Windows 8, settings. Metro guidelines clearly specify application are to be invoked by the user from the Settings Charm – no more Edit>Preferences or Tools>Options in various applications. Developers have a common entrance and common interfaces.
MSDN: The Settings charm provides a single access point to all settings that are relevant in the user's current context. The Settings charm is always available. Settings include system settings that always apply, app-related settings that are brokered by the app with permissions, and settings that are specific to the current app. This topic explains how to use the Settings contract to add app settings to the Settings charm.
Reason 7 – Share Contract
Metro applications can communicate with applications that haven’t even been written yet. Thanks to the Share Contract, metro developers can build applications that share data with any application that supports the payload schema. This includes applications that haven’t even been written yet.
The Share Contract is core to delivering on the Metro principle “Win as One” which simply guides the user to leverage all of Windows 8 and the entire ecosystem. With a few lines of code, metro developers can extend their apps with broad support for social networks and other apps.
Reason 8 – Windows Store
Windows 8 may be the biggest opportunity for developers, ever. With reach into over 200 countries and regions and in more than 100 languages, the Windows store will deliver Metro applications with unprecedented global reach. The Store alone may be enough to champion metro development.
The revenue sharing model of the Store is just more sugar. Applications using Microsoft to fulfill their commerce for app and in-app purchases, retain 80% revenue after reaching $25k. However, Microsoft allows you to handle commerce on your terms – even if it means we don’t get a penny. That’s right.
Reason 9 – ARM devices
Choosing an architecture isn’t a choice for metro developers. Just build your app and publish. We handle the rest. Windows 8 runs on Intel chipsets and ARM chipsets. If you want to extend your reach and support both, just write your Metro app and stop worrying about it. It’s that graceful.
Building Windows: Developers wishing to target WOA (ARM) do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps.
Reason 10 – WinRT
Metro applications access system devices and services through WinRT (Windows Runtime). Not only does this deliver identical functionality to JavaScript, C#, and C++, but it also protects the system through brokered API access. As a result, language choice is no-compromise, and users can trust apps they install. The bet part? WinRT projects system resources in local data types, so developers don’t have to mess around with converting pointers and enumerable like with pinvoke.
Reason 11 (Freebee!) – The Future
It would be a grave error to assume we are deprecating the desktop. Windows 8 is an upgrade to Windows 7 and the desktop is fundamental to many services, many apps, and many capabilities of the operating system. Metro simply introduces a new, touch-oriented interface for apps.
Metro also introduces the many features I have listed above. And, if you are the type who reads writing on the wall, if you are the type who reads between the lines, if you are the type who hears what isn’t said – surely you can see that Metro apps are important to Microsoft.
Windows 8 is coming, like it or not. Metro apps are coming, too. Embracing them will not only give you the advantage of leveraging WinRT and the marketplace, but it will also let you get in on the ground floor of what is a “big deal”. Don’t let this pass you by.
Conclusion
In all reality desktop development is awesome. Metro development is nascent. Some features have a ways to go to be in parity with their desktop cousins. However, Metro development brings with it a list of benefits that makes metro compelling. Get on board early on.
Best of luck!