With the demise of UWP, native development has reclaimed its place as the primary Windows development model after 20 years (given we had .NET in between). Delphi excels at native programming, so this is fantastic news for us.
Several announcements from Microsoft in recent weeks have partially reversed previous directions in Windows development. In short, Microsoft is undermining (if not outright rejecting) the Universal Windows Platform model.
Here are some relevant links:
- Microsoft publishes UWP to Win32 migration details, but it’s probably not what you think https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details
- UWP no longer fashionable as Microsoft releases guidance for migrating apps to Windows App SDK https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to-windows-app-sdk/
- Microsoft Officially Deprecates UWP https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp
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 stay 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.
By using Native Windows Development, your team can create compelling GUI applications with feature-rich functionality and the Windows look and feel in less time. Building data-driven applications are simple with a wide range of included components for database access, queries, and user interface development. Try the free trial here.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
This is my reward for sticking with Delphi since the beginning and resisting alternative ‘solutions’
I would love to have one again that works well after version 10.3.3 because the 10.4.2 and 11.0 +1 patches are unusable.
Can you elaborate, regarding what exactly makes them “unusable”, please?
I personally have (at least) hundreds of thousands of lines that have moved from 10.3.x to 1.4.x and now to 11 with very little effort. There’s always a couple of issues here & there but not “unusable”
I have 10,000,000 lines of projects. Version 11 IDE crashes regularly, starting debug five times does not work three times. No breakpoints or no variable values. 10.4 (0,1,2) is even worse.
Congratulations for the great decision!
Now this is an example to keep up with your own path, regardless of imposed trends.
The CodeGear team learnt from the past when they tried to implement .NET compilers and catch up with M$ and now they know the M$ has a history of liking to play dirty and to set traps.
Ok, now just let’s just take it back to Delphi 7 and everybody is happy.
While Delphi 7 was indeed a great product and a very stable one, it would be hard to use it to build 64-bit Windows applications, support High DPI, and call any of the Windows API added over the last 20 years and that Delphi 11 does support today.
Fantastic news! Apparently everyone knew this would be the eventual outcome… except for the “dreamers” at MS.
I can only imagine that wasted R&D costs for a company like Embarcadero, due to reckless announcements by MS driven more by sales / marketing motives than technical merit.
Well, perhaps the word “reckless” is a little strong. 🙂 Even the likes of Microsoft, who one assumes has a huge research budget to test out potential user reactions, sometimes have to rethink their strategies in the face of technological and aesthetic evolution. But, yes, it is a bit of a problem for all developers and development tool companies when Microsoft – or Apple – or indeed Linux and Android for that matter, rethink the direction of their future in ways which mean a lot of hard work by others suddenly becomes moot. Even Facebook are marching toward a metamorphosis which will see them give up the name “Facebook”, something a few years back would have been unthinkable by all of us, not the least Mark Zuckerberg. Things move around. The one constant in technology is change. Microsoft’s apparent recognition of the re-emphasis of native apps being the right direction to revisit is, of course, what Embarcadero has been saying for a very long time. It’s nice to be joined in that belief. 😁👍
Love to see that news filmed by Pedro Almodovar 🙂 Does it means that .NET developers are welcomed back on Delphi board? Greetings for all longtime Dephi community members.
😂 LOOOOOOOOOL ! ! ! ! !
Glad you’re pleased! At Embarcadero we’ve been saying for a long time we think this is the right way to go; it’s nice to have that supposition bolstered by Microsoft finally agreeing with us 🤪