Over the last couple of weeks there have been  several announcements from Microsoft that partially reverse past directions in terms of Windows development. In short, Microsoft is downplaying (if not fully deprecating) the Universal Windows Platform model.

Here are some relevant links:

UWP has been the application development focus for Microsoft since Windows 8 was released, and it was replacing a focus on .NET architecture as the Windows development platform.

Now this is a very interesting evolution from the perspective of developers (and development tools vendors like Embarcadero) who have remained focused on the classic native Windows development model, as we are first class citizens again after a very long time.

From Native to .NET and UWP

For many years, the native development model based on involving the classic Windows API and leveraging the three core Kernel/User/GDI libraries and all of their extensions has been considered an old-style, deprecated approach that would soon be abandoned. This is the classic model used by Delphi and C++Builder (with the VCL library), but also by Visual C++ (with the MFC library).

Windows developers were first encouraged to move to .NET (with the idea that the future platform APIs would require .NET and classic applications at some point would stop running on Windows). Over time, it became clear this wasn't going to be the case.

As the .NET-centric focus slowed down, Microsoft started pushing the next idea: the Universal Windows Platform. This was primarily driven by two ideas: one, the ability to run the same application on a desktop PC, but also a Windows phone, a gaming console and a visor technology; two, a more secure platform with limited access to the underlying operating system. At the API level, supporting UWP implied using the WinRT platform APIs, which were different and incompatible with the classic APIs.

UWP was slow to catch up. For Delphi and RAD Studio there wasn't an option, but also migration from Visual C++ and .NET and C# would imply using different runtime libraries and different UI controls -- accounting for a large rewrite of an existing application. When Windows 8 first shipped (still allowing classic API applications) there were very few UWP apps available, including from Microsoft. However, some of the new platform features were only available via the WinRT APIs, which is why developers and tools (RAD Studio included) came up with options to call WinRT APIs from within a classic application. RAD Studio Windows notifications support, for example, is implemented with this approach.

While Microsoft kept pushing for UWP, indicating classic apps were going to be deprecated, developers didn't really listen. The next step was promoting the so-called "Desktop Bridge", that is, the ability for native applications to leverage more of the WinRT APIs and to be "packaged" in a light container for extra security. This last feature was achieved by packaging an application as an APPX and later MSIX. Again, RAD Studio has long offered this support directly in the IDE. 

Microsoft initially described the bridge as a way to help migrate applications to UWP, which was still the company goal. Developers could move their application one form at a time. It quickly became obvious that developers had no real interest in converting their large code bases, but were interested in using all of the platform features. APPX and MSIX also opened the gates of the Microsoft Store for traditional applications.

Fast forward to the last year or so. Microsoft announced Project Reunion (now rebranded as Windows App SDK) with the goal of offering full interoperability for UWP applications to call native APIs and native applications to call any UWP API -- but ended up giving the native applications support a much higher priority, with UWP now left behind -- which is what the announcements above indicate.

Back to Native

So, in other words, after over 15 years in which Microsoft has been considering native Windows applications as second class, soon to be demised citizens, we have now a total reversal of the position. Native apps, or classic API apps, are here to say and are given priority in the context of modernization, support of new APIs, Windows 11 support, and so forth. Microsoft plans to bring UWP consents and APIs to the native world. 

This is increasingly happening, for example with the WebView 2 control (Chromium Edge embedded, which Delphi and C++Builder wrap and support), a COM component. Other new APIs also use COM, while others are native and some are based on WinRT -- but accessible from native applications.

If the native API model is here to stay, this is fantastic news for Delphi and C++Builder. Not only is this the model Embarcadero has always given top priority to (well, with the exception of the short Delphi .NET era), but it is also the model we have been extending and expanding over time way more than our competitors have done with their libraries. 

If you consider the alternative UI frameworks that use the classic API, like the MFC library or the WinForms library, they received much less focus and improvements from Microsoft than the VCL library has had. From additional UI controls to embedded WinRT and Reunion controls, from support for High DPI to UI styling, the VCL library has kept expanding at a much higher rate than competing native libraries.

That's why RAD Studio today is once more positioned as the best available solution for building native Windows client applications. Not only that, but it offers an astonishingly easy migration for 10 years old or 20 years old codebases, unparalleled by other offerings.

It's nice to be a Delphi and C++Builder developer and build first class Windows applications, now without even having to fear Microsoft deprecating the application model in the next version of Windows.