.NET UI when the interface must support work instead of slowing it down

.NET UI: which technology for which problem

The .NET UI ecosystem is rich and sometimes confusing: WPF, Windows Forms, Blazor, .NET MAUI, Avalonia.

Each framework has a primary use case and contexts where it is not the right choice.

Using them without this criterion produces applications that work but cost too much to maintain or that do not satisfy real requirements.

WPF is the choice for Windows desktop applications with rich interfaces, complex bindings, and vector rendering. It is mature, stable, and has the best support for Windows-only enterprise scenarios. It is not cross-platform.

Windows Forms remains valid for simple desktop applications with teams that know it well. It does not have WPF's rendering capabilities, but for data entry forms, grids, and internal workflows it is productive and easy to maintain.

.NET MAUI is the choice for applications that need to run on iOS, Android, Windows, and macOS with a single .NET codebase. It is younger than the others and still has aspects to mature, but for .NET teams that need to cover multiple mobile platforms it is the most consistent choice with the existing stack.

Blazor is the choice for interactive web interfaces written in C#. Blazor Server and Blazor WebAssembly have different execution models with different trade-offs on latency, offline support, and scalability.

Designing a UI that helps work: the principles that change products

A technically correct UI that users find difficult to use is a failure.

There is no point in implementing MVVM perfectly if the workflow the interface supports requires ten clicks to do something that took two in the previous version.

The fundamental principle is that the interface must model the user's work, not the system's data structure.

The difference is subtle but decisive: a system that exposes its entities (Customer, Order, Product) as separate screens forces the user to build context in their own head.

A system that exposes tasks (Manage customer order, Process return) reduces friction because it matches how the user thinks about their work.

State management is the second critical principle: how much state must the interface maintain, where is it saved, what happens if the user accidentally closes it.

In a complex desktop application, losing unsaved data is a UX problem before it is a technical one.

Immediate feedback on long operations is not a detail: it is the difference between an interface that feels responsive and one that feels stuck.

Progress indicators, cancellable operations, asynchronous updates: these are investments that users notice and appreciate even without being able to name them.

.NET MAUI and cross-platform: when it genuinely works

The promise of cross-platform is write the code once and run it everywhere.

The reality is more nuanced: the business logic code is truly shared, but the UI requires attention to platform differences because iOS and Android have different navigation paradigms, keyboard handling, and visual styles.

.NET MAUI handles these differences with the concept of native renderers: MAUI controls are rendered using the native controls of each platform.

The result is an application that feels native on each operating system, but that requires testing on each platform because behavior can differ in the details.

The cases where MAUI delivers maximum value are internal enterprise applications where cross-platform visual consistency matters less than team productivity and reuse of existing .NET business logic.

The cases where it should be evaluated more carefully are consumer applications where adherence to iOS or Android native conventions is a market requirement.

MAUI's Shell simplifies navigation and application structure.

Lifecycle, permissions, and hardware access (camera, GPS, sensors) all require platform-specific handling even with MAUI.

Accessibility and performance in .NET UIs: these are not optional

Accessibility in desktop and mobile applications is not an optional requirement for specific niches.

It is a legal requirement in many enterprise and public contexts, and an indicator of product quality.

In WPF, accessibility is built with AutomationProperties, which provide the text that screen readers convey to visually impaired users.

In MAUI every control has accessible semantic properties.

In Blazor the same web ARIA rules apply.

They do not require a large investment if integrated from the start; they require expensive refactoring if added at the end.

UI performance is measured differently from backend performance: the goal is perceived fluidity, not throughput.

An operation that takes three seconds but shows a progress indicator is perceived as more responsive than one that takes one second but blocks the interface.

The UI thread must never be blocked by I/O operations or CPU-intensive processing: everything that is not a direct control update must run on separate threads with async/await or Task.