Introduction

As a WPF developer for years I was recently concerned by the new direction chosen by Microsoft on its client platforms with the rise of the brand new WinRT framework.

I was concerned for good reasons: I’ve suffered from the collateral damages of the Silverlight failure, and as the proverb says “once bitten, twice shy”.
Since 2009 I have put a huge personal and professional investment in WPF, using it to develop LOB applications in the financial industry, and now I’m even providing training on this topic.
So as a professional developer and trainer the future of WPF is critical for me so I’ve studied this issue more thoroughly.

In this article I’ll share my findings with you, in a completely objective and transparent manner, and I hope you’ll provide your own facts, so that the community can have a better vision of the future of WPF.
In the last part of this article I provide some strategies for businesses and individual developers.

Some reasons to worry

First I’ll start by presenting the signs that are worrying me, and should worry you too if you are a WPF stakeholder.

WPF team’s blog is idle

As every Microsoft technical team the WPF development team owns a blog where the team’s members share their expertise on WPF with the community.
The last article of this blog is dated from may 2011 so more than 3 years ago, precisely when WinRT was starting to emerge as the next big thing.
An idle blog could mean a lot of things but IMHO nothing good: probably the team was reduced to the bare minimum and animating this blog is not a priority, maybe the best members of the team have been moved to other projects like WinRT, and maybe this is intentional to send a signal to the community…
In terms of public relations an active blog is essential because it shows the technology is evolving and is developed by enthusiast developers proud of their work and willing to share it with the community.
Note that often the MSDN blogs are not very active, the Entity Framework team’s blog being one of the exceptions, thanks to Rowan Miller who regularly publishes new posts, and this is one of the main reason I like this technology: it is being developed by brilliant and committed people.

The official WPF toolkit is idle

The WPF Toolkit is a free and open source project developped by the Microsoft team and designed as the anteroom of the official WPF releases.
As an example the DataGrid was not present in the initial release (WPF 3.0 and 3.5) but was available in the toolkit, and was finally added to WPF 4.0.
The official toolkit played this role till 2010, but since then the project is idle, so seems like there is no more stuff in stock for a next release.
Sign of this inactivity: for the “WPF Toolkit” search Google ranks the official WPF toolkit second after a non official one (more on this one in the second part).

No more certification

The official WPF certification (70-511) will not be continued and it will expire at summer 2015.
This is a strong explicit sign given to developers that they should not invest more time in this technology and instead devote their time to WinRT which benefits from new dedicated certification paths.
Maybe Microsoft will step back and postpone this removal like it did with other certifications after the developers community complained, but that won’t change the fact WPF is no more the priority.
Personally I’m still hesitating to pass it because I have no guarantee the time and money (yes as an entrepreneur I pay my certifications myself) are worth it.
Instead I prefer to prepare for the WinRT certifications which should be there for some years.

No Windows 8+ integration

If you remember the release of WPF 4, a large part of the enhancements were dedicated to Windows 7 integration like taskbar items customization (jump-lists, progress, overlay…).
There is no such things in WPF 4.5 to allow full integration to Windows 8+ features like the charm bar and the numerous application contracts though there is some interop capabilities.
So if Microsoft has not invested in this integration it clearly demonstrates that WPF is no more a first-class citizen in Windows and it prefers to dedicate all its workforce to WinRT, and I think this is a reasonable decision.

No support for Windows RT

Microsoft, historically a softwares vendor, is diversifying its business by becoming an hardware vendor, mimicking its competitors Apple and Samsung.
To this end Microsoft has acquired Nokia to benefit from its long time presence in the mobile phone market.
On the tablets and laptops side, to compete with iPad tablets and MacBook Pros laptops, Microsoft has launched the Surface series.
There were 2 versions of the Surface 1 and 2 depending on the hardware architecture: x86 and ARM, the later benefiting from a dedicated version of Windows: Windows RT (not to be confused with WinRT which is a software layer).
But Windows RT does not support (at least officially) the older APIs like the good old Win32, hence does not support all the “wrappers” like WinForms and … WPF, so you can’t run your WPF applications on all the Surface versions.
And if Microsoft did not invest in this it’s simply because it tries to get rid of Win32 to replace it with WinRT which is specially tailored for the new IT trends.

The new Microsoft’s strategy

In february 2014 Microsoft named a new CEO, Satya Nadella, who comes from the cloud division of Microsoft.
He is replacing Steve Ballmer, who did not understood the new mobile market (first iPhone and Android) and is probably one of the reasons Microsoft completely missed the boat and is now fighting hard to get a place taking market shares to competitors (Apple, Samsung) percent after percent.
Contrary to his predecessor Satya Nadella’s global strategy for Microsoft is “cloud first and mobile first“, so exit the traditional desktop model, and again this is a very sane strategy.
But precisely WPF was designed for the “old” model: fat desktop applications, whereas WinRT uses a totally different model, taking into account the new mobile needs.
Of course the desktop and PC market is not dead, far from it, but it is not the predominant model anymore.

The Windows Store

In order to capture a part of the applications vendors revenues most of the platforms’ owners like Apple and Microsoft have created “stores” you must use to publish and buy applications.
And unfortunately AFAIK the Windows Store applications must be based on WinRT, so your WPF applications can’t be deployed through the store.
Note that this is not an issue for businesses that deploy their applications internally and don’t need a store, nor for big applications vendors like ERP who use their own commercial channels to sell their applications, but this is an issue if you are a small vendor who need the visibility of the store, before a competitor eats your market shares.
More and more people are using the stores instinctively to search for new applications so there is almost no way around them.
So if you intend to develop your brand new application in WPF you will have a hard time distributing it and even harder if you intend to sell it, so you should instead use WinRT.

Mobility

You probably consume a big part of your daily content through your mobile phone using web or native applications so you understand how important it is nowadays to be present on this market: you must provide a mobile version of your applications.
WPF has never been a platform for mobile development and is not a player in this market, and for years the answer was Silverlight for Windows Phone and it was the reference toolkit up to Windows Phone 7.
But using one toolkit per platform was not ideal, even though you could share most of the procedural and markup code.
WinRT is an answer to this issue because it is a common toolkit designed to ease development on all the Windows platforms which are more and more unified at the OS level with Windows 8+.

Costs of maintenance

If you’ve worked with Microsoft technologies for years you know that Microsoft spends its money sparingly, and for good reasons: first, as a company, it must make money to survive and nowadays shareholders ask more, so a penny is a penny, second implementing even a small feature is costly because there is a lot of steps involved; Eric Lippert gives an overview in this blog post: How many Microsoft employees does it take to change a lightbulb?.
So when the community asks for a bug fix or a new feature, it is implemented only if it’s really a big one:
- either critical like security breaches, so even a few numbers of impacted users will trigger the implementation
- or minor but annoying a lot of people
Developing both WPF and WinRT would imply answering to both toolkits’ feature requests and fixing both toolkits’ bugs, this is clearly not an option, especially as Microsoft is currently reducing its workforce.

Portability

What could have “saved” WPF would be some niches, e.g. as a portable technology to develop client applications, but unfortunately this is not the case.
There is a portable version of .Net (to be pedantic, of the CLI): Mono, which runs on Windows of course but also on Linux, Unix and Mac.
And Mono is not a toy technology, it really works, with it I’ve myself already built a Jenkins integration server on Ubuntu Server.
Mono supports most of the .Net framework stack but one of the few missing parts is WPF; if I remember well there was a project named “Olive” to implement it but it was never really started due to the huge work it represents, especially at the low level rendering layers.
The only UI technology Mono has implemented is WinForms, so ironically WinForms could survive WPF thanks to its portability.

The Silverlight syndrome

I once was a Silverlight developer and I’ve discovered that technologies can vanish quicker than I once expected.
Back in 2008/2009: RIA is a buzz word, Microsoft is branding its own framework, Silverlight, in businesses managers see it in Microsoft events and want it in their IT ecosystem.
So in 2010 and first quarter of 2011 we started developing Silverlight applications.
But somewhere in 2011 at one of the technical events, concerning the web, Microsoft stopped putting Silverlight in the spotlight, and instead started promoting the HTML5 ecosystem (with CSS and JS).
Officially the story had not changed for Silverlight, but I was quite suspicious, reported it, and our team decided to stop Silverlight developments, which by the way had not delivered the expected benefits (e.g. Silverlight was not plug-and-play because you needed to be administrator to install the Silverlight player :/), to instead concentrate on “traditional” WPF.
Hopefully most (maybe 85%) of the XAML and C# code was shared with WPF, so not too much was really lost, and we stopped while we were not too much committed.
And this was the right choice because in 2013 the death of Silverlight was officially announced, and more than one IT stakeholder were surprised because they had not seen the forewarning signs.
I don’t think things will be that violent for WPF, but when you’ve lived such a disappointment you stop being naive and tend to become distrustful, which in my opinion is a quality in the current IT context.

Some reasons not to panic

After reading the first part you may be starting to freak out but as often things are not completely black, they are gray, a more or less dark gray.
This second part will help you mix the white with the black, so keep reading…

Still an active team

According to Greg Levenhagen (Is WPF Dead? – NO!) there is still an active development team dedicated to WPF.
Greg does not provide any hard numbers so it’s hard to measure the development effort.
While it’s obvious Microsoft wouldn’t abandon a technology used by millions of people, having dedicated developers, not merged in other teams, is a good thing.
And still according to Greg this team is not only dedicated to maintenance of existing versions but is also preparing at least a next release (WPF 5?).
Without having the change-log of this version it’s hard to be too optimistic: probably this will be only a bug-fixes and performance enhancement version without any major features.

Still a development effort [Update 2014-11]

In november 2014 the WPF team published an article, The Roadmap for WPF, showing that WPF was still actively developed.
The team is mainly working on important issues like performances, which have been continuously enhanced since the inception of WPF, and tooling fully integrated into Visual Studio.
Maybe the more important enhancement is the full support of touch and high-density display.
Why is it so significant ? Because these are features of devices like tablets and phones, and WPF was dropped in favor of WinRT precisely because the later has been specifically designed for such devices.
This may not be a complete u-turn from Microsoft in favor of WPF but it shows that Microsoft has heard and taken into account the claims of the community.

New tools versions

I’ve noticed a positive sign on the official tooling side of things: Prism, a set of tools and best practices for developing XAML applications, has been updated to version 5 and along with the WinRT version it does provide a new version for WPF.

As said in the first part, the official WPF toolkit is idle but another project picked up the torch: the Extended WPF Toolkit.
It is being developed by a well known extensions’ vendor, Xceed, so by WPF experts (and other Windows technologies by the way), and it is very rich with a bunch of additional controls, and most importantly the project is actively developed, latest version being from june 2014, so less than 3 months ago as of this writing.

Finally the two top MVVM frameworks, MVVM Light Toolkit and Caliburn.Micro, are active, new versions are 3 months old.

So the WPF tools ecosystem is still living and evolving which is especially reassuring for businesses because they are not left with a bunch of unmaintained projects.

Change in management

At the end of 2012 Steven Sinofsky, at this time President of the Windows Division, left Microsoft.
Why would it be a positive sign for WPF? Because Steven Sinofsky was famed for being a .Net hater and not playing well with the other teams (maybe the primary reason of his departure).
And this would partially explain, along with some real technical reasons, why .Net was not used as the foundation block of the next Windows versions whereas it is one of the best piece of software ever made by Microsoft.
From the outside it’s hard to evaluate the part of gossip and the real feelings of Steven Sinofsky and their impact on the design decisions for Windows 8+.

The OS market inertia

Another good point for WPF is the fact businesses and individuals don’t migrate immediately to each brand new OS version, and for a lot of good reasons: it costs money, it takes some time, it’s risky, and often it’s simply useless.
Migrating to a new OS is a really daunting task due to the need of ensuring compatibility of the applications: those provided by an external vendor like Microsoft with Office and those developed by the internal teams, and from my experience it’s a process that can easily take 2 years.
Currently (mid-2014) the market shares of WinRT on the PC market are quite reduced:
- Windows 8 + 8.1 : ~15%
- Windows 7 : ~55%
- Windows Vista : ~5%
- Windows XP : ~25%
So for more than 80% of PCs you can’t use WinRT and have no other choice than WPF.
And in some context this is worst for Windows 8+: in the companies I know in the financial sector in France this is simply 0%, the migration to Windows 7 is not even completed everywhere, and I know some still running with Windows XP because setup of applications is not trivial.
Considering the renewal cycle is about 5 years WPF should be the unique choice for a lot of businesses till the end of the decades.

The ALM inertia

As you probably know retiring applications is costly: first you have preliminary studies with a bunch of meetings to assess the impact it will have on the business, and you have to work hard to convince some users who will sometimes put the “operational risk” joker on the table; then you have to replace them with brand new application and you must ensure there is no regression, often running both the old and new versions side by side during a certain period of time before completely switching; moreover you may have to call up your DB teams to migrate the data, the network teams to adapt the firewall rules…
It’s why businesses migrate applications only when there is a valid business reason, and a brand new technical layer is not one, so the existing WPF applications, and there is a bunch, are here to stay, and it means WPF skills will be needed in the foreseeable future, just have a look at the number of WinForms applications still in the wild, and new ones are being developed every day, whereas WPF is available to replace it since 2006.
And from a technical point of view, while WPF and WinRT are really similar, they are not fully compatible: there are still missing features in WinRT 8.1 and some quirks: to map a namespace to XAML you use clr-namespace in WPF and using in WinRT, this is enough to break XAML compatibility and discourage any flimsy will to jump!

WPF is mature

The obvious important decrease of the development effort for WPF can be worrying but IMHO it is only following a natural path every developer has experimented: a huge effort to develop the first release, then still a sustained effort for the following release that benefits from the feedback of the community, and finally a minimal effort to maintain the application.
This is exactly the path followed by WPF with a first versions (WPF 3.0 (for me was more of a beta version) and 3.5) bringing a new way of developing Windows applications, then WPF 4 introduced some new controls moved from the toolkit, like the DataGrid, and performance enhancements, and finally WPF 4.5 introduced the Ribbon and still some performance enhancements.
So the more mature a technology is the less development effort it needs, and after 8 years WPF is a really mature technology, so the needs for new features and bug fixes are reduced.
And probably WPF has now entered the maintenance phase of its life-cycle so don’t expect frenetic development of it.

The LOB niche

If there is a domain where WPF can survive and even continue to shine this is LOB (Line Of Business) applications.
First because most of the expertise to develop them is based on .Net which is a mature platform that a lot of companies running Windows use to develop their LOB applications and won’t throw away but instead leverage as much as they can.
And some central .Net tools are not yet available for WinRT, e.g. ORMs like NHibernate or Entity Framework, which are necessary to most LOB applications to access their relational data.
Second for some big LOB applications like trading platforms there is no benefit to use WinRT because you don’t need and even don’t want, for security reasons, mobility.
And this kind of big applications even go against the official guidelines of Microsoft for designing WinRT applications: they should be focused with a minimal set of data on the screen.

The learning curve

If you are a seasoned WPF developer without knowing it you are probably already a WinRT developers at say 80%, and if you are a business you already have 80% of the expertise to develop WinRT applications in stock.
The reason is that most of the fundamentals tools for developing WPF applications are the same for WinRT:
- same procedural languages: C#, VB.Net…
- same markup language: XAML,
- same way to link view to data: data binding, DataTemplates…
- similar architecture of applications: global structuring, resources…
- same design patterns and implementations: MVVM, INotifyPropertyChanged, INotifyCollectionChanged, ICommand…
So most of your investment in other XAML platforms like WPF and Silverlight can be leveraged for WinRT, reducing the steepness of the learning curve (remember the one of WPF when you were a newbie? )

WPF is rich

WinRT is not a clone of WPF and some features are not yet implemented, so if you are only developing desktop applications from a technical capabilities point of view WPF is still better.
But I put it as the last one because IMHO it is not really significant, and as WinRT will continue its evolution the gap will become smaller and smaller, but I guess some developers with really specific needs won’t be able to develop with WinRT and will need WPF.
But again the added value of WinRT is not in its intrinsic technical richness but more in the development model it offers with access to mobile platforms and the Windows store.

Strategy for the future

Whether you are a business or an individual developer you should seriously consider slowing down your technical investment in WPF, and start to build your expertise on WinRT.

Businesses

As a business you can’t stop your WPF developments as long as you have some older versions of Windows, including Windows 7.
As for your existing applications, don’t worry, you don’t need to migrate them to WinRT, unless you want to benefit from its new capabilities as deployment through the Windows store.
Indeed Microsoft should ensure support for WPF for the foreseeable future; backward compatibility is something Microsoft takes really seriously.
As an example while it may be harder to setup VB6 environments in new versions of Windows it is still possible and, hence setup, your applications should continue to work seamlessly.

Depending on your available IT workforce, you should devote time to technology intelligence and have some developers starting to think seriously about WinRT: how you could benefit from it, typically to broaden your audience, how new applications should be developed, how the existing tools and code can be reused, what are the potential issues to anticipate…
For the applications that could benefit from WinRT for mobile and tablet you can start building some migration path, which is not that obvious because WinRT is missing many features from WPF.
Start to develop proof-of-concept applications to validate the new technology in your particular context and see for yourself if it delivers.

Developers

As developers we don’t want to have technical skills nobody needs, and instead we generally must build a large enough portfolio of skills to accommodate the more businesses and projects we can to reduce the risk of being left behind.
So if you are an experienced WPF developer and you have to choose between extending your WPF skills to become an expert or starting to gain new skills for WinRT development then IMHO you should choose the second option.
Of course you’ll probably be able to do both like me, but WinRT should be somewhere on your TODO list but not your priority either.

Or you could continue in WPF waiting for the market to lack WPF developers, like is the case for older technologies like COBOL and VB6, but I fear you’ll have to wait a decade before it happens, because, with the important development of IT in businesses, for any technology there is a lot of developers on the market, particularly for mainstream technologies like WPF, so I wouldn’t count on it.

Don’t be demoralized or upset by this nth brand new technology, this is the business model of our industry: it needs to create new things all the time (remember SOA that poured a ton of money from businesses to the pockets of IT companies, their employees, their shareholders and contractors) to sell them to customers just as Apple does with its iPhone 1, 2, 3, … and now 6 and soon 42, this is how it works and fortunately we, as developers, are on the good side of the barrier, we can make a living from this entropy, and objectively all these new technologies enhance the life of businesses and individuals.

Conclusion

I think that the sum of all these facts is pretty clear: WPF is past and present, in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF will become kind of deprecated like VB6 or WinForms.

Above all don’t be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind.
Do not expect a revival of WPF, there is no such thing in IT (well OK COM is kind of back in WinRT ), WPF is objectively not tailored for the new trends, the brand new stuff is.

Of course the picture is not all black: WPF is not dead and obsolete nor dying and obsolescent, it has just reached its peak and will slowly fade as the businesses migrate their infrastructure to Windows 8+ allowing them to choose WinRT for their future developments.

Be pragmatic and transparent: use WPF while it brings value to your clients and warn them about these facts, and help them prepare for the future.
I’ve myself updated my training material by interleaving WinRT chunks in my WPF training, and adding a slide with a summary of these facts, highlighting them depending on their significance.

But IMHO you should not invest too much in WinRT either. Why? Because the more I play with WinRT and think about it the more I see it less and less useful:

• if you develop a LOB application, your only target is probably Windows PC, and you need to be compatible with pre Windows 8 systems, at least Windows 7, so WinRT is clearly not an option, and you must use WPF,
• if you want to target tablets and phones you can't forget about 90% of the market, iOS and Android, so WinRT is not an option, and you must use either the web stack (JavaScript/HTML/CSS) or native cross-platform frameworks like Xamarin (C#) or QT (C++).

So for most use-cases WinRT is not an option. Moreover you should note that Microsoft is heavily investing in the later technologies. It's probably too early to ask yourself "Is WinRT (as a final developer platform) dead ?" but I would be quite surprised if WinRT manages to get some traction and becomes a major development platform.
IMHO WinRT is only a good platform for the Microsoft teams because it allows them to share code between the different flavors of the Windows OS, mimicking the effort of Apple; but for the final developer the use-cases for WinRT are way too limited: sharing some code between PC, tablets and phones but only for Windows devices. Probably some businesses may need only that but I doubt there is many because nowadays applications are often accessed from personal employees' devices (BYOD) which can be anything and probably some iOS or Android.