# Uno Platform: WinUI 3 XAML on iOS, Android, Web, Desktop and Embedded

> Uno Platform lets a single C#/XAML codebase target Windows, macOS, Linux, iOS, Android, WebAssembly and embedded framebuffer devices. Here is how the rendering split works, how to get a first app running, and where the approach costs you.

**unoplatform/uno** — Open-source platform for building cross-platform native Mobile, Web, Desktop, and Embedded apps from a single C#/XAML codebase. Work from any IDE/CLI with Hot Reload, Visual Designer, MCPs, and Skills built for modern .NET workflows. 200M+ NuGet downloads. Desktop (Windows, macOS & Linux): Uno Platform uses Skia for rendering across all desktop platforms, ensuring high-performance, hardware-accelerated graphics and a

- Repository: https://github.com/unoplatform/uno
- Website: https://platform.uno
- Stars: 10,058 · Forks: 888
- Language: C#
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/unoplatform-uno

## What Uno Platform actually solves for a .NET team

The problem is not "write once, run anywhere" in the abstract. It is that a team with C# and XAML experience, usually coming from WPF or UWP, wants to ship to iOS, Android, WebAssembly and Linux without maintaining four UI codebases in four languages. Uno Platform's answer is to implement the WinUI 3 API surface on top of each target platform. Your XAML is not transpiled into Swift or Kotlin. It is parsed by Uno's own implementation of the WinUI controls and layout system, which then draws or delegates to the platform.

The audience is therefore narrow and specific: .NET developers who already know XAML, and organisations with existing WinUI or UWP assets they want to carry forward. The README states the platform is used by enterprise clients including Toyota, Microsoft and Kahua, and that it has over 300 contributors. Those are the project's own claims; treat them as positioning rather than independent evidence. The licence is Apache-2.0, which matters more than the client list for most adoption decisions.

If your team has no XAML background and no .NET investment, the value proposition largely evaporates. You would be learning a Microsoft UI framework to write an app that could have been written in Flutter or React Native with a larger hiring pool.

## Two rendering paths, and the trade-off between them

The README describes two rendering methods, and choosing between them is the single most consequential architectural decision in a Uno project.

Unified Skia Rendering draws your UI onto a Skia canvas. The same drawing code runs on every target, so layout, text metrics and animations behave identically. On desktop the README is explicit about the shells: Skia runs inside a Win32 shell on Windows, an AppKit shell on macOS (Metal when available), and an X11 shell on Linux or directly to the framebuffer for embedded scenarios. The payoff is consistency and hardware-accelerated graphics. The cost is that your app looks like itself everywhere, not like an iOS app on iOS.

Native Rendering translates XAML into the platform's own controls, with UIKit on iOS given as the example. You get the platform look and feel, and you inherit the platform's accessibility and text input behaviour more directly. You also inherit the differences: a control that behaves one way on Windows may behave differently on iOS, and you will be debugging against two rendering backends if you mix the modes.

The practical consequence is that "single codebase" does not mean "single behaviour". It means one set of source files and one build graph. The rendering decision is per-target and should be made early, because retrofitting it after the UI is built is expensive.

## Installing the toolchain and running a first app

The README's Quick Start has three steps and points to the official documentation for detail. The first step is environment setup through a command-line tool called Uno.Check, which the README says checks, installs and configures required workloads and dependencies. The exact invocation is not given in the README, so check the get-started documentation for the current syntax before running anything.

The second step is project creation, either through a Template Wizard inside Visual Studio, Rider or VS Code, or from the command line. The README names the template mechanism but does not print the command, so the template package name and its parameters should be taken from the documentation rather than guessed.

The third step is build and run. Because the README truncates before showing the commands, the honest position is that this article cannot give you a verified command line. What can be stated is the shape of the workflow: the build produces a native application package per target platform, and the platform heads are part of the repository layout under `src/`.

For orientation, the repository's top level contains `global.json`, `Directory.Build.props`, `NuGet.Config` and `version.json`. Those files tell you the SDK version the project pins and how NuGet feeds are configured, which is useful if you are building Uno itself rather than an app on top of it. If you only consume the NuGet packages, your own project controls those settings.

The dev loop is where the project invests most: Hot Reload modifies XAML and C# on a running app without losing state, and Hot Design turns the live app into a design surface. Both are documented features, not guarantees about your specific project's reload coverage.

## Where Uno Platform is the wrong choice

The clearest failure mode is scope mismatch. If you are building a Windows-only desktop tool, Uno adds a compatibility layer, a second rendering backend and a set of platform heads you will never build. A plain WinUI 3 or WPF application is simpler and has fewer moving parts.

The second case is teams that need platform-idiomatic UI as a hard requirement. Native Rendering can approximate it, but the README frames Skia as the path to consistent visuals, and consistency is the opposite of idiomatic. If your designers hand you a UIKit specification and expect it reproduced exactly, you are fighting the abstraction.

The third case is dependency risk. The README lists supported libraries and third-party vendors, which implies that not every .NET UI library works. A control you depend on may have no Uno implementation, and the README does not document a general escape hatch for arbitrary WinUI controls beyond the supported list. Verify your specific controls before you commit.

Finally, WebAssembly targets inherit the .NET WebAssembly runtime's characteristics. The README links to the .NET Runtime WebAssembly SDK rather than describing its performance profile, so any claim about web startup time or payload size should be measured on your own app, not assumed.

## Uno Platform compared with Avalonia

The comparison people search for is Uno Platform versus Avalonia, and the difference is architectural rather than cosmetic.

Avalonia defines its own UI framework and its own XAML dialect. It is not trying to be WinUI. That means its API is designed once, for cross-platform use, without carrying Microsoft's historical decisions. Uno Platform takes the opposite route: it implements the WinUI 3 API surface, so existing WinUI and UWP knowledge transfers, and Microsoft's control set is the reference. The README states this directly, describing the platform as using the WinUI 3 API surface so existing C# and XAML skills carry over.

The practical difference shows up in migration. If you have a UWP or WinUI codebase, Uno's compatibility goal is the reason to pick it. If you are starting fresh and have no Microsoft UI heritage, Avalonia's self-defined API has fewer constraints to work around, because it never promised to match another framework's behaviour. Neither is universally better; the deciding question is whether WinUI compatibility is an asset or a liability for your project.

Both are Apache-2.0-style open source .NET UI projects, so the licence is not the differentiator here. The API surface is.

## Maintenance cadence, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-06. Recent releases in the 6.6.x line include 6.6.184 on 2026-08-06, 6.6.176 and 6.6.166, both dated 2026-07-30. That is a fast patch cadence within a minor line, which is typical for a UI framework that has to track platform SDK changes from Apple, Google and Microsoft.

The upgrade cost is the part teams underestimate. Uno tracks the WinUI 3 API surface and .NET SDK versions, so a .NET major upgrade or a new iOS SDK can force a Uno upgrade, which can in turn change control behaviour. The repository pins its own SDK through `global.json` and centralises build settings in `Directory.Build.props`, which is a signal that the project manages its toolchain tightly. Your application should do the same, because floating on the latest Uno package while your .NET SDK lags is a common source of build breakage.

On licensing: the core framework is Apache-2.0, and the repository carries `License.md` and `THIRD-PARTY-NOTICES.md`. Apache-2.0 permits commercial use and modification, and includes a patent grant. The README separately describes Uno Platform Studio as a productivity suite with components such as Hot Design, the Studio App and the Studio Agent, and those are distinct from the open-source core. Whether the Studio components carry the same licence is not stated in the README, so check their own terms before assuming they are covered by the Apache-2.0 grant. This is not legal advice; review the actual licence files for your use case.

## Conclusion

Uno Platform fits teams that already have C# and XAML skills and need one codebase across mobile, web, desktop and embedded targets, particularly where WinUI 3 API compatibility matters. It is the wrong tool if you want a small, single-target desktop binary or you are unwilling to depend on the WinUI 3 API surface and its Uno-maintained compatibility layer. Before committing, verify three things: that your target platforms are covered by the current supported list, whether your UI needs pixel-identical Skia rendering or native controls on each platform, and that the third-party control libraries you rely on appear in the supported libraries list. The last push to the repository was on 2026-08-06, so check the release notes for the version you pin.

## FAQ

### Is there a cross-platform UNO game?

The repository is Uno Platform, a .NET UI framework, not the card game, so this question does not apply to it. Nothing in the README or repository layout describes a game implementation.

### What is platform UNO?

Uno Platform is an open-source developer platform for building single-codebase .NET applications that run natively on Web, Desktop, Mobile and Embedded systems, using the WinUI 3 API surface. It lets developers reuse C# and XAML skills across those targets.

### Is the Uno platform free?

The core framework is described in the README as free and open source under Apache 2.0. Uno Platform Studio is presented separately as a productivity suite, and the README does not state its licensing terms.

### What is .NET cross-platform UI?

In this context it means building a user interface once in .NET and running it on multiple operating systems. Uno Platform does this by implementing the WinUI 3 API surface on each target, rendering either through a unified Skia engine or through native platform controls.

## Sources

- [Official documentation](https://platform.uno)
- [Official README](https://github.com/unoplatform/uno#readme)
- [Project repository](https://github.com/unoplatform/uno)
- [Release notes](https://github.com/unoplatform/uno/releases)

---

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