# UraniumUI for .NET MAUI: Material UI, Forms, and App Surfaces

> UraniumUI adds a Material presentation layer to existing .NET MAUI applications without replacing XAML, MVVM, Shell, handlers, or platform APIs. It is aimed at teams building business, admin, data-entry, and internal applications that need more application-ready UI than standard MAUI controls provide.

**enisn/UraniumUI** — The presentation framework for .NET MAUI.

- Repository: https://github.com/enisn/UraniumUI
- Website: https://uraniumui.gh.enisn-projects.io/
- Stars: 1,484 · Forks: 169
- Language: C#
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/enisn-uraniumui

## UraniumUI as a MAUI Presentation Layer

UraniumUI solves a specific problem in .NET MAUI: many applications need reusable application surfaces beyond basic labels, buttons, and layout primitives. The project describes its target users as teams building production line-of-business, admin, data-entry, and internal tools. Those applications commonly need consistent fields, validation behavior, data-heavy screens, modal surfaces, selection controls, and themes. Rebuilding those patterns separately across pages can produce inconsistent interaction and visual behavior.

The project does not replace the .NET MAUI application model. Its documentation explicitly says that developers continue using XAML, `ContentPage`, `Shell`, bindings, styles, resources, handlers, dependency injection, MVVM, and platform APIs. UraniumUI attaches controls and presentation patterns to that model. There is no required base `ViewModel`, proprietary navigation model, custom application layer, generated project structure, or new UI DSL.

That boundary is important for adoption. A team can use a single control, add a validation-aware field set, or adopt a larger Material presentation layer without converting the application into a different framework. The documentation presents incremental adoption as a supported approach. It also points to a full template, which is a different starting point for a new application.

The repository identifies `UraniumUI.Material` as the package for adding Material controls and `AutoFormView` editor mappings to an existing app. The core project is named `UraniumUI`, while the NuGet links include both `UraniumUI` and `UraniumUI.Templates`. This package split affects both installation and upgrade planning. Teams should first determine whether they need a template for a new project or the Material package for an existing one.

## Forms, Validation, and Data Screen Components

The main form mechanism is a pair of controls. `AutoFormView` generates editors from a model, while `FormView` handles validation, submit and reset behavior, busy state, and validation summaries. The documentation also lists InputKit validation, DataAnnotations integration, async validators, and property-path mapping. These features allow validation to be attached to generated fields or to fields written by hand, which reduces the need to reproduce validation display and submission state in every page.

The generated editor model is intended to remain extensible. The README says that developers can replace generated editors and customize templates. That matters because model-driven forms can save initial implementation work, but only if the generated output matches the layout and input behavior the application needs. A form with a small number of standard fields may be convenient; a form with conditional fields, unusual data entry, or specialized validation can require direct customization.

For data-oriented screens, UraniumUI lists `DataGrid`, `Paginator`, `TreeView`, `TabView`, `Select`, `Dropdown`, `CalendarView`, and Material input fields. The distinction is worth noting. `DataGrid` and `Paginator` address collection-oriented application screens, while `TreeView` and `TabView` address hierarchy and section navigation. `Select` and `Dropdown` cover selection workflows, but the accessibility section also calls out keyboard-aware behavior and semantic descriptions for supported controls. The project documentation therefore treats presentation and interaction quality as connected concerns rather than limiting itself to visual styling.

The repository includes a `demo/UraniumApp` directory. Based on the repository layout, that demo is the most concrete place to inspect how the controls are composed in an application, although the README does not document a command for building or running it.

## Dialogs, Bottom Sheets, and Visual App Surfaces

UraniumUI also targets the page-level surfaces that appear around application content. Its documentation names `IDialogService`, modal-page dialogs, Mopups, CommunityToolkit dialog providers, form dialogs, `BottomSheetView`, and `BackdropView`. This gives teams several interaction models instead of requiring every notification or selection flow to use a standard page navigation route.

The practical difference is architectural. Dialog and bottom-sheet components can represent transient tasks, confirmations, or focused forms while leaving the underlying page in place. `BackdropView` handles the background treatment associated with an overlay, and blur effects are available as part of the visual system. The README does not claim that all providers behave identically or that every platform supports every effect, so the integration choice still matters.

The project also includes theming resources: Material color and style resources, light and dark tokens, button variants, containers, dividers, elevation, icon packs, cascading styles, and blur effects. These resources sit above the MAUI primitives already used by the application. The documentation does not describe a mandatory global theme replacement. It says that styles can be overridden, themes can be created, and native MAUI APIs remain available.

For accessibility, the documentation specifically points to popups, dialogs, bottom sheets, `TabView`, `DataGrid`, date pickers, combo or autocomplete fields, validation messages, masked or formatted inputs, and custom clickable cards. That list is more useful than a broad accessibility claim because it identifies the control areas where interaction semantics and keyboard behavior need review.

## Installing UraniumUI in a New or Existing MAUI App

For a new project, the README gives a template-based installation path. The template command creates a starter application, while the blank template provides a lighter starting point. The item template is intended for generating a `UraniumContentPage` within an application named by `-na`.

The documented commands are:

```bash
dotnet new install UraniumUI.Templates
dotnet new uraniumui-app -n MyMauiApp
```

After the template is installed, the `uraniumui-app` template creates the named project. A lighter alternative is documented separately:

```bash
dotnet new uraniumui-blank-app -n MyMauiApp
```

The README says templates can configure icon packages, dialog integration, and blur support during project creation. It does not document interactive switch names for those options, so this article does not add any. The generated project should be opened in a MAUI-capable development environment, and the next step is to inspect its `App.xaml`, pages, and package references.

To add the framework to an existing MAUI application, the documented command is:

```bash
dotnet add package UraniumUI.Material
```

The documentation says that this package references the core `UraniumUI` package and configures Material controls and `AutoFormView` editor mappings. It then directs the developer to register UraniumUI in `MauiProgram.cs`:

```csharp
using UraniumUI;

builder
    .UseMauiApp<App>()
    .UseUraniumUIMaterial();
```

The README is truncated at the instruction to add Material resources in `App.xaml`, so the exact resource declaration is not available here. A developer following the official documentation should complete that registration step from the linked Getting Started documentation rather than infer a resource name or XAML merge instruction. No application build or runtime result is claimed here.

## Maintenance, Releases, and Apache-2.0 Implications

The repository is not archived. Its recorded last push was on 2026-09-29, and recent releases include `v3.0.0` on 2026-06-14, `v2.16.0` on 2026-05-28, and `v2.15.0` on 2026-03-15. The presence of multiple releases and a recent push indicate ongoing project activity in the documented repository metadata, but the README does not publish a compatibility matrix for each .NET MAUI workload or platform target. Upgrade planning therefore requires checking package compatibility in the target project rather than assuming that every release can be applied to every MAUI version.

The package organization creates a maintenance consideration. A new application created from `UraniumUI.Templates` may reference several packages or generated configuration, while an existing application using `UraniumUI.Material` also receives the core package transitively. A framework upgrade can therefore affect both package versions and project configuration. The repository includes `global.json`, `common.props`, `maui.common.props`, build scripts, and an Azure Pipelines definition, but the README does not describe a supported upgrade command for consumers.

UraniumUI is released under the Apache-2.0 license. The license permits use and modification under its terms, including distribution subject to the stated conditions. This is a repository and package licensing fact, not legal advice. Teams still need to review the license file and any dependency licenses separately before shipping an application. The README also links to the project documentation, NuGet pages, templates, demo application, and Discord community, but it does not promise a particular support response time.

## Where UraniumUI Is the Wrong Choice

UraniumUI is not a general replacement for every UI platform. Its value depends on an application already using .NET MAUI and accepting a presentation package built around MAUI primitives, XAML, and MVVM conventions. A team seeking a rendering engine with its own cross-platform drawing model would not find that model described in the repository.

It is also a poor match for projects that need very little UI. Adding packages, registering `UseUraniumUI()`, applying Material resources, and reviewing generated forms can cost more than it saves for a simple application with a handful of native controls. The framework's feature list is broad, but broad features also create more surface area to evaluate for accessibility, platform behavior, package upgrades, and visual consistency.

Model-driven forms and data grids can be unsuitable when application logic depends on highly specialized editors or when generated controls do not match the required data-entry flow. The documentation says generated editors can be replaced, so the limitation is a design trade-off rather than a hard prohibition. The relevant question is whether customization remains simpler than building those controls directly in XAML.

Compared with plain .NET MAUI, UraniumUI adds controls, resources, templates, validation mappings, and interaction surfaces. Compared with adopting a separate UI stack, it keeps the application in the MAUI model instead of requiring a new application architecture. That makes it a closer fit for incremental MAUI enhancement than for teams seeking independence from MAUI.

## Conclusion

UraniumUI is a practical choice for .NET MAUI teams that need forms, validation-aware inputs, data views, dialogs, and Material styling while retaining the standard MAUI application model. It is a poor fit for projects that need a fully independent rendering engine or that cannot accept additional packages, templates, and XAML integration work. Before adoption, verify the package version against the target MAUI project, inspect the generated controls in the demo app, and confirm that the documented accessibility behavior matches the forms and interactions required by the product.

## FAQ

### How do I install UraniumUI in a new .NET MAUI project?

Install `UraniumUI.Templates`, then use either `dotnet new uraniumui-app` or `dotnet new uraniumui-blank-app`. The README documents these commands for creating a new starter project.

### How do I add UraniumUI to an existing .NET MAUI app?

Run `dotnet add package UraniumUI.Material`, then register the packages in `MauiProgram.cs` with `UseUraniumUI()` and `UseUraniumUIMaterial()`. The README also instructs developers to add Material resources in `App.xaml`.

### Does UraniumUI require a custom ViewModel or navigation architecture?

No. The README says developers continue using standard MAUI features such as XAML, `ContentPage`, `Shell`, bindings, styles, handlers, dependency injection, MVVM, and platform APIs. UraniumUI does not require a proprietary application layer or custom navigation model.

## Sources

- [enisn/UraniumUI on GitHub](https://github.com/enisn/UraniumUI)
- [License: Apache-2.0](https://github.com/enisn/UraniumUI/blob/develop/LICENSE)
- [Project website](https://uraniumui.gh.enisn-projects.io/)
- [README](https://github.com/enisn/UraniumUI/blob/develop/README.md)
- [Releases](https://github.com/enisn/UraniumUI/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/enisn-uraniumui