Microsoft has further clarified its plans for the Universal Windows Platform, a desktop application framework which at the launch of Windows 10 was said to be the future but now looks headed for oblivion.
Principal program manager lead Thomas Fennel has posted on GitHub about the choices facing developers invested in UWP applications.
He explained that the new Windows App SDK – formerly known as Project Reunion – is "using the existing desktop project types as the foundation of the Windows App SDK, due to the vast amount of existing desktop APIs and compatibility that desktop project types provide."
In addition, new capabilities including Fluent Design – Microsoft's design system used for Windows and cross-platform applications – are part of the Windows App SDK, to enable an up-to-date appearance.
What about those who bought into the hype and developed UWP applications? The good news is UWP will continue to get "bug, reliability and security fixes." If you are happy with the functionality, leave it alone, said Fennel. The WebView2 browser control is also coming to WinUI 2, used by UWP apps. The bad news is... everything else.
".NET 5/6 is not coming to UWP project types," said Fennel. If you need this, "we recommend you migrate your project to a WinUI 3 desktop project," he added. WinUI 3 is the UI framework of the Windows App SDK, and unlike WinUI 2 cannot be used by UWP applications.
Fennel said that migration should not be too hard, though there is no automated porting. For a user interface defined in XAML, "in general, you simply change your namespaces from Windows.UI* to Microsoft.UI*." However, developers will know that there are often issues that appear with this kind of migration.
One remarked in response: "I simply don't understand how you can tell us 'if you're happy with your current functionality in UWP' – we're pretty much 8 years behind any decent advance there has been made." The dev complained about bugs as well as difficulties interoperating with the file system.
Across the Windows universe
UWP was an evolution of WinRT, the API for the Windows Runtime introduced with Windows 8, and was originally designed to be a sandboxed system to make Windows more secure. UWP applications were also intended to be deployed via the Windows Store.
The Windows Store has now been updated so "developers can publish any kind of app, regardless of app framework and packaging technology."
"Once again you abandon a framework. How disappointing!" said another developer.
What went wrong? Business as usual for Microsoft perhaps, but the origins of the UWP debacle go back to 2004 or thereabouts and the decision to remove the dependency of Windows Longhorn (the codename for Windows Vista) on .NET. Early previews of Longhorn used .NET "Avalon" (Windows Presentation Foundation or WPF) at the heart of the Windows UI but performance issues forced an infamous reset and a return to the Server 2003 codebase.
The relevance of this is that the Windows team at Microsoft became convinced that .NET should not be too tightly coupled to Windows, which is why when a new application model was sought for Windows 8, a new thing called Windows Runtime was invented, instead of building on what had been done for Windows Phone, which used the .NET-based Silverlight.
- Microsoft .NET updates include C and C++ code in Blazor WebAssembly, release date for Visual Studio 2022
- Are you a 1%er? Windows 11 turns up in the usage figures
- A bunch of apps will be able to bypass Microsoft's new store and use own update methods
- Oh dear, Universal Windows Platform: Microsoft says 'no plans to release WinUI 3 for UWP in a stable way'