Microsoft is aware of the “framework gap” that pushes developers to the web or other frameworks, and it just rolled out one of the biggest updates for WinUI. Today’s update adds support for TableView, chart controls, and even addresses one of the bugs that contributed to memory growth on Windows 11.

The update is Windows App SDK 2.5 Experimental, released on September 29, and it finally adds WinUI 3 TableView and Chart controls. More importantly, it includes fixes for WinUI memory growth.

If you remember, Microsoft confirmed at the Build 2026 developer conference that WinUI is Windows 11’s flagship native framework, and it’s going to catch up eventually in all areas.

It also admitted that WinUI is still a mess in some areas, and there’s a framework gap where other frameworks, even though they’re not native, have more features than WinUI.

For example, until now, you couldn’t build a WinUI app that supports TableView and Chart controls using Microsoft’s own native controls. It might not sound like a big deal unless you realize how many apps could actually use these controls

WinUI did support some of these controls through community-made efforts, but these basic features have been missing from Microsoft directly. You can’t expect a “flagship” framework to not even natively support charts, right?

Until now, quite a lot of users, and even developers, believed that Microsoft’s promises to make WinUI better were just “words,” as it’s not the first time the company committed to a framework and later abandoned it.

In fact, WinUI was a part of a big push during the early days of Windows 11, but at some point, it started looking like the framework was dead, and even Microsoft moved some of its own apps to the web.

You’ve got apps like MSN Weather or even the Start menu using web components, and its flagship products, such as Outlook and Teams, are web crap.

Microsoft is shipping the WinUI controls it promised at Build

At Build 2026, Chris Anderson from Microsoft’s Windows UI team shared the following statement:

“We have DataGrid and Charting that are up and coming that should be out relatively shortly,” Anderson said during the session. “These will be showing up in the core WinUI bits and will allow you to go after a lot more of these data-oriented scenarios.”

With Windows App SDK 2.5 Experimental, you’re getting TableView with grouping, templated group headers, sorting and filtering with column-header sort indicators, pointer and keyboard column resizing, and optional tooltips for cells and column headers.

Moreover, WinUI Chart control support has also landed in this release, and as I noted, it’s a big deal because native Windows apps have lacked some of the most basic controls enterprise developers expect out of the box. It pushed developers to other frameworks, such as Electron.

Microsoft also fixed WinUI memory growth issues

Windows Latest observed that the Windows App SDK update also has a critical fix that should reduce memory usage for some modern apps.

According to Microsoft, WinUI had a bug where memory usage could grow when apps repeatedly created visual-state storyboards or resolved static or theme resources.

And that reminds me that Microsoft made it clear that performance is one of the areas where WinUI lags, and it can do better.

“The first and foremost is performance, fundamentals, quality, fixing a lot of bugs,” Anderson said at the Build 2026 developer conference.

He also noted that WinUI can sometimes use more memory, but it’ll eventually get better because Microsoft has heavily invested in improving memory usage, and it’s necessary given the rising cost of RAM.

“On the performance side we’ve invested heavily in really improving memory usage as well as switching over to a system compositor which should yield some even better performance improvements,” Anderson said.

We’re finally seeing some of these improvements, but they’ve only landed in Windows App SDK Experimental, so users and developers won’t automatically receive the benefits immediately.

Microsoft previously also said that it’ll begin integrating WinUI into the Windows shell at a much faster rate after patching critical bugs, and this memory growth fix could be part of that larger push. Moreover, we’re also told that Windows will get more native apps from Microsoft, and by native, the company means “100%” native.

“We’ve started to integrate it into the shell at a much faster rate,” Anderson said. “And so you’re going to see a lot of the first-party features coming from Microsoft being built on top of WinUI.”

How bad is Windows 11’s app situation?

Most people do not realize how bad the state of Windows 11 apps is unless they look at Task Manager and pay close attention to the framework of the apps. Most popular apps either use Edge’s WebView-based web apps or Electron, and most have not even bothered to optimize their web crap, which makes the situation even worse.

In fact, as somebody who has been following Windows development for decades, I’ve watched native apps become web apps, then become native again, then get abandoned and go back to the web. For example, WhatsApp had a native UWP app, and even Microsoft’s Copilot had a WinUI app. Both were replaced with web-based versions that used considerably more RAM in our testing.

WhatsApp’s WebView2 version climbing from about 600MB to 1.2GB of RAM while scrolling through messages in our November 2025 test. Playback is sped up 2.5×. Video: Windows Latest

For those unfamiliar, Discord uses Electron, which packages Chromium and Node.js with the app. On the other hand, apps like New Outlook, Teams, WhatsApp, and MSN Weather use WebView2 to run the entire shell in a Microsoft Edge-powered container.

Here are some of your favourite apps and their framework:

Funny enough, WhatsApp is that one perfect old app that was easily running with 100 individual chats and around 30 active groups with that small idle footprint. Now, it feels like a pain to use WhatsApp on the desktop.

And it’s not just WhatsApp that abandoned its native app. The irony is that Microsoft made a similar choice with Copilot when it replaced its well-built WinUI version with a web version that shipped with its own Edge package and used more resources.

It makes you wonder why these developers are not picking up WinUI. Is WinUI bad, or is it because Microsoft doesn’t enforce its own framework enough? Well, I’d say WinUI has been ignored for all these years, and it wasn’t clear until March 2026 what Microsoft’s flagship framework for Windows 11 actually was.

Microsoft itself used different frameworks for different apps and parts of the OS. For example, the Start menu still uses React Native for its Recommended feed and All apps list.

WinUI is not close to perfect, and that’s why we’re seeing these memory-related fixes or basic features finally getting added. But when you have other alternatives like WebView or Electron, I’d go with the lesser evil, and that is WinUI.

There’s no chance Windows would go back to classic Win32 apps, which worked better, felt native, and used fewer resources than any of these frameworks. But if Microsoft wants Windows 11 apps to feel less like web pages running inside Edge, WinUI is probably the closest practical answer it has right now.

The post Windows 11’s WinUI just got basic features and less RAM hogging, after years of losing apps to the web appeared first on Windows Latest

Here's a software pattern that I've found new use for in our new world of agents. I'll motivate it with an example from build systems.

When using build systems you often write down some information that feels redundant. For example, from the source code you can see that module A imports from module B, but then the build system requires you to separately tell it to build module B before building A. Why do we need to write this out, when it is visible from the source? It is tempting to figure it out automatically, as tools like ekam do.

The easy answer for why we don't always do this is the normal software answer of path dependence and how software tends to be clunky. But there are also two good reasons: information like this can be costly to gather and also can be hard to get completely right. It can be costly if your language design you might need to parse the whole source tree to find where a given module actually lives, as perhaps with C++ modules. It can be hard to get correct if there is configuration complexity; for example in a C file with #include "config.h", it is not clear which of potentially multiple config.h candidates it means; a tool that guesses will be hard to predict and sometimes wrong. (Just so I'm not only picking on C, I'll add that finding where a given import ... from 'x' in JavaScript resolves to has surprisingly complex semantics, and can even depend on the path of the source file.)

However, in the common case it really is often possible to automate things, and it's not that costly. This leads us to what in my head I call the guess and check pattern: use a tool to automatically guess, edit and/or verify the result, and write that down as the definitive answer.

For example Gazelle updates Bazel BUILD files from Go source. Bazel then gets to run quickly without parsing Go source, and if Gazelle gets things wrong, you can still edit the files. As an additional benefit, you check the result in to source control, which means a human gets to see what actually changed, and it pins down the result.

For another example of this pattern, consider "lock files" as used in programming language package managers. When you npm add or cargo add etc., the tooling makes network requests, runs a complex algorithm to resolve what you meant, and writes down the result. Builds after this point can use the lock files without looking around on the network or guessing about versions.

I used this pattern in my Windows emulator projects. For any given Windows function I declare the emulator's version of the function in Rust. To automate writing out the function's matching argument list I can generate it from metadata published by Microsoft. But I only need that metadata when I run the generator, and the output doesn't need to be perfect! I can generate code that is most of the way there, because it's fine as a human to fix up the details after. The generator can even just make up type names that don't exist because the compiler will catch it afterwards.

Another way to look at this pattern is to see there's a chain of work to guarantee determinism atop a nondeterministc start: you can use a tool that makes a guess, and as long as you write down that guess and use deterministic steps from that written state onward you still have determinism in the result.

Which finally leads me to one way I've been tentatively experimenting with AI. AI behavior matches the shape I've been describing. An agent can do a long slow processing step and generate some output — not limited to code, even things like gathering data — as long as I write the output down as a result and have a human and/or tooling verification pass after. Keeping this pattern in mind has helped me find places where AI is suitable: problems where I know up front that a plausible guess is all I require, and that framing helps me keep in mind that the output is always just a guess.

(PS: just in case it wasn't obvious, my blog posts are always just me banging away on a keyboard, no clankers will keep me from my meandering!)

Version 3.0 of SvelteKit, the official application framework for Svelte, is now available.

If you’ve used earlier versions of SvelteKit, everything will feel very familiar — it’s the same framework with a little more polish, a little more type safety, and a little less junk. We’ve made migration as seamless as we can with the sv migrate command...

npx sv migrate sveltekit-3 --tasks all --confirm

...which will automatically migrate as much of your codebase as possible, and generate a TODO list for everything else. (If you’re agentically inclined, your robot friends will make short work of it.)

To create a new app, run sv create:

npx sv create my-new-app

As with any major version bump there are a handful of breaking changes to be aware of, which are covered in the migration guide (or, more briefly, in the recent release candidate announcement).

Quick highlights:

• configuration now lives in vite.config.ts instead of svelte.config.js
• the $lib alias is now #lib, making use of standard subpath imports
• environment variables are more powerful and easier to use
• service workers are less boilerplatey
• error handling is improved across the board

Are remote functions ready yet?

Not quite. But it’s our top priority!

Remote functions are a set of utilities for secure, efficient, type-safe client-server communication. You’ve likely seen some version of this idea in other frameworks, but we think you’re going to prefer this one.

Using them requires Async Svelte, which for now requires an experimental flag. Bear with us.

Join us in Ljubljana next month

This is as good a place as any to remind everyone that the next in-person Svelte Summit is taking place on November 19-20 in the lovely town of Ljubljana, Slovenia. Among other things it will be a celebration of Svelte’s 10th birthday, and we’d love to share some cake with you.

Links from the show