SwiftUI for .NET — everywhere. Write declarative UI once in C# and render it as real native UI on every platform: SwiftUI on iOS/macOS/tvOS, Jetpack Compose on Android, GTK4 on Linux, WinUI 3 / WPF on Windows, and HTML/DOM on the Web — plus self-drawing backends (SkiaSharp, or a from-scratch WebGPU rasterizer) for a pixel-identical look anywhere, hosts for the MonoGame, Godot and Unity game engines, and a terminal backend for anywhere with a TTY and no display server.
This is the documentation set. Start with Getting Started, then read Architecture to understand how one C# view tree becomes native UI on every backend.
- Getting Started — install prerequisites, build the native bridges, and run the sample app on each platform.
- Architecture — the Core, the diff engine, the patch/event protocol, and the two backend routes (native shim vs. pure-C# interpreter).
- Hot Reload — edit a
Bodyand see it live underdotnet watch, withState<T>preserved across the reload. - Rider Plugin & Dev Tools — one run configuration per head with the host-OS gate, the live patch inspector, and the in-IDE Skia preview.
- Hosting & Dependency Injection —
SwiftProgram.CreateSwiftApp(), the builder,[Inject]services, view lifecycle, and theUseX()seam. - Views & Controls — the full vocabulary: layout, navigation & presentation (including alerts & action sheets), inputs, and display views.
- Modifiers, Gestures & Animation — the universal modifier pass, one-shot gestures, implicit animation, and multi-track keyframe timelines.
- State & Data Binding —
State<T>, two-way bindings, and the re-render loop. - Collection View (
List) — keyed identity, recycling, virtualization, selection, grids, sections, refresh, and load-more. - Global Styles — the environment cascade, control-style protocols, reusable
modifier bundles, and design tokens (
Theme). - Custom Controls — composite views (the common case) and custom native primitives via the renderer registry.
- The Controls Library — the
SwiftDotNet.Controlscompanion package, the imperativeDialogservice, what each control depends on, and the honest per-backend support matrix.
- Backends Overview — the platform matrix and the two rendering families.
- Apple — iOS / macOS / tvOS (SwiftUI)
- Android (Jetpack Compose)
- Linux / GTK (GTK4, pure C#)
- Linux / Wayland (self-drawn Skia on a native Wayland surface, no GTK)
- Windows (WinUI 3, pure C#)
- Windows / WPF (WPF, pure C#)
- Windows / WinForms (the Skia canvas — no native-control backend, by design)
- Web (Blazor WebAssembly → HTML/DOM)
- Skia (self-drawing SkiaSharp toolkit)
- WebGPU (self-drawing, from-scratch GPU rasterizer — no Skia)
- MonoGame (the Skia engine drawn into a
Texture2D, inside a game loop) - Godot (a
Controlnode drawn with Godot's own 2D renderer — no Skia) - Unity (the Skia engine drawn into a Unity
Texture2D) - Terminal / TUI (XenoAtom.Terminal.UI, pure C#)
- MAUI Interop — hosting SwiftDotNet inside a .NET MAUI app, and the
MauiViewnode that puts real MAUI controls back inside a SwiftDotNet tree, over the platform-view seam. (There is deliberately no MAUI backend.) - Maps — the opt-in
SwiftDotNet.Mapscompanion (MapKit / MapLibre). - Live Surfaces — the
SwiftDotNet.Live/SwiftDotNet.Widgetscompanions: iOS Live Activities and the Dynamic Island, home-screen widgets, Android custom notifications and app widgets, and Android 16 Live Updates. The first targets where another process renders our tree. - Roadmap — open design questions and planned work, indexed against
plans/.
| Platform | Renders as | Route | Status |
|---|---|---|---|
| iOS | SwiftUI | Swift shim (xcframework, P/Invoke) | ✅ Verified on simulator |
| macOS | SwiftUI (AppKit-hosted) | Same Swift shim | ✅ Verified on desktop |
| tvOS | SwiftUI | Same Swift shim (#if os(tvOS) fallbacks) |
✅ Verified on Apple TV sim |
| Android | Jetpack Compose | Kotlin shim (.aar, JNI) |
✅ Verified on emulator |
| Linux | GTK4 | Pure C# (Gir.Core, no shim) | ✅ Verified on desktop |
| Linux | Self-drawn on a native Wayland surface | Pure C# (libwayland/xkbcommon P/Invoke) | 🧩 Scaffolded — builds clean; never run against a compositor |
| Windows | WinUI 3 | Pure C# (no shim) | 🧩 Scaffolded — never compiled, no tests |
| Web | HTML/DOM | Pure C# (Blazor WASM, no shim) | ✅ Verified in Chrome |
| Any (Skia) | Self-drawn canvas | Pure C# (SkiaSharp) | ✅ Verified (macOS window, Silk.NET desktop, headless PNG, and iOS sim + Android emulator via the MAUI host) |
| Any (WebGPU) | Self-drawn, on the GPU | Pure C# (wgpu-native, no Skia) | ✅ Verified on Metal via headless pixel readback; Vulkan/D3D12 unexercised |
| MonoGame | Self-drawn into a Texture2D |
Pure C# (Skia engine + game component) | ✅ Verified — real window and back buffer on macOS/DesktopGL |
| Godot | Godot's own 2D draw commands (no Skia) | Pure C# (Control node) |
✅ Verified on Godot 4.7.2 (macOS/Metal), both rendering routes |
| Unity | Self-drawn into a Texture2D |
Pure C# (Skia engine + Unity host) | 🧩 Host compiles against UnityEngine reference assemblies; never run |
| Any (terminal) | Characters in a TTY | Pure C# (XenoAtom.Terminal.UI) | ✅ Verified headlessly on macOS (35 CI tests); not yet driven by hand in a live terminal |
| Live surfaces | Live Activities, notifications, widgets | Restricted DSL + a Swift widget interpreter / a C# RemoteViews interpreter | 🧩 Vocabulary, wire, validator & timeline ✅ verified headlessly (41 tests); both platform drivers compile but have never run |
The top-level
README.mdis the marketing/overview entry point; these docs are the reference. When they disagree, the docs are authoritative for detail and the README for the pitch.