[WorldMaker]

Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the GAC (Global Assembly Cache).

"Sandbox-first" even made some sense as a direction to work because it is harder to add a sandbox after the fact than to start with one, which is one of the core lessons learned from XP trying to sandbox some of the insecurities in Win32 and getting caught in a lot of complications. (The "sandbox-first" of UWP wasn't even that different under the hood from the XP "sandbox" of Folder/Registry Redirection, just a little better hardened.) Microsoft needed a lot better messaging up front if they had expected to allow more apps to leave the sandbox eventually. But Microsoft probably did believe the UWP sandbox was a better and safer experience for consumers.

But yeah, what's left of Package Identity outside of the sandbox feels like it includes several classic mistakes from .NET's CAS/GAC era, and also seems to point out that Sinofsky was wrong about WinRT "respecting the past" when it failed to learn from that era because it didn't trust .NET's history.

[ack_complete]

One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.

It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.

If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.

[WorldMaker]

> .NET at least allowed self-signed certs.

The GAC and certain CAS configurations would require paid certificates, too. Certainly the requirement of paid certificates can be seen as a part of how both of those eventually fell out of favor. That is another of the things I felt UWP missed learning from .NET. Developers do generally dislike code signing certificates and try to avoid them.

Also to be fair, UWP had a rather streamlined certificate system if you targeted only the Store and let the Store manage your certificate chain. It was even a little bit easier to use than Apple's similar App Store management of XCode certificates. Not that that was a high bar to clear.

> It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP

There was some progress. Office involves a lot of teams working at different paces and sometimes extremely different codebases. OneNote was fully UWP for a while and was at one point considered a flagship and testbed for UWP "Fluent Design" (both before and after the shift from touch-first to the over-correction to "it's just a desktop framework that sometimes is touch friendly"). Several new Office apps were written UWP first, including the "Office Hub" app that became called just "Office" and now is even more confusing called "Microsoft Copilot 365 app". "Outlook (New)" has always been React Native, but as a React Native project, it ran entirely in UWP, too, for a while. It was said to have been one of the drivers for deep UWP support in React native at the time. There were also the React Native-based Word, Excel, and PowerPoint "mini" versions that ran entirely in UWP. Those are said to have influenced more of the real codebases pushing towards React Native, but did not try to replace the original codebases in the same way that "Outlook (New)" today is overtaking "Outlook (Classic)".

There were a lot of strategy problems with UWP, but adoption was further along in some areas than it looked.

[hyperrail]

There are still some things that are still locked in the UWP world that I wish were not.

For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.

This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]

I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.

[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

[WorldMaker]

Those are some good points, and I especially loved that lifecycle management in the era where I used a lot of Windows 8 apps. Even on a Desktop with apps filling up my screen still seeing some of them pinned to 0% CPU most of the time (while I'm multi-tasking) in Task Manager was a delightful magic. I also agree that was one of the best parts of the UWP sandbox and one of the biggest shames when Microsoft had to figure out how to allow sandbox breaks that they couldn't find a way to make the lifecycle and other smarts parts of the sandbox more opt-out by default rather than "opt back into the full sandbox". Of course needing to opt-out by default was one of the reasons developers hated the sandbox in the first place. It's a marketing challenge no matter how you slice it.

That relates to some of my criticism that maybe UWP could have used more .NET veterans because that was one of the problems with the CAS sandbox. For the most part the CAS sandbox was "opt-in" and yeah software developers through ego, hubris, and everything else will most often declare "my app/library is a special snowflake and needs access to everything!" So even if things opt-in to additional security controls like CAS, no one tests or builds for Production in a CAS sandbox so even things that claimed to support CAS threw runtime exceptions all over the place to the point no one could trust CAS to the point were CAS died for being practically useless overhead because no one both opted in and knew how to test it.

UWP had a lot of good ideas. It's insistence that it didn't have much to learn from .NET's mistakes was not one of them.