When WhatsApp made the universally hated decision to switch its native Windows app to a web wrapper, most of the criticism was directed at Meta. And rightly so. It felt lazy, it was a clear, RAM-hogging downgrade, and it removed what little “native” experience the app had on Windows.But the reality is a bit more uncomfortable.Even Meta didn’t have much incentive to stick with a native Windows app. The company barely updated it, didn’t bring feature parity, and eventually defaulted to the web version instead. The main reason is probably for the fact that web apps are cheaper to build and maintain. But the actual issue is that Microsoft hasn’t given developers a UI framework they can commit to in the long term. Web apps don’t have that problem.We recently heard from a long-time Windows Latest reader, Alexander Ovchinnikov, who also happens to be a developer. His points echo what a lot of developers already feel.Unlike macOS, which always gets native apps, despite having a much smaller user base, developers’ attitude toward pushing web apps just for Windows isn’t about convenience. It’s about trust, or rather, the lack of it.Over the years, Microsoft has introduced multiple “future” frameworks, only to move away from them later. From WPF and Silverlight to UWP and now WinUI 3, the company hasn’t changed this pattern. As Alexander puts it, many developers now assume that whatever Microsoft is pushing today might not last long enough to justify building on it.Microsoft hasn’t had a clear GUI strategy in decades, and Windows now offers too many frameworks without a definitive answer on what developers should actually use.Knowing this changes the outlook I had on web apps for Windows. They’re a fallback option when the platform itself feels uncertain. However, Microsoft’s recent love for making 100% native apps for Windows may turn things around.Windows went from one clear development path to too many confusing choicesThere was a time when building a Windows app didn’t require a mental debate. Early Windows development revolved around a single, well-understood approach. Win32 was the answer. One API, one mental model, and a clear way to get things done.Charles Petzold’s “Programming Windows”, which was universally regarded as the “Bible” of Windows development, made it accessible, and developers could invest their time knowing the platform wasn’t going to shift under their feet. That stability created trust, and trust made the ecosystem grow.However, instead of evolving Win32 into something more modern, Microsoft kept introducing new layers and alternatives. First came MFC as a C++ wrapper. Then WinForms for .NET developers. WPF followed with XAML and hardware-accelerated rendering. Silverlight showed up as a cross-platform bet. Then came WinRT and UWP during the Windows 8 and Windows 10 era. And now we have WinUI 3 with the Windows App SDK, alongside MAUI for cross-platform development.Each of these was announced with a strong pitch about being the future of Windows development. Each one asked developers to invest time, learn new patterns, and build on top of it.The issue wasn’t that these technologies were bad. Many of them were genuinely ahead of their time. The problem was that the “future” kept getting replaced before it could fully settle. Instead of a single evolving platform, developers were left chasing moving targets.Jeffrey Snover’s detailed blog points out that Windows stopped having a clear answer to a simple question: how should you build a Windows app?WPF was supposed to be the future, until Silverlight came along, which looked promising, until Microsoft pivoted to HTML5. UWP was pushed as the unified platform for everything, but never gained full adoption, even internally. WinUI 3 is now positioned as the modern solution, but its roadmap hasn’t inspired the same level of confidence developers had in earlier eras.When Microsoft introduces a new framework with a clear direction, developers will start adopting it. Then the strategy would shift, and attention would move elsewhere. The previous framework wouldn’t always be officially killed, but it would slowly lose relevance. This cycle repeated enough times that developers stopped fully committing.As Alexander told us, the sentiment today is, if Microsoft couldn’t stick with previous frameworks, why assume the current one will be any different?That’s how things look today. Ask a developer what they should use for a Windows app, and the answer depends on who you ask. Some will still recommend Win32. Others prefer WPF because it’s stable. WinUI 3 is positioned as modern, but not universally trusted yet. MAUI exists for cross-platform use. Then there’s the web route with Electron or PWAs. On top of that, third-party frameworks like Avalonia and Qt are gaining traction.This isn’t the kind of choice developers were asking for. It’s total uncertainty.Why developers are choosing web apps instead of nativeSome of the most popular Windows apps are not truly native. WhatsApp, Spotify, Discord, Slack, Notion, Zoom, and even parts of Microsoft’s own ecosystem…Microsoft Teams (before its rewrite), Clipchamp, and several first-party experiences use WebView2.Microsoft ClipchampOf course, it has become so easy to build a web app once and ship everywhere. It can run on Windows, macOS, Linux, and even inside a browser without maintaining separate codebases. Frameworks like Electron, Chromium-based WebView, and Progressive Web Apps have made distribution simpler, updates faster, and development costs lower. Companies find it hard to ignore.Microsoft’s pivot to WebView2 embeds the Edge (Chromium) engine inside apps. It works well for consistency, but it also means many “desktop” apps are just web pages running in a container.And the obvious downside is that these apps consume more RAM, feel less responsive, and don’t integrate as deeply with the OS. Running multiple Electron apps at the same time can easily eat through system resources, something native apps traditionally handled much better.“WhatsApp” is new version and “WhatsApp Beta” is old UPW/WinUI in the screenshotOn macOS and iOS, developers still prioritize native apps. Even companies that have web technologies elsewhere build native versions for Apple devices. That’s because Apple has maintained a much clearer development path. Frameworks like Cocoa, AppKit, and now SwiftUI have been consistently supported and evolved. Developers know what to use, and more importantly, they know it will still be relevant years later.Windows doesn’t have that same clarity, and developers respond accordingly.So instead of betting on a framework that might change direction again, many choose the web. It’s not perfect, and in many cases, it’s objectively worse for desktop performance. But it removes the bigger risk of depending on Microsoft’s next decision.Microsoft is trying to fix this, but it may be too lateThere are signs that Microsoft is aware of the problem. Recent efforts suggest them moving toward improving performance, reducing reliance on web-based components, and building more native experiences across Windows. Rudy Huyn’s X post welcoming Windows developers to build 100% native apps has been looked upon in a positive light.But fixing the apps themselves is only one part of the equation.Even if Microsoft delivers better native apps going forward, developers are still going to hesitate. The hesitation doesn’t come from what WinUI 3 can or cannot do today. It comes from what happened to everything that came before it. Years of shifting priorities have made developers cautious, and that kind of hesitation doesn’t disappear overnight.If Microsoft wants to change that, it should fully commit to one framework and communicate it well to developers. That also means sticking with a framework long enough for it to mature, making its direction clear, and supporting it. Developers need a roadmap they can trust, along with clear migration paths when changes do happen.The real problem isn’t technology, it’s consistencyMicrosoft doesn’t lack capability. The company has some of the best engineering talent in the industry and a long history of building powerful development tools. Many of the frameworks it introduced were genuinely strong from a technical standpoint.What’s missing was and is consistency.Rebecca Sutter’s analysis mentioned that the issue isn’t technical failure, but a pattern of internal decisions that repeatedly shift direction.These have repeatedly translated into uncertainty for developers. From the outside, it doesn’t matter why those changes happened. What matters is the result. Developers were left with multiple paths, none of which felt guaranteed to last.That’s why the situation looks the way it does today. The problem isn’t that Windows has too few options. It’s that none of them feels definitive. Developers are not asking for more frameworks. They’re asking for one they can trust.Web apps are a symptom, not the problemWeb apps are not taking over Windows because they’re better suited for desktop computing. In many cases, they aren’t. They’re taking over because they offer reliability to developers who no longer want to invest in the Windows platform.Developers can’t be blamed for making a calculated decision based on past experience.If Microsoft wants to improve the quality of apps on Windows, the solution isn’t just committing to fix Windows 11 and build native first-party apps, but rebuilding trust with developers and proving that this time, the platform (WinUI3, I hope) will stay consistent.The post Developer explains why Windows 11 keeps getting web apps instead of native apps appeared first on Windows Latest