Windows apps need a feel budget

A native app promise is easy to say and hard to feel. Users usually do not care whether a window is WinUI, WebView, PWA, Electron, or something else. They care that the app opens quickly, keeps the keyboard path intact, respects the file system, and does not make a simple action feel heavier than it was last year.

That is why the current Windows native-app push is worth tracking. Microsoft is publicly steering more work toward WinUI 3 and native Windows experiences, while coverage around built-in apps keeps pointing at the same pain points: performance, memory use, responsiveness, and consistency. The useful lesson is not "native good, web bad." The useful lesson is that a platform promise needs a feel budget.

A feel budget is the small set of things the app must make lighter before the rewrite deserves the word native. Start with cold launch and warm launch. If a default app takes long enough that the user checks whether they clicked, the implementation has already lost trust. Then check memory after one simple task, not after an artificial benchmark. A notes app, recorder, camera, or photo viewer should not behave like a full browser session when the user only wanted one file.

Keyboard flow is the second test. Native desktop software earns trust when tab order, accelerators, copy/paste, context menus, drag and drop, and focus recovery feel boring. Boring is the goal. If the mouse path works but the keyboard path breaks, the app may look modern while becoming worse for repeated use.

System integration is the third test. File open and save dialogs, jump lists, notifications, share targets, default app handling, high-DPI scaling, pen and touch behavior, and accessibility APIs are not decoration. They are the reason people expect a desktop app to feel like part of the operating system. A shared-code app can absolutely pass these tests, but it has to pass them explicitly.

There is also a fair counterargument. Shared web code is often the only way a small team ships across Windows, macOS, Linux, and the browser without splitting its roadmap into four products. A rewrite can burn months and still produce a slower app if the team only changes the toolkit. Native investment is strongest where the app is default, frequently opened, file-heavy, input-heavy, or trusted as part of the system.

For Windows users, the practical question is not "is this native?" It is "which task became lighter?" If the answer is launch time, memory, keyboard flow, file handling, or accessibility, the label has substance. If the answer is only a framework name, the promise is still unfinished.

A reusable checklist:

- Measure cold launch and warm launch separately.
- Record memory after one normal task.
- Test the full keyboard path, including focus recovery.
- Check file dialogs, drag and drop, notifications, and default app behavior.
- Verify high-DPI, touch, pen, and screen reader paths.
- Name the user task that got lighter.

Native means the task feels lighter.

Windows apps need a feel budget

// COMMENTS

ON THIS PAGE