On the other hand, this move is not without its costs. Microsoft has been trying to get third-party developers to build UWP applications. UWP applications have some desirable features: they’re safer (because they’re run in sandboxes and have a phone-like security model governing their access to files, cameras, GPS, and similar sensitive capabilities), they play better with power management capabilities (the operating system has greater ability to suspend them or terminate them to free memory), and certain parts of the UWP APIs are meaningfully more modern. In general, UWP applications should play much better with high-resolution screens, for example.
But UWP applications have had some big drawbacks: they only run on Windows 10, and in broad terms they required rewriting applications from scratch. The former issue is becoming less significant as Windows 10’s market share grows, and the latter issue has been addressed in part by Microsoft’s “desktop bridge,” which provides a way to piecemeal migrate a Win32 application to UWP, but nonetheless these factors have limited UWP’s appeal. If Windows 10 Mobile were on several hundred million smartphones then the price might be worth paying, but it isn’t right now. That leads developers to make the same choices that Microsoft has—stick with Win32. With Microsoft now implicitly endorsing this path, it’s hard to imagine UWP adoption to increase any time soon.
The move is also a bit surprising because Microsoft has very recently shown new hardware that uses the UWP Office apps. The company demoed its Surface Hub 2 systems this week, and one part of that demo included the use of the UWP Office apps. Surface Hub 2 is, after all, touch-based hardware, making the touch apps a better fit. The current Surface Hub cannot run traditional Win32 apps, requiring UWPs instead, and the features that make UWPs better behaved and more tightly controlled would seem valuable on appliance-like hardware like the Surface Hub.