These are only opinions, just like the article. I agree with the author that mobile isn't enterprise. Even if enterprise is clamoring for it now, it is a fad for precisely the reasons that the author pointed out. It's a local minimum of productivity that we will eventually tunnel out of; to an area where a real productivity curve exists (mouse, keyboard and monitor most likely).

I disagree that UWP is synonymous with mobile and the author has used the two interchangeably incorrectly. UWP, in theory, runs on all devices but - newsflash - Windows mobile is completely dead. It's exactly like having a go at Linux because it supports DEC.

All UWP is, is a more modern version of WPF that supports more than one execution target (CLI, JS or native). It so happens to run across many devices. I can't see why you wouldn't develop your enterprise software using it (apart from the horrific store) because it's no different from any other stack. If you don't care about it working on mobile, don't deploy to mobile. If you don't care about XBox, don't care about XBox. If you care about one platform only, support that one platform only.

The bonus is that if you aren't enterprise, and do care about the platforms you support, you can carry your skills there. Now, you'd be utterly mad to actually use it (as you would depend on users mad enough to use the store) - but that's the idea behind it.

I work in a similar space, although more focussed on the backend. I agree with everything you say as is applies to banking/trading.

BUT ... it's not clear to me that the majority of enterprise software development falls into this category. I think the vast majority is quite likely old VB apps that work perfectly well as web apps.

Most information workers don't have the density or latency constraints that the finance space does.

And where they do, I think in most cases their needs are satisfied by a small-ish set of applications: Excel, AutoCAD/ProE/Solidworks/etc, Photoshop/Illustrator/etc, VisualStudio, and so on.

I do think Microsoft (and Windows) needs a story for the development of "professional" apps like these. And UWP doesn't work for them. I'm not sure C# and WPF does either: how many of even Microsoft's own professional apps are written (or being rewritten) in C#?

Perhaps banking/trading is just too small a market to make it worth Microsoft's while to care about? Perhaps it's a market best served by a third-party stack/tools?

Another huge pain point of UWP: the whole suspend/resume concept.

UWP apps can't be closed by the user. The system manages the lifecycle and there's no way for a developer to know when the app will be terminated and when to save data.

To save your app's data you have to:

- Register for a suspend event

- Ask for an extended execution so that your app is not terminated within a few seconds

- Save your data and cross your fingers that the system does not terminate your app anyway and your data is lost

I recently ported a document-based macOS app to UWP and this was the BIGGEST pain point (aside from the fact that there's no easy way for an app to have more than one window, ouch).

> The Enterprise doesn’t care about mobile — it really doesn’t.

The enterprise didn't care about minicomputers, until it did.

The enterprise didn't care about PCs, until it did.

The enterprise didn't care about Web applications, until it did.

In each of the above cases, there were people insisting that The Enterprise would never follow the general market. The Enterprise has special needs, they said. The Enterprise needs things the new tech can't provide, they said. They kept saying that right up to the moment The Enterprise finally moved and made their objections irrelevant.

Enterprise customers see the hot new stuff general consumers have access to. They want it. And they command big enough budgets that someone will eventually get the hot new stuff up-armored and Enterprise-Readied so they can use it to peel off a share of those budgets. By the time this actually gets deployed the hot new tech isn't hot or new anymore, but that doesn't matter. Once the first enterprise domino falls, the rest tend to fall pretty predictably.

You can make a good living for a long time selling legacy tech into the enterprise market. But "a long time" does not mean forever. Enterprise software buyers move slowly, but they do move.

If anyone from MS is reading this, please consider throwing some support behind WPF. It's actually a very reasonable framework for native development, and with a few updates here and there, would be competitive (in terms of developer-hours) with the latest JS frameworks.

I doubt that will happen, as MS is seemingly embracing the whole web-services/HTML/JS model. VS Code might be the nail in the coffin - possibly an Electron test-case to see if the entire VS proper can be ported over.

The author has some good points. But the solution he proposes - bringing back WPF with a bunch of features they didn't bother adding in the last 12 years - that sounds questionable to me.

WPF wasn't really adopted the first time around. WinForms kept being used for years (till this day) after WPF was the official guidance.

And now, after WPF was abandoned for UWP there is very little chance Microsoft is going to resurrect it.

This article is pretty clueless, the author seems to be conflating his broad experience in the banking industry with Enterprise as a whole.

> The Enterprise doesn’t care about mobile — it really doesn’t.

I guess I can't speak for The Enterprise, but only as someone who works in an enterprise. We recently switched to a new service desk system with very strong mobile support, from one with none. Responding to support tickets is a significant aspect of my role, and this has been a huge workflow boost to me. Pretty much anything else we roll out to expand user's access in the mobile space is being gobbled right up. I don't know what rock the author's been living under but a statement like "The few mobile enterprise apps currently out there are more about productivity triage [...]nothing more" is crazy sauce. This space is exploding right now, although falling on their face in that platform race does mean MS and UWP are playing a pretty minimal role in it.

> enterprises do not buy their employees touchscreen laptops, unless there’s a really niche requirement — which is very rare.

Enterprise doesn't buy touchscreens laptops? We've bought hundreds of laptops in the past year and almost all are touchscreen -- not because we give a shit about that, but because they are cheaper than spec'ing a custom order from our vendor to get one without. I agree with the core tenet that touchscreens on laptops are likely never going to be useful, but MS seems to be responding to actual market conditions the author is ignorant of.

> we cannot take advantage of the super-accurate mouse and keyboard input devices that have been so amazing for so long.

I would posit the mouse is super accurate for pointing at fixed targets, but has dreadful accuracy for drawing or any sort of path-based input. There's a reason artists don't use them, and considering a broader range of input paradigms is a decision I would not so quickly fault an OS developer for making.

> Adobe have just release at design tool called XD that’s a UWP app. Compare its usability with its main (proper desktop) rivals like Photoshop and Sketch. The comparison is startling. XD feels like a small mobile app with limited capability, and its because that’s exactly what it really is.

XD is a specialty app with an extremely limited feature set. It is, by design, vastly limited compared to PS because it's trying to compete with more stripped-down successful prototyping platforms from competitors. This is a complete red herring example.

Can anyone explain, why would anyone ditch WinForms in favor of a newer technology on .NET stack? I mean complex apps, not simple forms? Winforms is close to metal (in the sense it is close to Windows), it's high performance in contrast to WPF and its virtualization, it's been here for ages and can't really disappear because WINAPI won't disappear.

The biggest downside for us is the deployment model, we'll stick with winforms for the foreseeable future* but getting the software onto user machines is still about as easy as it was in 1995, this is half the reason many apps become web apps in the first place, instant deployment.

Hosting a corporate store is azure only which is a no go, so we're stuck with the god awful click once.

There are no push deployments, when we release a new version we want everyone to be on that version, not waiting for the app store to get around to it.

The store may have caught up in this regard, but we also need to control which users get which version of the software for deploying preview builds.

The enterprise is MS's bread and butter and I always thought that they understood it well, I increasingly think that they never understood it and they just got lucky that for a time enterprise needs aligned with MS capabilities.

*There is a project to replace many of our winforms apps with react, can't wait to see this crash and burn.

I don't see a lot of engineering design, analysis and simulation software being done in the browser or mobile device. There are a few examples, but the really powerful stuff is desktop Windows (some still in WinForms) or Unix/Linux. The cloud offers some great potential for doing HPC stuff on large clusters, but the user interfaces necessary for DEFINING the problem aren't something I want to do on a touch screen or in a web Client.

I still hate the webclients for major brand tools like SAP and Successfactors where they still don't know about async calls...

I agree with this.

I was skeptical about WPF at first, as I didn't like XAML at all. I'm happy I stuck with it. Under XAML is a really elegant engine that you can interface with directly (few of my WPF projects have any XAML in them at all).

I skipped UWP for the same reasons as OP, and because you can't (as far as I have been able to figure out) distribute windows services with it. Win2D looked like an answer to a lot of my design issues, but I got a sense that the team building and maintaining it was smaller than mine.

If Microsoft heavily re-invested in the desktop I would be very happy.

I'll take the otherside, WPF was only useful on Windows desktops. UWP apps can run on desktop, mobile even consoles. Before UWP developing across all devices was much more difficult. Developing UWP with Xamarin you can get iOS, Android, Windows platforms with very minimal differences in many cases. With .NET Standard/Core 2 even older .NET libs work in many cases except a key part of WPF, System.Drawing.

WPF was built on older non .NET Standard/Core that doesn't work for Microsoft anymore, Windows lock-in is dead and that is what the WPF/Silverlight game was. They tried to platform lock in at the Windows layer with WPF but it was too late, mobile hit soon after.

Microsoft has to be cross platform now and the lock-in has been moved up to Azure, their new OS for developers essentially.

I think UWP is a better platform than WPF even with less maturity. Lots of people liked WPF as it was better than the previous iteration in Winforms, and probably grew a liking to it, but UWP is now and trying to keep old Microsoft platforms alive is a lost cause. Devs must move to what Microsoft is pushing just as you do with Apple, if not, feel the wrath of the future.

Agree 100%. I had a bunch of legacy Winform apps and faced the same dilemma.

Solved it by switching to Qt. It's excellent even if you just use it for Windows development, i.e. never use any of its crossplatform abilities.

i think this guy nails it.

One if the ways that Microsoft proved WPF could be used for real apps was that they wrote visual studio with it. you cant build visual studio witb UWP.

i hope that the platform gets there...but right now if i started a new windows app i would use the centennial bridge.

I agree with the article: enterprise will never play well with store/uwp nonsense. I have the same background - I work in high perf very heavy desktop .NET and I can’t see any reason UWP would work here.

But: I also see where Microsoft are coming from. There is no need to innovate in this space. Microsoft want people to run mobile, touch, store... and those of us doing heavy desktop can use third party tooling or just stay with the mature tools we already have. Microsoft will never sunset the legacy win32 stack, and enterprises of the kind the author describes will never choose a windows that doesn’t allow the standard win32 stack.

Reading the comments, I think most of you miss actual realistic complaints of the author.

1) UWP apps are absolutely horrible to debug. They use some kind of COM broker layer to deliver the majority of very cryptic framework level exceptions. Almost everything IS an exception. There's also no way to get proper stack traces in compiled applications and worse, only apps delivered through the store will symbolicate the final crash point, so good luck trying to find the root cause if it's not immediately obvious.

The level of absurdity here is, if you drop a file in a UWP app's drop target that doesn't have foreground focus, the data broker will throw an exception that you can't do that. There's no realistic way to manage that exception, so if you're not diligent it'll crash your app.

2) Then there's the whole XAML interface framework. (Though they seem to slowly be moving away from this to a more reasonable flexible framework, sort of like iOS CoreAnimation, called Composition.) Originally it was meant to be freely styled by "designers", but as the original WPF and Silverlight proved, this flexibility resulted in terrible designs and apps looked cheap and crappy. So the UWP XAML team instead built a completely stylized framework and all the controls have hard-coded baked in assumptions about those styles remaining unchanged. So in that aspect, even if you wanted to push UWP XAML to allow for more information density, you would run into all kinds of show-stoppers.

This is more about desktop development than enterprise development. With that in mind, I think there's a better chance of people figuring out how to get it done on UWP or with web technologies (perhaps with some help from MS) than there is of MS improving support of WPF.

Azure is where it's at now for Microsoft, and WPF/desktop apps don't run on Azure.

> Web apps don’t cut it. They don’t cut it as replacements for serious desktop apps.

I don't buy that. If the argument is that "the Enterprise" doesn't care about mobile for this last decade, then it certainly didn't care about usable and powerful desktop apps the decade before.

One thing I'm not seeing is people talking about the reason Microsoft created UWP: as a competitor to responsive web frameworks that could run on their Continuum and Windows on ARM platforms.

Full stop.

Of course, the second they abandoned Windows Mobile, it made UWP irrelevant (not that it was terribly relevant anyway).

Absolutely no one* wants to build an app that works only on Windows 10 desktops, Xbox and IoT devices. There's no use for that.

*Obvious hyperbole.

I understand the author's frustration, though I don't agree with all of his points. However, what is Microsoft's motivation for investing in WPF at this point? If they don't improve WPF, will enterprise customers stop using Windows? Unless it moves the needle significantly one way or another, they won't do much with WPF. Besides, they have their hands full on other fronts.

The mistake made in this article is that the problem with UWP is not that it is touch, but that it purports to be universal. There is no universal solution that works on both touch platforms and the desktop. Either it sucks on one of these or both of them.

The right solution is to make it so what can be shared is shared and what needs to be specialized can be specialized.

Enterprise isn’t Windows-only anymore. If you’re not targeting Mac and Linux, too, you’re doing it wrong.

This might apply for banking/trading, but it does not apply at all for education markets.

UWP comes from the "cloud-first mobile-first" Microsoft.

Neither are well suited to enterprise, and one of which has been canned.

I think we have to ask ourselves, why do we need apps that run on the local machine anyway? 90% of my CPU time goes to Chrome/Firefox. Outlook in one of those runs better than Outlook native on Windows. Play music in the browser works as well as any native music player. Netflix in edge runs as good as the UWP Netflix app. I suspect there's a lot of code reuse among them. There is no mass market for desktop apps anymore.

Even things like slack run better in the browser than outside as an independent app, because they anyway use a browser engine to run for compatibility.

I use vim and VS code for editing. Vim doesn't need a new framework, and VS code bundles an entire web browser engine within it (electron), again, for cross platform compatibility.

All the internal company tools like code review, ticket management, etc. which used to be native apps, now run in the browser, too.

So let me ask again, why do we need a new app framework at all? What we have with WPF is good enough for the rare app that actually needs to run natively. Everything else is a web app already.

Honestly do not see a lot of native development happening on Windows any longer but far more wev interfaces of some kind. I really do not see native coming back in a big way.

Ha ha it would be a progress if they dug out win forms and made it official api. And I’m not throwing away my Petzold