Windows 8 Store Applications Vs. WPF Applications

Today’s Windows Developer faces a crucial decision: whether to build for the new (shiny!) Windows 8 Store or to build for the Desktop.  There are significant advantages to each, and they are, more or less, mutually exclusive.

Let’s start with some definitions:

Windows 8 Store Applications are distributed through (surprise!) the Windows 8 Store; Start Screenthey have the pretty tiles that appear in your start screen, and they only run on Windows 8

W8 Store applications can communicate with one another through charms (sharing, searching, etc.) and can, if you are good and if you are lucky, make you serious money through the Windows Store. 

Windows Desktop applications, on the other hand,  run on the desktop in Windows 8 (and note that this means they run only on Intel boxes, not ARM, which means they don’t run, for example, on the Surface, but only on the Surface Pro.) 

They are backward compatible with Windows 7, and while they can look a lot like Windows 8 Store applications (through the use of custom controls and careful programming) they are quite different.  For example, they do not have charms and they do not have the same life-cycle as Windows 8 Store applications.  They are, in short, Windows 7 applications running, if you want, on Windows 8.

Windows 8 Store applications are created in Visual Studio 2012 using the Windows 8 Store Application Templates.  Windows Desktop applications are developed in any number of ways, the most common of which may be WPF. 

Comparing the Platforms

If you want to put an application in the store, there is no choice: you must go with the Windows 8 Store application.  This path lets you charge for your application, create trial-ware, create in-app advertising, etc.

If you want to build an enterprise application, however, the answer is considerably less obvious. 

On the one hand, WPF offers a great variety of controls, runs on Windows 7 and there are dozens of third party controls (e.g., from Telerik) that can greatly simplify and enhance your application. 

On the other hand, Windows 8 applications are very slick, are touch-centric and have generated a great deal of interest; especially for those running Windows 8 on slates, tablets, etc.  And while there are fewer third party controls, more are coming every day.

One of the bigger stumbling blocks in using Windows 8 Store applications for the Enterprise is that Microsoft has promised but not yet delivered, a coherent and simple answer for how to deploy these applications.  Clearly deployment through the Windows Store is not an adequate answer for Enterprise apps.  Side-loading (loading directly from a disk or by downloading) may be a good answer, as may Enterprise-specific stores (stores that sit on a given company’s server).  We don’t yet know what the final strategy will be.

On the other hand, WPF offers click-once deployment, making the entire issue of installing the application simple and straight forward.

WPF programmers are also given a great deal more power than Windows 8 Store Application programmers. This is a mixed blessing, but when you need it, not having the restrictions present in W8 Store programming can be liberating. 

For example, in WPF you have full access to the Operating System.  That means you can write a file anywhere, at any time.  Not so with W8 Store apps, where your access is restricted to safe locations.  The restriction makes sense: you don’t want an application from the store piddling all over your file system, but Enterprise applications are, by their definition, highly trusted, and sometimes you do want to write to c:\temp – which is not possible with W8 Store apps.

WPF programmers also enjoy a robust development platform that is fully mature.  Win 8 App development is still in its first cycle, and is missing some key features such as Data Triggers and solid data validation with fallback values. 

Transitioning from WPF to Win 8

Many programmers are either experimenting with Win 8 Store apps, or are making the transition.  For WPF programmers, it is a relatively painless transition, because the underlying XAML and architectural approach are very much the same.  That said, there is much to learn. 

Among the topics that WPF application developers need to learn about when making this transition are:

  • Managing application life cycle (e.g., restoring state to restarted apps)
  • Charms and Contracts  (searching, sharing, etc.)
  • Live Tiles and Notifications (Windows 8 provides new ways to send information to the user,  about apps even when they are not running)
  • Interacting with sensors (e.g., Gyroscope, etc.)
  • Asynchronous Programming (which is pervasive in Win 8 App Store programming)
  • Notifications (live tiles and toast, as mentioned above)

The need to learn this new material may very much make the decision for many developers. There will be those who are proficient in WPF who really don’t want to tackle a new platform, and there will be those who can’t wait to dig into the new material. 

It is early days for Windows 8, and if what we’re hearing about Blue is accurate, it is an evolving platform.  You can expect that Enterprise developers will be keeping an eye on the platform, with some early adopters jumping now, some holding back until it matures, and some cling to WPF long after Windows 8 apps have dominated both the consumer and the Enterprise market.

About Jesse Liberty

Jesse Liberty has three decades of experience writing and delivering software projects and is the author of 2 dozen books and a couple dozen Pluralsight & LinkedIn Learning courses. He was a Senior Technical Evangelist for Microsoft, a Distinguished Software Engineer for AT&T, a VP for Information Services for Citibank and a Software Architect for PBS. He is a Xamarin Certified Mobile Developer and a Xamarin MVP and a Microsoft MVP.
This entry was posted in Windows 8, WPF, XAML. Bookmark the permalink.