> I can't see why you wouldn't develop your enterprise software using it... because it's no different from any other stack From a .Net perspective, the article

> I can't see why you wouldn't develop your enterprise software using it... because it's no different from any other stack From a .Net perspective, the article authors, it's the debugging challenges that are the major salient difference between WPF and UWP. Considering the demands those frameworks place on developers who are making 'innovative' GUIs there are numerous things that can go terribly wrong at run-time. A lack of relevant debugging tools and a hop between technologies could be a showstopper for some. COM + .Net competence, like competence with the Win32 API, is somewhat generational. Younger .Net developers are not versed in these things, and those who are command significantly higher salaries and are increasingly less likely to be doing front-end work over time. If you're dealing with Enterprise customers, or development in the Enterprise, there are real costs associated with moving your baseline developer requirements into specialist territories.