The Microsoft Store, Universal Windows Platform Apps & Developer HELL
Getting Discovered
As a software developer, I want my app to be discovered. I want people to know it exists and try it out. I’ve spent over 10,000 hours developing my software, and even if it’s the best app in its niche, it’s disheartening when it doesn’t reach its potential audience.
The Microsoft Store Opens
After witnessing the success of Apple’s App Store, Microsoft decided that Windows should have a store of its own. Initially, the store was basic, but it allowed you to list and sell your desktop application through Microsoft. It wasn’t perfect, but it was relatively easy to set up.
All a developer had to do was provide a pre-activated installer EXE file. Once authorized by Microsoft, anyone could run the Microsoft Store app, purchase the installer, and use it without the need for separate activation—a quick and simple experience.
The rise of Universal Windows Platform
Then Microsoft introduced the Universal Windows Platform (UWP) application model. Microsoft wanted a fresh start, discarding legacy desktop applications in favor of a model that allowed the same application to run across different platforms (Xbox, HoloLens) and processors (ARM).
On paper, this seems like a logical course of action. Every developer dreams of seeing their code run on multiple platforms without additional effort. However, UWP applications can’t really share a codebase with legacy applications. UWP is a completely new framework.
The Microsoft Store Closes
With the introduction of UWP apps and a revamp of the Microsoft Store app, Microsoft made the store UWP-exclusive. Suddenly, developers could no longer list desktop apps on the Microsoft Store. For many, this meant losing an important sales channel, with the only option being to rewrite their entire codebase to fit the UWP framework.
Microsoft comes to the rescue (sort of)
The ratio of desktop apps to UWP apps is staggering. Many app codebases run into millions of lines of code, and converting such large codebases to UWP is financially impractical for most developers.
To work around this obstacle, Microsoft introduced a UWP wrapper solution initially called “Desktop Bridge” and later renamed to “MSIX Packaging”. You feed the conversion tool a desktop installer EXE (and fill in lots of data), and it produces a UWP application that can at least run on the same CPU architecture. It sounds like a great solution, if only it worked out of the box.
Developer HELL
Besides supporting multiple CPU architectures and different Microsoft platforms, UWP apps are designed to run in isolation. This introduces new limitations for desktop apps wrapped in UWP that were never present in their original versions.
The Split Path Conundrum
In ancient times, Microsoft instructed developers to install applications to the “Program Files” folder by default. By the time Windows Vista was released, Microsoft decided, for security reasons, that developers should split their files into two folders: a “Program Files” folder for static files that don’t change, and a “ProgramData” folder for files that can be modified (such as configuration files).
However, the UWP wrapper virtualizes the installation, making the desktop app think it’s installed in one path while it’s actually running from another. Additionally, the UWP installer only allows writing files into a virtualized folder chosen by Microsoft. This breaks any desktop application that looks for files in the “ProgramData” folder post-installation.
Glitching 3rd party components
What happens if your app uses pre-installed, system-level components from third parties? In my case, Zoom Player uses MadVR, a third-party video rendering component based on DirectShow. Trying to use such components is hit or miss. Some work, while others mysteriously fail without any clear solution.
No Updates
What if your UWP-wrapped desktop application has a separate executable to update third-party components and ensure your system is up to date with the latest technology and security patches?
In my case, Zoom Player’s Install Center refuses to work. You can’t have a second self-contained application within a UWP wrapper, as it doesn’t fit the UWP model.
Broken Registry
This is a recent issue that has affected the latest version of the UWP wrapper tool. For reasons I have yet to understand, Windows Registry values are not always saved across sessions. Initially, this caused the UWP-wrapped version of Zoom Player IPTV to lose its settings every time it was closed.
No Shortcuts
Zoom Player’s standard installer includes helpful shortcuts for accessing the Install Center, Online Help, Usage Guides, the Support Forum, and more. However, the UWP version limits you to a single shortcut that only opens the app.
Store setup website issues
Attempting to reserve a new name for 'Zoom Player IPTV' failed. The Microsoft Store website returned an error, despite indicating that the name was available. To work around this issue, a previously reserved name from a few years back was used and then renamed.
Conversion issues
Each time Microsoft releases a major Windows update, parts of the UWP compilation and conversion process break. New issues constantly arise, requiring fixes or workarounds. Sometimes, previously resolved issues resurface, wasting even more time searching for new solutions.
The Microsoft Store Reopens (sort of)
After seeing developer frustration and the limited number of UWP apps submitted to the store, Microsoft once again decided to open up the Windows Store app to desktop applications… sort of.
You see, instead of allowing developers to sell their software directly to the consumer, desktop apps are still relegated to second class. Desktop apps on the Microsoft Store are only allowed to be listed with a link to their home page.
I’ll reiterate, at the time of this posting, if you’re a desktop app developer, you can’t sell your software on the Microsoft Store app as-is, you have to jump through many technical hoops in order to produce a UWP wrapped app that is a semi-crippled version of your desktop app.
Frustrations with Microsoft Defender Smartscreen
Microsoft defines the Defender Smartscreen program as "Microsoft Defender SmartScreen protects against phishing or malware websites and applications, and the downloading of potentially malicious files". Smartscreen is integrated directly into Windows as part of Microsoft's OS level safety measures.
In reality, the Microsoft Defender Smartscreen program works in two ways: a 'good' list a 'bad' list. If your installer is new, it won't be categorized under either list and Smartscreen will display a scary warning when trying to download any installer it's not familiar with.
For software developers, Microsoft provides a process for submitting a Windows Installer EXE file to the Smartscreen program prior to an official release. I use the same Microsoft account to submit Zoom Player's installers to the Smartscreen program that I use for publishing updates to the Windows Store.
The installer EXE files are digitally signed with a code-signing certificate, verified by a trusted third-party authentication service and I’ve been submitting updates for years. Would it surprise you to learn that nearly every update I submitted to the Microsoft Store was rejected because it was falsely flagged by Smartscreen?
This means that if I have a high-priority update, a critical bug that broke the entire application or a recently discovered security vulnerability, there’s no way to issue a quick fix. I'm forced to wait, sometimes for days, even weeks, for the installers to be added to the 'good' list before they can be accepted into the store.
Conclusion
I managed to work around most of these issues, but it required hours of effort and frustration, with literally thousands of dollars’ worth of developer time wasted. The Microsoft Store app still has a long way to go. The user interface and experience remain sub-par, even after all the revamps. Developer support has been, frankly, painful for desktop developers. I sincerely hope Microsoft will eventually see the light and change its attitude.