Microsoft Confirms UWP Is Not the Future of Windows Apps | Hacker News Reader

Microsoft Confirms UWP Is Not the Future of Windows Apps

thurrott.com

57 pointsmrpippy77 comments

The comments on this post really make me wonder how many people have actually written a UWP app or tried using the API?

I have experience across a heap of stacks... Cocoa, Cocoa Touch, Android, Win32/WinForms/WPF, Web, Xamarin Forms etc... I love UWP. It was pretty ordinary in the first few releases but it has matured well, has great documentation and the UI framework is developed in the open on GitHub.

I am by no means suggesting you could write something like Autocad or Photoshop in UWP; perhaps you could with a rethink of the UI. But UWP is an excellent choice for probably 70-90% of desktop applications, including enterprise LOB that are just forms over data or integrating with an online service of some kind.

If you're drawing your own conclusions based on what you read from others writing (who are likely doing the same) - actually try the framework, you might be pleasantly surprised.

Finally, I think Thurrott has lost the plot. He has been waging this war against UWP for many years now - to the point of a crusade - I just ignore any statement he makes on this.

I concur, It has been a very easy and fast platform for me, and it seems like not a lot of developers have caught on to the fact that UWP is great for the end consumer, its snappy and can be updated without having to load the application or an update application first. But hey, developers don't like it so I guess thats forced Microsoft's hand.

> UWP is great for the end consumer

It it? I've never developed windows GUI apps, so can't comment on a technical level. But from a consumer perspective all the UWP apps I've tried, including those shipped by Microsoft with Windows 10, are awful. I think Windows 10 Mail could be the worst GUI application ever written. I used Windows 10 for most of the last year, and it got to the point where the Windows Store became my primary filter for apps - ie. if an app was available there, I'd cross it off my list of candidates.

> I think Windows 10 Mail could be the worst GUI application ever written

What makes you say this? I'm a heavy desktop user and find Windows 10 Mail to be the fastest and simplest way to interact with mail. It works perfectly with attachments, and calendar invitations, etc

It's a year or so since I used it, so I don't remember all the details. But off the top of my head: crashy, terrible IMAP implementation, mails often stuck in outbox, very incomplete keyboard shortcuts, links opened in Edge rather than default browser. I'm sure there was as lot more, but anyway I found it unusable.

actually try the framework, you might be pleasantly surprised

Enough people have used UWP apps and been repulsed enough by the experience to not want to inflict the same upon the users of apps they themselves write.

But UWP is an excellent choice for probably 70-90% of desktop applications

No. It's a massive failure even for something as simple as the Windows calculator, which is one of the apps that MS rewrote so you can actually compare the Win32 and UWP versions.

I wouldn’t be pleased if I had to use a LOB app without sub-pixel anti-aliasing.

I'll be really happy if UWP will die. I don't care for the visual side it offers at all, and the UX is simply terrible compared to the good old Win32.

Maybe I'm missing something, but the feeling I got regarding UWP is that it is an effort to unify the UX across all platforms and devices by aiming to lowest common denominator of all platforms. It meant that simple and useful utility like calc became a visually bloated app with sluggish UX. It meant every app takes double the screen size and offers half the functionality. In short, it made useful computer programs into passable mobile apps.

Isn't it obvious that mobile apps UI/UX is poor and is only acceptable as a compromise due to form factor limitations?

Did the strategy folks at Microsoft thought sacrificing the desktop will get them the mobile?

If you look at the history of Microsoft across platforms, with the exception of the Xbox they've been pushing the unified paradigm for decades. It's one of the things that really set the iPad apart at release- a tablet that didn't try to re-use the desktop paradigm, as opposed to the parade of previously failed Microsoft tablet attempts. UWP was simply an attempt to do the same thing from the opposite direction, with the same poor result. It seems to be lesson that's been very hard for them to learn.

> Isn't it obvious that mobile apps UI/UX is poor...

Isn't this the direction that MacOS is going too? I hear complaints of "iOS apps" becoming default on macOS too.

That will probably be fine for the 90% of Mac users who came from iOS anyway.

Microsoft figured out that the only way to scale mobile apps up across platforms is to dumb the apps down.

That’s an artifact of dealing with the real estate challenges on the phone and the side effect of this era where apps need to hustle users for marginal dollars first and do something useful second. That said, they failed on mobile, and the tablets are more like laptops than iPads. And the market likes that!

I think the younger developers are doing to flip to Chromebooks and Windows, as the Unix tool sets are there, and both vendors take their vision of PC seriously.

Didn't they fire the guy behind Windows 8?

Microsoft took mobile-first too literally and applied it to their entire OS

>Microsoft took mobile-first too literally

Server 2012.

This comment is spot on. UWP apps feel gratuitously non-native on Windows, have terrible keyboard accessibility, and exhibit a ton of interoperability issues with third-party utilities like xkeymacs that hook into platform functionality. Even Electron apps that use standard buttons and text inputs end up feeling more native.

The lack of good keyboard accessibility is particularly frustrating, because the ribbon paradigm and even the menu accelerators in old-school Win32 apps both had outstanding, highly discoverable keyboard control.

It meant that simple and useful utility like calc became a visually bloated app with sluggish UX.

That's an excellent example. A calculator does not need a loading screen, nor should it take over a second to start on any remotely modern machine. Fortunately MS have released the source, so you can see for yourself just how much bloat there is:

https://github.com/Microsoft/calculator

To compare, you can also see the source of the old "classic" calculator from Windows 2000 here:

https://github.com/pustladi/Windows-2000/tree/661d000d50637e...

That said, Windows CE was an attempt "to unify the UX", being basically a subset of Win32, and that didn't cause anywhere near the same level of disgust, so I'd attribute the bloat more to the cruft of "modern practices" than anything else.

What the hell is wrong with Microsoft? Everyone is excited about WSL, but Microsoft is failing miserably at their core competencies. They killed off Win32 OneNote to create UWP OneNote (which offers a fraction of the features), and then kills UWP? Every new Microsoft app somehow does less than the version you were using when Win2k came out.

UWP isn't being killed; the UWP API is merging with other framework APIs into a single platform API for Windows.

UWP as an API is very good. UWP as a user interface wasn't well received.

There was a talk at the recent Build conference about it, which is now available on YouTube if you want to find it and judge for yourself.

What is the title?

As a long-time Win32 (and Win16) developer, I am very pleased. Win32 is basically "Microsoft's POSIX" --- it might not have all the new-fangled trendy object-oriented best-practices fluff of the newer APIs, but being a simple C API means that it's not tied to any newer and "faster-moving" (i.e. faster-deprecating) technologies and also makes it more portable. Some of you may remember Windows CE, which is basically a subset of the Win32 API.

I don't know if the newer MSVC compilers can be configured to do it, but it's definitely possible to create a single self-contained binary for a GUI app that will run on everything Win95 and newer, and which uses a fraction of the resources of newer UI frameworks. A lot of developers these days are used to even simple apps taking over 1MB of disk, and when shown a native Win32 one will be astonished at how small and fast it is; what they often don't realise is that all apps used to be like that.

Win32 is the past, the present, and the future.

> Win32 is the past, the present, and the future.

The problem is there hasn't really been a present for anyone starting new desktop projects, at least with common corporate restrictions. Can't build on win32 because that's not the future, can't build on WPF because that's not the future, can't build on UWP because that doesn't work on windows 7, can't build on qt because we're an MS shop and don't acknowledge the existence of third parties. For several years it's just been "fuck it, we'll make a web app".

> A lot of developers these days are used to even simple apps taking over 1MB of disk, and when shown a native Win32 one will be astonished at how small and fast it is;

This is the most promising part of the librem phone for me, a couple dozen lines of C and you have a an app. On android you can't even get to hello world without downloading a bloated IDE, a huge SDK and a dozen xml files, they don't even provide instructions on how to build outside of an IDE.

I think from a developer perspective this is pretty misleading because all the "new" stuff in Windows development is just repackagings of UWP subsystems to work with Win32 apps. WinUI is the UWP UI stack, MSIX is the UWP package format, etc.

So even if they aren't really pushing the UWP "brand" anymore, if you have a UWP app you are already using all of the "new" stuff.

yeah, they are really just opening all of that stuff up so that existing apps can use it more easily. WinUI is one of those things that I just never thought would happen...but there it is. They are open sourcing the entire UI stack. It's crazy.

That wasn't the impressions I got from the article:

> And the way we know that’s true is that Win32, WPF, and WinForms have all been “elevated to full status”—Gallo’s words—in Windows 10 all these years later.

It sounds like they're promoting Win32 as a long term option. I wouldn't expect them to say "UWP is dead", MS has a history of playing "it's not dead it's just resting" with UI frameworks, WPF was one of those.

I'm also curios what these changes mean for compatability? Anything that can't be used on windows 7+ will be dead on arrival. If they could just provide a "This is how you build windows apps for 7,8,10+ that we won't deprecate in future" I'd be happy.

My comment isn't based on the article, it's based on observing what's actually happening, both from the conference sessions and activity in the various open source projects that it's about. The article is based on public info, so you can observe for yourself.

The truth as of now is that WinUI (the UI stack from UWP) is the only one of these frameworks actually getting significant new feature development. The main reason for this is that unlike winforms or WPF, it doesn't have a dependency on .NET, so it can be used by projects like Windows and Office that for the most part never adopted .NET and managed code.

Like if you watch this session from the conference -> https://www.youtube.com/watch?v=hKMzFjGfoy0 , it's billed as a talk on the Windows presentation platform as a whole, but they spend basically all their time talking about WinUI. The new React Native implementation for Windows is also being built on top of WinUI.

I think this was obvious just after UWP was released. It was like a separate ecosystem that got all the new goodies (eg Win2D) bit was fairly incompatible with the other ecosystems (WinUI kind of like WPF but not really, complicate AOT deployment builds that took an hour to compile, nerfed DLR, no explicit MT, a sandboxed app model, Windows store that no one wanted, etc...). Now they are saying that you can have the new goodies before you commit to the restrictions of UWP (if you ever want to), which is really how it should have been in the first place.

Now it feels like it is kind of too late, unfortunately.

I believe that with the new XAML Desktop initiative, we finally will get access to a broader Universal XAML dialect wich probably will be very based on the UWP XAML, but will be able to run outside the UWP AppModel and restrictions. If you see that along with the new .NET 5 perspective that will include even WebAssembly, maybe even SVG GUI on the Browser, we have a chance to finally have a decent cross-platform GUI and powerful programming languages, that I see as curated result of this decade of javaScript experiences. We will have the best of the two worlds, the Web and Native, the dynamic and typed, avaliable. All that said, I think that we are in good company also having the UNO Platform community folks, that I see as a garantee that all this will happen in a way that envolves the community needs.

https://platform.uno/

used to be mainly mfc programmer doing large client/server lob app suites; after dotnet, worked around five years with c# and like it (reminded me borland delphi from the college) but local .net projects keep under-delivering and growing more expensive than previous tech; so i keep being called instead to update or support mfc projects... using atl/wtl (and later powerbasic instead of vb6 to host activex).

The last few years sometimes for dynamic/customized/personalized corner case uis have been using fast AXML provided by codejock label or using css+html by terra informatica HTMLayOut/Sciter

Microsoft lost a lots of local enterprise lob custom apps with the always evolving dotnet platform and heavy resource requirements, lighter alternatives won their market

What is the current recommended API if you want to build a big new desktop GUI application for Windows today? Something demanding like a CAD application, perhaps. Something you'd have built using MFC or pure Window API in the past.

FTA: > And the way we know that’s true is that Win32, WPF, and WinForms have all been “elevated to full status”—Gallo’s words—in Windows 10 all these years later.

I guess these three.

I would probably do qt or WPF. For CAD probably a large part in Directx or Win32. But in general the picture for windows desktop apps is very murky. There is no option that really stands out.

If I had to do a windows app I would seriously consider electron. Which is very sad...

Electron seems to me to be the ideal path for the future. It has some major issues today. But I expect it will get a lot better. Consider the following: Microsoft owns Github and electron. One of the best electron apps is VSCode, a Microsoft creation. Microsoft is replacing the edge engine with chromium.

I expect that in a few years electron will be a very good experience on Windows.

my current option is gambas in linux (or vala before that) but in windows, for small apps i prefer powerbasic forms to generate easily win32 dialog based programs... for larger better looking programs atl/wtl + codejock toolkit. I should try Lazarus (qt + free pascal) but have never reserved the time to reacquire the ability i had with borland delphi in college

I still recommend Win32, there's nothing that beats it for efficiency or compatibility.

To be clear, this is just an opinion piece by someone not at Microsoft. And since the article starts with "As I predicted", I'd take it with a grain of salt.

I hope they keep chipping away at the Store. It's a nice additional stream of apps that while lacking in curation provides an easy route for novice users to get something or even just browse. They need either a higher bar for quality or much more vast curated content for users to explore. Same with UWP, I hope they don't kill it off. It's a good entry point for some- though I'm sure more adept programmers would have alot to say on that.

There is too much crap in the store, they need to get it out.

To distribute software the normal way you need to at least be able to register a domain name and run a web site and it seems the bottom 20% of app developers can't do that.

Nope. Github Pages + releases disagree. I know of many applications that are distributed that way. Hexchat for example.

They just need to allow non-UWP apps. I have some interest in the Microsoft Store succeeding. As a technician, I worked with tons of people who hadn't updated their programs in years and there was never an acceptable solution. Personally, I use choco to ensure all my programs are up-to-date without manually checking every single one, but it's not something I could've deployed for private customers. The Store could've been the solution, but UWP apps are far too limited and UI-wise a disaster (I recently tried VLC from the store, it's terrible). There's just too much good software that isn't UWP and I don't understand why they copied the store idea from Apple while throwing out one of its biggest benefits (access to any "full" MacOS program you could need, instead of splitting the user base).

The future of windows is JavaScript. And no, I’m not kidding.

Anyone who has used Office 365 in their browser can see that for many desktop things, you no longer need a framework. For everything else, it’s probably a custom library on top of DirectX anyway.

And I’m not saying I agree with this, but MSFT opened that door and others will follow whether they want them to or not.

Hell no. Whats wrong with plain old win32. Compiled software will almost always be faster than interpreted JS. Do we need a new system? UWP is more or less a flop, but the old way still works.

Now, I don't use windows on a regular basis, but clearly something was wrong with the UWP UX design.

But we don't need to replace it with a web based version of everything. Imagine electron based apps for your calculator....they'll be very very resource heavy.

Office 365 sure is impressing from a technical standpoint. It's also frustratingly slow compared to desktop Office, in my experience.

lol am sorry JS is like a weed which can not grow much taller than the browser platform.

I’d say that The JS weed is growing the browser platform. But yes it’s a weed.

Is it just me, or does Microsoft create a whole new Windows API with every release? How are people supposed to build anything without a stable API? No wonder everyone has switched to Electron.

The API is very stable. Any Win32 app from the last 24 years will still run. 16 bit apps will still run on the 32 bit version of Windows. They promote the cool new thing every so often, but all the old stuff still works and eventually gets the access to the new features.

Win32 is super stable. The .NET Ui toolkits churn every 3 years or so without much improvement. Very frustrating.

I haven't seen much (if any) churn in Windows Forms or WPF toolkits in about a decade. Are you sure about that 3 year thing?

i meant every 3 years there is a new, incompatible toolkit. Winforms, Html5/JS, WPF, Silverlight, WinRT, now UWP. Instead of refining what they have they create something new (possibly with less capability like WinRT), and put the previous toolkit into maintenance mode with only minor development.

This isn't as bad as it seems on Desktop. If you build to the old old api (win32), it has enough support to basically work forever. Longer if you stick around to release updates.

If you build to the new release, there's a good chance it's not going to work well on the next one though. This is part of why Windows Mobile failed. There weren't that many apps to begin with, but you needed to build differently for WP7, WP8, and WM10 if you wanted things to really work. And WM10 never got any users.

They just can't seem to settle on a UI framework. They have like 5 at this point.

They really need to just figure out how you make a GUI app on windows.

I want to make a GUI app in the same framework the Office team uses, if its good enough for them then good enough for me, see "eating your own dog food".

Coincidentally office is adopting more and more UWP controls in their Win32 app using these publicly available interop technologies.

That, as well as their new icons, the applications icons and even more so the icons inside the applications is terrible in my eyes. It feels like when your side lose the elections, the future is gloomy because of wrong decisions someone else took and you have zero control over it, while they have so much effect on you.

Unfortunately, the public APIs for the ribbon interface are broken to an extent. I havent checked recently, but as an add-on, it was impossible to get 2 excel windows to display different values in a textbox embedded in a ribbon for 2 sheets openned in the same excel process.

Despite the appearance of being separate processes because of separate windows, excel is basically a detached MDI interface where each sheet gets its own window, but same process. I think the other Office products are the same (but I'm not sure). I dont know how many hours I wasted at a previous employer trying to figure out what was wrong, but finally gave up after many frustrating hours.

That’s probably why Office 365 freezes a lot when you unplug screens and also sometimes renders a little blurry. They haven’t made it better.

This perception is due to the comparable longevity of the Windows ecosystem. Rate of change is the same as Android, or Apple's products. They just they keep the old ones around, and have twice the history.

Xamarin isn't either. It really is whatever open source cross-platform UI leads the pack. I am really impressed by Qt Apps, but I also am not happy with their licensing. I would like to see something new with Vulkan desktop integration. I think Microsoft really needs to reconsider what is important, and I believe them working on open source will have to be a better commitment. They should pay some of their Kubernetes engineers and Linux engineers work on a Linux Kernel OS. There are just certain nuances about their OS that they can't seem to grasp, especially when it comes to Mac at least application packaging better Windows. Choco for GUI apps is awful, and the only solution will be application containers, and Linux is likely going to outpace them... and I see more and more great apps for Linux. I don't think it will be too much longer.

What issues you've encountered with installing GUI apps with chocolatey?

I'm rather curious about this as well. Maybe he is saying that it is not as user-friendly because it is command-line-based? I have had no issues with it, and it seems it would be simple to make a graphical front-end.

Not at all. I prefer CLI based tools for system administrators. They are easy and quick to automate. It is just a pretty terrible package manager compared to Homebrew and far worse than Arch.

It is incredibly slow, buggy, most packages aren't up-to-date and the packaging is far more complex overall, lots of bad or missing documentation about silent installs. The package manager itself doesn't really offer a lot. I've seen more spyware in their apps. Windows app installs by default leave configuration files all over your system and registry entries. It is near impossible to cleanly manage an install. There are a lot of tricks for viruses on Windows. Linux is open source and much easier to improve collectively. There is a lot more thought put into these objectives from a system administrator perspective, hence why they use it all over their cloud.

> I see more and more great apps for Linux

Bit of an aside here, but what for example? I'm using Linux these days as the least-worst option, but I wouldn't have claimed app quality as one of its advantages. It has the best terminals (matched perhaps by iTerm on mac), and most of the important cross-platform apps are perfectly fine (VS Code, IntelliJ, Firefox, Chrome etc). Could you list some of the linux-specific apps you consider great?

Telegram works great, Slack works fine as does Discord. LibreOffice is descent, there are a few Money Manager apps. I'm not a huge fan of GTK or KDE-based apps, but ones developed in React Native and Qt with static binaries, then I really enjoy the quality and having the latest version integrated into my package manager. It is much cleaner to install and remove overall. Containers would help isolate this even more. I really also enjoy having most of my dotfiles in a single location to manage application settings that can be shared for other installs.

You're adding to my list of cross-platform apps. I agree that most of the important ones are fine under Linux, but I still haven't seen many (any?) great linux-specific ones.

There are obviously reasons to use Linux (I do), I just don't think unique (end-user, GUI) app availability is amongst them.

I guess it depends on what distro you're using.

Perhaps I misunderstood you. If you meant that lack of software isn't the Linux deal-breaker it used to be, for many types of use I'd agree. It has all the main generic apps I need except for a proper Google drive client.

What it doesn't seem to have is any linux-specific apps compelling enough to drive one to use it. This used to be one of OS X's big strengths, diminishing in recent years I think.

How does it compare to the new Windows Terminal?

Based on what I've seen, the new Windows Terminal is far from being close to anything on Linux.

Another issue is the lack of documentation. For example, the VPN API has zero documentation (it has the functions but not what they do or any sort of app notes) and you have to apply to MS for permission to use it. So most apps still use the massive, outdated WinTAP adapter.

or use something else with proper support... my choice is devp2p from weonlydo for linux/windows vpn app integrated networking (for not-integrated self-hosted vpn i prefer to use SoftEther, and ZeroTier for not-hosted cases)

Where is some good starter docs on all of the different ways to write a Windows UI app? I can't keep track of WPF, UWP, WinForms, WinUI?, winRT, .NET Core, .NET Foundation, .NET Standard

Microsoft's own docs site has a pretty good official guide to this, though I'd quibble with a few things (e.g., WinRT/UWP isn't really a "managed runtime" in the same sense as .net): https://docs.microsoft.com/en-us/windows/desktop/choose-your...

WinUI is the UI stack from UWP, which is being split into its own open source package and made available for use by Win32 apps as well.

Another thing that I think related to this is:

I respect JavaScript, but what I would add is this: We can not stop on JavaScript. JS is cool, brought dynamic new features that helped to reshape the other languages, but we need to also allow the other languages to run on the Web, since they got isolated when the Web expanded.

So if this new XAML initiative runs on the Web, it would be awesome!

Disagree with the simplistic conclusion.

Before I make a long comment, please spend a few minutes to take a look at this video and make your own conclusion: https://youtu.be/GrKA4D_8ngY?t=382

My interpretation of the direction is the opposite of Thurrott’s in some sense – UWP will be expanded and morphed together with Windows Forms and WPP into .Net core app eventually with .Net Core 5.0 Here is my take of UWP development that I have expressed on different occasions: 1. The best target OS compared with Android and iOS. 2. The best IDE (VS). Android Studio is catching up fast, but still has a long way to go before rivaling VS. 3. The best user experience compared with apps on other platforms (e.g. Android) for for which I also develop apps. 4. The worst app store by far. I have been suspecting that Microsoft Store killed Windows Phone. WP came out late, but it had a decent chance to survive and thrive (its market share actually reached double digits in some European countries), but the lack of apps killed it eventually. I blame Microsoft Store for it. It is pretty much the worst in every sense and had glitches one after another. If Microsoft had outsourced the app store to a competent company, Windows Phone could be rivaling iPhone and Android now. It is as if Microsoft thought the poor store was not hurting UWP apps enough, they introduced .Net Native toolchain nightmare to hit UWP further. I have never noticed any promised app performance benefit. Instead, one app’s performance deteriorated so much that it became almost unusable under certain circumstances after .Net Native was used. An app’s debug version may behave significantly differently than its release version compiled with .Net Native. It takes 10 to 20 minutes to generate an app package with .Net Native. More than 90% app development problems I have encountered are related to .Net Native nightmare one way or another. Sideloading UWP app could make up a little bit for the store’s deficiency, but it seems they have changed the sideloading mechanism many times. I have lost track of it. In summary, UWP apps are the first-class products marketed and sold by a third-class store. I cannot help mentioning one emerging technology that adds absolute excitement to UWP – Uno Platform. It allows C# UWP code used for creating iOS, Android and WebAssembly web apps. It is truly “program once, run on billions of devices".

I worked on Uno for a few years. We used it to build over a hundred iOS and Android apps. Nobody would guess they're built with UWP.

I have done native development for UWP, iOS, Android. UWP delivers the most consistent API, advanced tooling, and productive devrloper experience by far. This is part of why we picked UWP as the abstraction API for Uno.

That said, I believe that modern web development frameworks offer an even better developer experience, thanks to projects like TypeScript and React. I can't comment about Flutter yet.

Good riddance. UWP was another form of nasty lock-in (no support for Vulkan in UWP applications for example).

Reply on news.ycombinator.com