Proposal: Build a next-generation native Windows UI framework for modern declarative UI and AI automation

Proposal: Build a next-generation native Windows UI framework for modern declarative UI and AI automation

Summary

WinUI is an important UI framework for native Windows application development. It provides Fluent Design controls, native Windows integration, and a XAML-based development model.

However, the broader UI ecosystem has clearly moved toward a new direction: state-driven, component-based, declarative UI. Frameworks such as SwiftUI, Jetpack Compose, Flutter, React, and Vue all reflect this trend.

At the same time, the AI era introduces new requirements for UI frameworks. Future software interfaces will not only be clicked and operated by human users, but also understood, navigated, and controlled by AI agents, automated testing tools, scripts, and system-level assistants.

Therefore, I suggest that Microsoft explore a new native Windows UI framework. It should not simply continue improving XAML, nor should it make compatibility with legacy frameworks its primary goal. Instead, it should be designed from the ground up for the next decade of Windows application development.

Motivation

XAML has served Windows development for many years and still has value, especially for existing WPF, UWP, WinUI, and enterprise applications.

However, the core model of XAML still reflects a previous generation of UI development:

• XML-based UI declaration
• Strong separation between markup and code
• Dependency properties
• Binding expressions
• MVVM as the primary architectural pattern
• Large object-based visual trees
• Complex resource, styling, and template systems

Modern UI frameworks have moved toward a more direct mental model:

UI = function(state)

In other words:

The interface is a function of state.

This model makes UI behavior easier to understand and is better suited for component reuse, UI logic testing, dynamic interface construction, and collaboration with modern tooling.

Windows needs a first-class native UI framework that adopts a modern UI development model while preserving the strengths of the Windows platform.

Core goals

The new framework should be designed around the following goals:

• Native Windows experience
• Modern declarative UI
• State-driven updates
• Component-based development model
• No dependency on XAML/XML
• High-performance native rendering
• First-class animation and transition system
• Fluent Design and modern theming
• Semantic model friendly to AI agents and automation tools
• Designed for new projects, rather than constrained by legacy UI framework compatibility

Design principles

1. Make state-driven UI the core model

The new framework should not treat data binding as an additional layer on top of controls. Instead, state should be the primary driver of UI.

Example direction:

View MyView(AppState state) =>
    VStack(
        Text(state.Title),
        Button("Save", onClick: state.Save)
    );

When state changes, the framework should automatically compute and update only the affected parts of the interface.

Developers should not have to manually maintain complex control-state synchronization, nor rely on large amounts of implicit binding expressions to connect UI and data.

A better model would be:

• State is explicit
• UI is a declarative expression of state
• Updates are handled automatically by the framework
• Side effects and user operations are expressed through clear actions or commands

2. Make component composition the primary development model

The framework should make components the basic unit of UI development.

Components should be:

• Easy to define
• Easy to compose
• Easy to reuse
• Easy to test
• Easy to refactor
• Built around clear input, output, and state boundaries
• Independent from XML markup files

Components should not merely be wrappers around controls. They should be a unified expression of interface structure, behavior, and semantics.

3. Move beyond XML/XAML-based declarative layout

The new framework should preserve the advantages of declarative UI, but it should not require XAML/XML.

UI structure should be expressible directly in the host programming language, such as C#, C++, or other languages that may be supported in the future.

Traditional XAML looks like this:

<StackPanel>
    <TextBlock Text="{Binding Title}" />
    <Button Content="Save" Command="{Binding SaveCommand}" />
</StackPanel>

A modern declarative code model could look like this:

VStack(
    Text(state.Title),
    Button("Save", onClick: state.Save)
);

This does not mean abandoning declarative UI. It means freeing declarative UI from XML.

This would enable better:

• Type checking
• Code navigation
• Refactoring
• Compile-time diagnostics
• Code generation
• State composition
• IDE IntelliSense
• Integration with modern language features

4. Preserve true native Windows capabilities

This framework should not be a WebView shell, nor should it primarily be another cross-platform abstraction layer.

Windows needs a modern but truly native UI framework.

It should provide:

• Native windowing integration
• Native input system support
• Native text rendering
• High-DPI support
• Complete support for touch, pen, mouse, and keyboard
• System theme support
• Accessibility support
• Windows animation and Composition capabilities
• Integration with non-UI capabilities from the Windows App SDK

The goal should be to approach the developer experience of SwiftUI, Jetpack Compose, Flutter, and React while preserving true native Windows behavior and performance.

5. Be C#-first while keeping a path for C++

A next-generation Windows UI framework should feel natural for C# developers first, while still keeping a reasonable path for C++ developers.

C# is a strong candidate as the primary development language because it supports:

• Strong typing
• async / await
• records
• pattern matching
• source generators
• LINQ
• strong IDE tooling
• Visual Studio and VS Code support

At the same time, the lower layers of the framework should consider C++ scenarios, especially for high-performance applications, system-level applications, creative tools, professional software, and game tooling.

6. Provide a first-class animation and transition system

Modern UI should not treat animation as an afterthought.

Animation should be part of UI state changes.

The framework should support:

• State-based transitions
• Layout animations
• Gesture-driven animations
• Shared element transitions
• Interruptible animations
• Page transition animations
• Component enter and exit animations
• High-performance animation based on the Composition layer

Developers should be able to declare how state changes, and the framework should handle the corresponding visual transitions automatically.

7. Provide a modern styling and theming system

The framework should support Fluent Design, but it should not recreate the complexity of the old XAML styling system.

It should support:

• Design tokens
• Light theme
• Dark theme
• High contrast theme
• Dynamic system accent colors
• Local component styling
• Global theme overrides
• Adaptive layout rules
• Runtime theme switching

The styling system should be closer to a modern design system, instead of relying primarily on resource dictionaries and control templates.

8. Do not make legacy framework compatibility a core goal

The new framework should not make compatibility with WinUI, WPF, UWP, or XAML its primary design goal.

In particular, I do not recommend prioritizing:

• Hosting WinUI controls inside the new framework
• Hosting new framework components inside WinUI
• Automatic XAML migration tools
• Legacy control model compatibility layers
• Deep compatibility with old resource and template systems

Although these compatibility features may appear helpful for migration, they can easily drag the new framework back into the limitations of older architectures. As a result, the new design may become constrained by historical baggage.

The new framework should primarily target new projects.

It should have a new:

• UI architecture
• State model
• Component model
• Rendering model
• Styling model
• Automation model
• Tooling design

Existing capabilities can still be reused outside the UI layer, such as:

• File system
• Window management
• Notifications
• Clipboard
• Input devices
• Application lifecycle
• System theme
• Permission model
• Non-UI capabilities from the Windows App SDK

However, the UI framework itself should remain clean, modern, and independent. It should not sacrifice long-term design quality for compatibility with old UI technologies.

9. Design for automation in the AI era

A next-generation Windows UI framework should consider AI agents, automated testing, script control, and system-level operations from the beginning.

Future software interfaces will not only be operated by human users, but also understood, navigated, and acted upon by AI assistants and automation systems.

Therefore, the framework should provide a structured, semantic, and predictable automation model, instead of relying on screenshot recognition, coordinate clicking, or fragile UI tree traversal.

Suggested capabilities include:

• Every component has clear semantic information
• UI state can be safely and structurally read
• User-executable operations can be exposed as explicit actions or commands
• Common interface patterns such as forms, lists, navigation, and dialogs have standard semantics
• Automation tools can understand what a button does, not just that a button exists
• AI agents can execute explicit operations under permission control
• UI tests can be based on component semantics and state, rather than pixel coordinates
• High-impact operations support confirmation, auditing, and undo
• Automation permissions are restrictable, traceable, and explainable

For example, a button should not only be a visual element:

Button(
    text: "Submit order",
    action: SubmitOrder,
    automationRole: "primary-confirm-action",
    automationDescription: "Submits the current order after validation"
);

With this model, an AI or automation system can understand that:

• This is a primary confirmation action
• It submits the current order
• It requires form validation first
• It may be a high-impact operation that requires user confirmation

This kind of capability should be a foundational part of the new framework, not something added later through accessibility APIs or testing frameworks.

10. Make UI easier for tools and AI to generate

A UI framework in the AI era should also be easier for tools to generate, analyze, and modify.

If UI is represented as a clear, type-safe, state-explicit, and semantically rich component tree, AI tools can more reliably:

• Generate interfaces
• Modify layouts
• Refactor components
• Add tests
• Check accessibility
• Generate automation scripts
• Explain interface structure
• Generate code from design files
• Optimize interactions based on user behavior

Compared with complex XAML resources, implicit bindings, and scattered code-behind logic, modern component-based UI is much better suited for AI-assisted development.

Why this matters

Windows has excellent native platform capabilities, but its UI development experience does not feel modern enough compared with other ecosystems.

Many developers choose Electron, Tauri, Flutter, or React Native today not because they are more native, but because they provide a more modern and productive UI programming model.

If Windows wants to make native application development attractive again, it needs a truly modern native UI framework.

This framework should combine:

• Native performance
• Fluent Design
• Modern declarative UI
• State-driven updates
• Component-based architecture
• Strong tooling
• Excellent accessibility
• Semantic model friendly to AI automation
• A clean new architecture, not a legacy compatibility layer

Suggested outcome

I am not suggesting that WinUI should be immediately deprecated.

Existing WinUI, WPF, and UWP applications can continue to be maintained, and legacy projects can continue using the existing technology stack.

However, Microsoft should start a public design exploration for a truly modern native Windows UI framework aimed at new projects.

Possible next steps include:

1. Publish a design exploration for a next-generation native Windows UI framework.
2. Make it clear that the framework does not center on XAML compatibility or legacy control hosting.
3. Prototype a C#-first declarative UI layer.
4. Design a state-driven component model and rendering model.
5. Design a semantic UI model for AI agents and automation tools.
6. Explore integration with non-UI capabilities from the Windows App SDK.
7. Define a long-term technical direction for native Windows UI development after XAML.

Windows should have a modern native UI framework.

Its developer experience should be as productive as SwiftUI, Jetpack Compose, Flutter, or React, while remaining deeply integrated with the Windows platform and ready for the AI automation era.

Why is this important?

make windows great again.

Steps to reproduce the bug

make windows great again.

Actual behavior

No response

Expected behavior

No response

Screenshots

No response

NuGet package version

windows 11

Windows version

No response

Additional context

No response

This is a broad framework proposal and names no implementation files, tests, or entry points. Start by reviewing the existing WinUI architecture and narrowing the proposal to a specific component or design decision; completion would require an agreed scope, implementation plan, and acceptance criteria.