Table of Contents
UWP and Windows App Platform
As you have probably seen, over the last month there has been some discussion around UWP (Universal Windows Platform) and the current focus, or change of focus, for Microsoft in terms of how developers should build applications for their mainstream operating system, Windows 10. There have been claims and counterclaims, making the entire debate quite interesting.
Needless to say, Microsoft directions for building Windows applications is of critical importance to most of our customers, and also for us as at Embarcadero, given RAD Studio has a strong focus on Windows development.
For a summary of Microsoft point of view, you can read this interview by Mary Jo Foley of Microsoft Corporate Vice President of the Windows Developer Platform Kevin Gallo: https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/
But let me start from the beginning and recap Microsoft plans (and how Embarcadero addressed those).
UWP Holy Grail and WinRT
A few years back, when Microsoft introduced Windows 10 for desktop the company still had high hopes for its twin Windows 10 Phone operating system. We know the phone ended up being a big failure for Microsoft, but at the time they were betting heavily on it. The idea behind UWP was to create a new common API and core operating system infrastructure that would allow the same application to run on all versions of Windows (including also Xbox and HoloLens). Technically, Windows 10 came with a new “core” called WinRT (initially introduced in Windows 8), a subsystem you can target with a specific API. This is not a .NET API, but more of a native, C++ type of API.
Side Note: Turns out that WinRT is “invocation compatible” with COM and it can be easily mapped to Delphi interfaces — which is what Embarcadero did offering direct support for this new platform API.
There were other key tenets: increased security (as apps run more in isolation and are safer in their memory management), more stability (with more responsive UIs and async processes), and that could allow Windows become a more stable ecosystem.
So why didn’t all developers jumped to UWP and WinRT? Microsoft offered a variety of programming languages (C# and .NET, C++, even JavaScript) and they expected large adoption. However, UWP came with its own UI design guidelines (wide spaced controls, full screen mode) and technical specifications (almost all code requiring to be asynchronous) that hampered development. Nice, modern, but quite different from any other API, platform and UX — and so difficult to adopt by developer, particularly if the target is more than one platform. Basically none of the existing code was ready to run there, regardless of the programming language you picked. And doing a full rewrite is not something developers (and their companies) are keen on doing.
Cross the Bridge or Stay on the Trusted Side?
After the initial dismal adoption (which allowed developers to publish app on the store — but a store that wasn’t well maintained) Microsoft started promoting a set of “bridges” to allow bringing existing code to the new UWP platform. There was a bridge for Android apps support on Windows Phone, one for Objective-C conversion, and one to allow Win32 native apps to become part of UWP. Now these were non-universal UWP platform apps, given they could run only on one of the versions of Windows 10, desktop or mobile. This ended up only adding to the confusion.
Moreover, Microsoft kept indicating these bridges were meant to help converting your applications to the new model, one form and one module at a time — rather than all at once. But the destination was still supposed to be a complete rewrite of your code. “If you have a million lines of code, you want to move to the new platform over time”, Microsoft was officially stating. But it was obvious developers didn’t really want to do ANY rewrite of their code for moving it from Windows to Windows 10! Considering all old applications kept running smoothly and the brand new features offered by the operating system were fairly limited.
Now again, RAD Studio (as well as Visual Studio) started offering support for the Desktop Bridge, but our goal was only letting developers target new APIs available only on the WinRT side (like notifications or BLE) and be able to deploy applications on the Windows Store — for easier distribution, taking advantage of low commissions, and additional monetization options (via subscriptions).
Is Microsoft Giving Up?
This brings us to today and the recent “announcements” by Microsoft. An interesting POV is at: https://mspoweruser.com/uwp-is-dead-because-windows-apps-are-dead/
The company has apparently just come to the realization that no matter their insistence developers are not going to rewrite applications to target the Windows operating system. In fact they keep using WinForms and MFC (on Microsoft developer tools side) or VCL (on the RAD studio one) or other native libraries. These days Microsoft is clearly downplaying UWP as a development model.
Notice that there are also reports of the fact XBox apps are now being built with Electron, a JavaScript desktop library: https://www.onmsft.com/news/new-electron-powered-xbox-app-leaks-hours-before-e3
The claim development for the Windows platform has stopped seems fairly exaggerated. There are still a lot of business applications written for Windows, and also real time control systems and games. While a lot of consumer apps moved to the web and mobile, investment on Windows development is still a significant portion of the IT budget — even though maintenance of existing applications is likely a significant part of it.
In any case, this is only one side of the scenario. The APPX model of the desktop bridge implies apps run “partially sand-boxed”. They cannot be elevated with admin permission, they can access only their “view” of the registry and operating system. Granted, they can still do damage, but the store vetting procedure should also help filtering out the bad guys. The concept around UWP / APPX is applications can be more easily isolated (and with .NET Core even have each their own copy of any required library). They can be installed with no admin permission and removed leaving a clean (or almost completely clean) operating system, mimicking the experience users have on phones.
Now this is not just surviving to the UWP model, but Microsoft has double its effort with the MSIX technology. This sounds and it is being promoted as an “installation” technology, but it is in fact the next interaction of APPX. MSIX apps can be distributed via Windows Store or within an enterprise distribution model, allow for extra security and what Microsoft originally called “virtualization” and now dubs as “containerization” — to piggyback on a common trend.
The idea apps should live more and more in isolation is also backed by changes at the .NET level, with the idea (a key element of .NET Core) that each app should ship with its own version of .NET rather than relying on the version of library the operating system provides — with the big advantage of reducing dependencies and allowing users to update .NET without fearing to break existing applications on their systems.
And What About RAD Studio?
This is how I understand the future of the Windows App platform — a future that allows Delphi and C++Builder VCL applications to play on par with Microsoft own UI libraries and ecosystem, with a much higher degree of compatibility with existing code and investment.
Windows 10 as target platform is alive and growing (within the desktop OS total, if not in absolute terms) and the VCL with its support for Windows API, COM, WinRT and APPX model has everything you need to target the platform. Our libraries integrate Windows 10 feature, High DPI support, and compatibility in a way that’s unparalleled in the industry — without forgetting a large ecosystem of great third party controls!
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
