The problem with UWP started with Windows 8.

As consequence of the traditional WinDev vs DevTools relationship, WinRT did not care for a good story.

Worse, it forced devs to write the app three times because the APIs were not the same between phone, tablet and desktop.

Window 8.1, helped a bit with the Universal Apps model. Then the business code could be shared between platforms, but the views (XAML) still needed to be written three times.

Finally UWP was supposed to be back into one single code base for all platforms, but it still lacks polish.

One area is that .NET Native imposes restrictions on .NET code and they are still improving on that area.

Another burning point was that they dropped raw 2D APIs from .NET, forcing anyone that wanted accelerated graphics to go write DirectX code with C++/CX or C++/WRL. Forcing them to make Win2D available.

This is also one of the reasons why Visual Layer was later introduced.

C++ devs also don't know much what to expect.

Initially there was C++/CX and C++/WRL, then Kenny Kerr got hired to work on C++/WinRT, which would support UWP but with standard C++ instead of the extensions used by the former.

C++/WinRT is still WIP after two years, and C++ almost vanished from Microsoft UWP related presentations. The majority of C++ talks are always related to standards support, or OS X/Linux/Android related tooling support.

No word when C++/WinRT will reach feature parity with C++/CX, be supported on Blend or even actually integrated into Visual Studio.

Meanwhile HoloLens and Visual Layer graphical coding presentations are done with C#.

A real pity, because UWP is what I wish .NET would have been since version 1.0 built on COM and AOT compiled to native code, but Microsoft doesn't seem to get it right how to send an uniform message to the developers to build up confidence.

Didn't the problems start even before that? Windows 7 phone was the first new phone platform from Microsoft and was widely regarded as pretty good by the pundits. It had a whole new set of APIs though compared to Win32 (as could be expected), based on a Silverlight-like platform IIRC. Then Microsoft changed all of the APIs again for phone 8 as you outlined. That really scared off a lot of developers I think. Who would be willing to code for something so unstable? 2 new sets of APIs in as many years, with no kind of overlap or migration plan.

All these changes had their reasoned explanations back in the day: the install base was small so it didn't have much impact and they were removing cruft each time, but with hindsight it was a really bad way to go about creating a healthy ecosystem.

Kind of, it had to with "WinDev vs DevTools relationship" I refer to.

Windows 7 was .NET based, Silverlight for apps and XNA for games, native code was only available to Microsoft partners.

Then the WinDev won the next round and we got WinRT, fully based on COM, based on the initial design of .NET before CLR was a thing (Ext-VOS).

As side effect XNA and Silverlight were killed, not even ported to WinRT, and as I mentioned for accelerated graphics the APIs were only exposed at C++ level.

As a c++ developer it has been indeed impossible to figure out what ui stack to use from Microsoft. We ended up choosing Qt because it seemed to have much lesser roadmap uncertainty.

I can't see any compelling reason to use UWP. Functionality is limited, runs only on Win 10, Windows 10 mobile is dead. Why would you use it over WPF, Winforms or going straight to a web app?

This is probably where Windows 10S (pushed in education) comes into play. It's a version that offers "secure & superior" performance over normal Win10. Since 10S can only install from the Store app, devs are `forced` to port their app.

Only time will tell how effective this strategy is. I for one would love for this to succeed if it means better security for users (especially on older, technologically challenged folks)

I feel like it's more likely that the Education apps they're trying to push to UWP would be ported to the web. I am a firm believer that there are places where desktop apps make more sense but from a market standpoint, porting to UWP gives you access to Win 10/10S but porting to the web gives you Win 10/10S, iPhone, Android, Windows 7, OS X, Chromebooks, etc. That's a lot more coverage for your dollars spent.

Not to mention a decent path to Electron (mac, windows, linux native-ish) and Cordova (android, ios native-ish). React-native is conceptually better than UWP at this point.

Win 10S can run desktop apps that have been "converted" using the Desktop App Converter (nee Centennial) and uploaded to the Store. This is how iTunes will be coming to the Store later this year.

Currently the only device shipping with 10S is the Surface Laptop, and it can be upgraded to regular Windows 10 Pro for free for the rest of the year. I suspect that step 1 of the Surface Laptop setup experience for users-in-the-know will be to do this upgrade, just like "uninstall craplets" has been for previous Windows laptops.

Well, I don't see how Windows 10S helps push adoption of UWP since you can already distribute Windows Forms, WPF, or Win32 desktop apps on the Store today. At that point, why bother making a UWP app?

Also, Edge only have a handful of extensions. If they want to compete against Chrome, they have to do something about that, otherwise people will just use Chromebooks.

UWP will handle touch-enabled Win10 devices better. And while it's not a segment anywhere near the size of iPad, it's still there, so if you can reach it, why not?

The problem is that right now, doing UWP means no Win7 support, and that's a far larger segment - there are twice as many Win7 installs as there are all Win10 installs, and Win10 tablets would be positively minuscule in comparison. So this will change if and when Win10 becomes the dominant Windows desktop OS.

Win32 apps run with full thrust, instead of the actual UWP container, so ideally one should migrate to a proper UWP app.

But we all know how users and many devs, actually value security.

The devs may value security but they need the tools to actually build a working app. From what I have seen UWP is way too limited for a lot of apps.

I'm not sure UWP can be judged yet. Slack and Spotify, amongst others, just announced UWP apps.