IMHO WCentral isn't helping to clarify the confusion surrounding this topic. This article makes a few mistakes. This quote contains two that I think are relevant to the issue at hand:
That conversion can be thought of as a hybrid, allowing the Win32 app to continue to exist without substantial modification while also adding UWP APIs for things like Cortana, Live Tiles, Notifications, App updates, and more. When completed, the converted app is repackaged as a .appx or .appxbundle where it can be submitted to the Store.
What the developer actually gains by using the desktop bridge is the
ability to access UWP APIs, but that ability doesn't mean those APIs are actually accessed. Accessing those APIs requires that the developer modify their program. The part I quoted above makes two mistakes:
- APIs are not added to the Win32 app (that sentence itself doesn't really make sense)
- the Win32 app is not modified or converted in any way. The Win32 app itself stays exactly as is. If the Win32 app didn't access a single UWP API before using the bridge, then it won't access a single UWP API afterwards either.
MS confirms my second point in
this article where they state:
Your code is still the same, it's just packaged differently.
Why is this important? Because it explains how a Win32 app can be distributed via the Windows Store without actually using any part of UWP. That we're calling these apps UWP apps regardless is the real source of the confusion!
In fact, at least some people at MS realize that this is slightly ridiculous. MS are themselves using various definitions. For example in
this article MS states:
For example, a UWP app is an app that specifically targets the universal device family, and consequently is available to all devices.
That article was last updated two weeks ago, and in contrast to the definition WCentral is using, that one actually makes sense. Based on that terminology, an app that is brought to the store using the desktop bridge wouldn't be called an UWP app, because it doesn't target the universal device family set of APIs (the set of APIs shared by all devices that run W10).
In contrast to what WCentral is proposing, I'd recommend the following:
- App is availble in the Windows Store: "Store app" (that term is already in use and was established in W8)
- App specifically targets the universal device family set of APIs: "UWP app"
- UWP app that targets more than desktop systems: signaled using the badges on the store webpage (which MS already uses)
IMHO adding the tagline "runs anywhere" isn't a good solution. It means we can have a
universal app that doesn't even have the potential to "run anywhere", in which case we have to ask "why call it universal to begin with?". It degrades the term "universal" to mean nothing more than "available in the store". Is that really an intuitively grasped meaning of the word "universal"? For developers the proposal is even more unhelpful, as developers associate specific APIs and a specific run-time environment with the term UWP. We'd also have to explain why an app with the tagline "runs anywhere" doesn't actually run everywhere (often not on Xbox, very often not on Hololens).
I understand that WCentral is basing their proposal on how some at MS use the term "universal app", but considering MS are themselves inconsistent, I'd say it's best to push for a definition that actually reflects the technical reality of the situation. IMHO this proposal does the opposite. It doesn't solve the fundamental cause of the confusion and will ultimately just end up confusing even more people.
Facebook
Twitter
Instagram