Microsoft and the UWP for Enterprise Delusion

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.

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?

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 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.

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.

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.

> 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.

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 still hate the webclients for major brand tools like SAP and Successfactors where they still don't know about async calls...

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.