Since the introduction of Windows-as-a-Service, Microsoft has been actively promoting a way to create universal applications that could leverage Windows 10 platform capabilities across all Windows devices: the Universal Windows Platform. But in the past months, more and more voices declared this common application platform dead, or at least close to extinction.
Today, I want to take a closer look at what the Universal Windows Platform is, my predictions for its future, and its impact on your long-term application management strategy.
What Is The Universal Windows Platform?
The Universal Windows Platform (UWP) was originally introduced in July 2015 with Windows-as-a-Service. It was at one point code-named Project Westminster Bridges, but apps developed on it were also sometimes referred to as Windows Store apps and Metro-style apps. The goal was to provide a common application platform for every Windows 10 device, including PC, tablet, Xbox, HoloLens, Surface Hub, and Internet of Things (IoT) devices.
The UWP toolkit consists of three components: some developer tools, the Store ingestion processing, and the Universal Windows Platform runtime frameworks. It allows developers to use the Microsoft-Universe languages they are comfortable with, such as C#, C++, and Javascript.
The general idea of the Universal Windows Platform was to create Hosted Web Apps that can be scaled to any Windows device natively. As long as your site is running as a UWP app in the Windows 10 App Host, you have access to a variety of platform capabilities.
.png)
Image Credit: Microsoft
Because this lets you call app-remote Javascript files, you can integrate with Cortana voice commands, Windows Live Tiles, active notifications, and the Windows Store. However, you won’t be able to platform APIs when navigating in browsers (Edge or others) or run any legacy components that aren’t available in Edge, such as ActiveX or Flash.
To create such a UWP application, a developer would start a new project by opening a blank Windows 10 Javascript template, creating the app package, and deleting all project resources other than the images and the AppX manifest. Then open the AppX manifest, add the start page URL and configure the App Content URL Rules. Now you are ready to run, test and debug.
The Universal Windows Platform Is Dead! Long Live UWP!
For years, Microsoft encouraged its Win32 app developers to develop Universal Windows Platform (UWP) and, specifically, Centennial apps moving forward — touting Windows Store support and lower support costs through automatic update rollouts as the major benefits for moving to UWP.
However, the Universal Windows Platform and AppX didn’t take off as Microsoft hoped. One of the most significant signs that Microsoft was de-prioritizing UWP was maybe the movement of Windows 10 app development teams to the Edge browser development.
So what is the future of UWP?
While some say that the platform is dead, I believe UWP is too important to Microsoft’s co-management strategy. It is simply getting redefined from making apps universally applicable to all Windows devices (Microsoft’s “Cloud-First, Mobile-First” Strategy from 2016) to allowing developers to take advantage of the new Windows features — regardless of whether your app is a Win32 program, a progressive web app, or a UWP app. Or, in the words of Mary Jo Foley, they are just “broadening the definition”.
MS to make UWP version of OneNote (OneNote for Win 10) the default version later this year. The fine print: https://t.co/F2RalGGvSn
— Mary Jo Foley (@maryjofoley) April 18, 2018
However, this new direction will have direct implications on your long-term management strategy.
Implications On Your Long-Term Application Management Strategy
While Microsoft has been actively trying to get developers off legacy Win32 apps, the writing has been on the wall for Click-to-Run packages, .exe, MSIs, AppV, and AppX as well for a while now. In June 2018, Microsoft actually announced it will no longer support App-V or AppX:
“Starting with Windows 10 1809 MSIX will replace AppX as Package-Format completely. But it’s not just replacing the File-Extension. MSIX will drastically extend the usage and configuration options while reducing known limitations. Ultimate target for MSIX is to provide a common package standard for UWP and Windows applications.”
Below is a quick sketch of how I believe this convergence will happen:
What We Know So Far About MSIX
MSIX is a new Open Source container type (SDK is available on Github) applicable for client workloads. It can apply to all Windows applications, such as Win32, WPF, Windows Forms, and UWP apps, as well as other operating systems. This new openmindedness already bears fruit as Advanced Installer and Cloudhouse have already announced their support.
While it inherits features from the UWP (e.g., its platform capabilities and easy management), it unites the Desktop Bridge, AppX, AppV, and MSIs. The distribution of your applications is only restricted by store policies they have to adhere to.
Furthermore, Microsoft states that:
- MSIX will be available in late 2018 (with the release of Windows 10 version 1809, code-named Redstone 5?)
- App-V is a Windows 10 Inbox product that is currently supported in every Windows 10 Edition and every Windows 10 release with an Inbox App-V Client will extend support time frames.
- A new MSIX Packaging Tool (currently in preview) can be used to convert and preserve previous App-V investments. The preview currently doesn’t support all features, but it can be used to update “existing Win32 application packages to the MSIX format,” according to the announcement. The preview will work on Windows 10 version 1803 machines using the Windows Insider Program build 17701 or later.
- All current Appx apps will be 100% supported in MSIX and will be automatically referenced and launched using MSIX.
Although there hasn’t been an official announcement, I believe that Microsoft will remove support for App-V starting around 1909 or even a little earlier to encourage developers to move to MSIX. MSIs, on the other hand, will remain relevant and the MSI installer will still be on many more Windows 10 builds, as there are millions of legacy applications leveraging MSI packaging.
Combating Competing Containerization Solutions
Why does Microsoft go through all this trouble? Moving its developer ecosystem to MSIX is Microsoft’s way of combating all the other containerization solutions such as Rain, Droplet, and others. And it is very smart too, as they are creating their own style and containerization approach that is embedded in Windows 10: MSIX will give you that container approach of delivering apps in a containerized way while embedding the best platform capabilities Windows 10 has to offer.
App-V / MSIX Short-Term Planning
So, what if you were planning on an App-V project? Should you stop and switch to MSIX? Here are your basic three scenarios and what to do:
- If you don’t have your containerization strategy in place yet, you should start familiarizing yourself with MSIX as soon as possible and evaluate an early App-V conversion.
- If you aren’t using App-V yet but you have made significant investment in planning for it, go ahead and create your App-V project. Then introduce containerization and migrate to MSIX when you are ready.
- If you are using App-V already, start evaluating MSIX as soon as it becomes available. Start using MSIX as a new package format which helps you extend the usage of your containerized applications. Once your features reached parity, start migrating to MSIX.
In closing, I want to leave you with two thoughts: While we are very early on and many of the things mentioned above might still change, it is important to get a head-start early on and stay on top of the developments, e.g., Microsoft’s interest in Progressive Web Apps, which I haven’t even touched upon yet. The other is that if this is done right, this development will enable you to reduce application complexity significantly!
