Windows 11's built-in Weather app holds more than 1 GB of RAM during ordinary use and climbs to roughly 1.5 to 1.6 GB while you interact with it. Testing by Windows Latest and Wccftech, reported on 9 August 2026, put hard numbers on something people had been grumbling about for a while. Apple's Weather app does the same job on macOS in about 250 MB.
On a machine with 8 GB of RAM, which Microsoft still sells Windows 11 into, a weather forecast is consuming close to a fifth of system memory.
RelatedNixpkgs core team disbands, citing steering committee friction
Why does a weather app need a gigabyte?
It does not, and the number is not really about weather. The app is an MSN Weather web experience wrapped in WebView2, Microsoft's embedded Chromium runtime. That single architectural choice explains the entire figure.
WebView2 does not run as one process. It follows Chromium's model: a browser process, a GPU process, a network service, a renderer per site isolation boundary, and utility processes as needed. Each carries its own heap and its own share of the runtime. You are not running a weather app, you are running a small browser that happens to only load one site. The advertisements embedded in the app are also live web content, with the DOM, script and image decoding that implies.
There is a floor to this that no amount of tuning removes. A WebView2 host pays for the Chromium runtime before it renders a single pixel of forecast, and that baseline is tens to low hundreds of megabytes depending on how many processes the isolation policy spawns. A native WinUI implementation starts from a different floor entirely, because the layout engine, the text stack and the compositor are already resident in the operating system and shared across every app using them. The gap between 250 MB and 1 GB is not a story about sloppy JavaScript. It is the cost of shipping a second rendering engine inside an application that had a perfectly good one available for free.
The counterargument is real, and it is why so many teams make this trade: one codebase serves the web, the desktop app and the widgets board, and it ships on whatever cadence the web team already runs. Memory is the currency that buys that convenience, and on a machine with headroom it is a fair price.
How the two apps differ under the hood
| Property | Windows 11 Weather | macOS Weather |
|---|---|---|
| Implementation | MSN web app in WebView2 | Native |
| Process model | Multiple Chromium subprocesses | Single app process |
| Typical memory | Over 1 GB | About 250 MB |
| Peak observed | 1.5 to 1.6 GB | Not reported |
| Embedded ads | Yes | No |
Roughly a five-to-one ratio for a feature set that is, from the user's side, close to identical: a forecast, an hourly strip, a radar map.
Is Microsoft going to fix it?
Unclear, and the signals point in two directions at once. Microsoft's stated direction for Windows 11 includes running well on lower-end hardware, and a bundled first-party app taking a fifth of an entry-level machine's memory works directly against that. Rudy Huyn, an executive on the Windows apps side, has said previously that the company intends to build more fully native Windows applications.
The complication is that Weather is not really a Windows app in the org-chart sense. It is MSN, and MSN is an advertising property. A WinUI rewrite would mean rebuilding an ad-supported web surface as a native client, and the incentive to spend that engineering budget is weaker than it looks from the outside. No commitment to rebuild the MSN-branded apps has been made.
RelatedGoogle Play Age Signals Goes Global: Inside the 4 Tiers
What you can do today
Check it yourself first. Open Task Manager, expand the Weather entry, and look at the subprocess list rather than the top-line figure. The child processes are where the memory actually sits, and that view also tells you whether the app is genuinely idle or quietly refreshing content in the background.
If the number bothers you, the app is uninstallable through Settings, Apps, Installed apps, and the same forecast lives on the web at no fixed memory cost. Turning off its background activity is the lighter-touch option if you want the widget behaviour to survive. On a 16 GB machine this is a rounding error and not worth acting on; on 8 GB it is one of the larger single wins available.
- Whether a WinUI rewrite is announced. That would be the real signal that the native-app commitment extends to MSN properties.
- Whether other bundled MSN apps measure the same. News and the widgets board share the architecture, and nobody has published equivalent numbers yet.
- WebView2 process sharing. Multiple WebView2 apps can share a runtime. Whether Microsoft uses that across its own bundled apps is a straightforward optimisation nobody has confirmed either way.
Our take
The number is embarrassing but it is not a bug, and treating it as one misses the point. Nobody shipped a memory leak here. Somebody made a rational decision that shipping one MSN codebase to the web, to Windows and to the widgets board beat maintaining a native client, and the memory cost was somebody else's problem, specifically the person who bought an 8 GB laptop.
That calculation is not unique to Microsoft, and the same trade has been made by nearly every desktop app that now ships a bundled Chromium. What makes this case worth writing about is that it is a first-party, preinstalled, ad-supported app on an operating system whose vendor keeps saying it cares about low-end performance. Those two positions cannot both be fully true, and the gigabyte is where the contradiction shows up.
- ReferenceWebView2 process model Microsoft's own documentation of the multi-process architecture
- TestingNotebookcheck report on the measurements Aggregates the Windows Latest and Wccftech figures
Original analysis by GenZTech. Measurements originally reported by Windows Latest.