A while ago I posted StateUI here as an experiment: Swift for the UI, with .NET MAUI underneath providing the controls on each platform. It worked, but every change had to cross into C# as a binary patch, and an app's own native views had to go through another runtime. So I dropped MAUI to get better performance and simpler interop, and every platform now has its own native host written in Swift. The host reads typed patches directly, in the same process, and an app's own native views - an MTKView, a GtkGLArea, a Direct3D SwapChainPanel - plug in straight from Swift.
You write an app's interface once in Swift, and each platform draws it with its own controls: AppKit on the Mac, UIKit on iPhone and iPad, Android Views, WinUI 3 on Windows and GTK 4 with libadwaita on Linux.
That's the same Gallery app, one Swift module, on four of them. There's no custom renderer and no web view. A button is an NSButton, a UIButton, an Android Button, a WinUI Button or a GtkButton.
How it works: Swift owns the UI tree, the state, the diffing and the animation. Each platform has a thin host, also written in Swift and running in the app's own process, that applies sparse patches to the native controls. On Android the host reaches Java through JNI, and on Windows it reaches WinUI through a small C++/WinRT layer, but the logic stays in Swift.
The same sample uses each platform's own graphics API: Metal on macOS and iOS, Direct3D 11 on Windows, OpenGL on Linux and OpenGL ES on Android.
Every host runs the same conformance suite, and the platform matrix in the repo is generated from those test runs. So it shows what actually works on each platform, not what I hope works. Not everything is covered everywhere yet, and the matrix says exactly where.
It's pre-1.0, and the API still changes when a platform shows me a better model. It needs Swift 6.4. Apache 2.0.
https://github.com/idexus/StateUI
I'd love to hear what you think, especially from anyone who's tried shipping Swift outside Apple platforms.