Thinking (Again) About UWP and the Microsoft Store (Premium)

So, we need to discuss this week’s news about the end of ad-based UWP app monetization through the Microsoft Store. And you may be surprised by my take on this event given my previous editorials about these two topics.

First, a bit of background.

As you must know, Microsoft has been scaling back its original strategies for both UWP (Universal Windows Platform) and the Microsoft Store for years, though the cataclysmic news of last year triggered the first serious handwringing. And that news was a one-two punch: Internally, Microsoft’s decision-makers decided that its UWP mobile app strategy was “dead” (their word), paving the way for technology that was previously locked into UWP to be used with other developer frameworks. And the firm is working to remove the Microsoft Store as a requirement for distributing so-called Store apps (which include UWP apps, but also a wide range of other app types).

Both of those decisions are about-faces when compared to the previous strategies. But both also mark long-overdue admissions from Microsoft that its original strategies were not working.

To be fair to Microsoft, nothing it’s tried in the client developer space has worked for about 20 years now. And that’s interesting, because if you divide the history of Windows into two eras, as I have in my Programming Windows series of articles, you’ll see that the first period, which we might think of as classical Windows, was one of epic growth and change. And that the second period, the .NET period, was one of defeat, developer indifference, and the rise of platforms like mobile and the web that Microsoft does not control.

It’s not all bad, of course. The other way you could view these two eras is by sophistication, and while the .NET era has not been as successful for Microsoft as was classical Windows, it is still more sophisticated and thus “better” for developers. It’s just that the world has moved on, and nothing Microsoft has tried to reverse those trends has worked.

And not just recently. Yes, UWP and the Microsoft Store are failures. But so, too, were the .NET Framework, VB.NET, and Windows Forms, in 2002. The Windows Presentation Foundation (WPF) in 2006. And then each generation of what eventually became UWP, starting with Metro in 2012. And lots of other things in-between that, frankly, I’ve simply forgotten about for the most part, or are trying to, like Silverlight and Windows Phone (2010). Whatever. It’s all failed.

Looking at the original vision for UWP and the Microsoft Store (both of which had different names at their inception, interestingly), you can easily Monday Morning Quarterback the “why” of those failures: UWP is a mobile platform shoehorned into a desktop OS and is not as sophisticated as the frameworks that preceded it. And the Microsoft Store was originally designed to only house this weird type of app and, worse, to be the only place from which developers could distribute such apps and from which users could find, download, and install such apps. It seems patently obvious that this would never work.

Before completely reversing course, Microsoft did everything it could to make these initiatives succeed. It opened up UWP and the Store to developers with existing code bases via so-called bridges. When that failed, it expanded the definition of a Store app to include many types of non-UWP apps, including even desktop applications. It even toyed around with the idea of letting Windows just run Android apps natively, a process that worked so well the project was scrapped out of fears that it would destroy any incentive for developers to use UWP.

When all that failed, Microsoft finally bowed to the inevitable. It open-sourced .NET and made it a more equitable underlying platform and runtime across multiple OSes. It open-sourced its previously retired Windows Forms and WPF frameworks and began supporting them again, and porting UWP features to them and to the low-level Win32 API. It completely detached the UI layer from UWP so that it would work identically across different frameworks. It relented on its Microsoft Store requirements for distributing and updating UWP and other Store apps. And it finally admitted, if only quietly, that UWP was a non-starter. It was—again, their word—“dead.”

Going forward, Microsoft will do what one might argue it should have done all along and simply meet developers where they are, much like it is doing so with its offerings for end users. Where the firm could assume in the past that most of its customers were using Windows PCs and thus it could force-feed frameworks aimed at Windows applications to developers, it is now far more agnostic and open in both cases. Everybody is welcome.

And while it’s easy for enthusiasts like us to be consumed by fear and dread, the reality is far more uplifting: This is a great time to be alive, and that’s true whether you’re a Microsoft customer or a developer targeting Microsoft’s platforms. It took a long time to get here, but as is the case so often, defeats have a way of opening eyes and opening doors to paths that would otherwise have never been taken. Yes, I wish things had gone differently. But it’s hard to argue with the outcome.

So. This latest news.

Many see this event, in which Microsoft quietly announced that it is shutting down its Microsoft Ad Monetization platform for Windows UWP apps, as an indication that UWP really is dead. Even some people who criticized my declaration about that last year—again, based on what key decision-makers at Microsoft did and communicated to the press—may suddenly be correct after all. Huh.

It is bad news, I guess. Microsoft says that its UWP ad platform is “no longer viable,” and while it describes what’s happening as a “transition,” there’s no solution at the end to transition to. We’re transitioning from a world in which UWP developers could monetize their apps with ads to one in which they cannot. They are now on their own and must figure out how to “transition to another ad platform” all by themselves. That is pretty shitty, for sure, and it’s curious that Microsoft isn’t partnering with at least one third-party ad network to help developers make that transition.

But I think this change says as much about Microsoft Store as it does about UWP. Which is nothing we didn’t already know: Both are failures and Microsoft is taking steps to move past those failures. In other words, nothing has really changed. This is just the latest step that Microsoft has taken since Build 2019 to course-correct on its failed strategies.

Another thing Microsoft could do better, of course, is clearly communicate what’s really happening. It continues to be coyly secretive about UWP, in particular. But the news really isn’t all that bad: If you are a UWP developer, the platform you chose will continue to be supported with new features going forward, just as will other frameworks. What else could you ask for?

More broadly, many are wondering what’s next. Is there some future Windows application framework coming?

Increasingly, I don’t see the point. Microsoft currently supports so many different ways to create apps that can run on Windows, from native apps to web apps, that developers interested in supporting the one billion souls on Windows 10 alone should have enough choice to last a lifetime. And, ultimately, the core benefit of Windows to its users continues: It can run your apps. All of your apps. Which can be made with a wonderfully diverse range of technologies, none of which the average user ever needs to worry about. UWP apps like OneNote can and do coexist with web apps like Outlook.com and Teams and native Win32 apps like Notepad and Microsoft Word. And it all works just fine.

I’m sorry that Microsoft is leaving UWP developers hanging with this latest “transition,” and that it can’t communicate what it’s doing effectively. But I’m also hopeful for the future of Windows application development now that Microsoft has finally given up on its brain-dead strategies of the past. It happened about six years too late, but it did finally happen.