macOS is the only OS you can write native applications for. On Linux there are with GTK and QT two different GUI frameworks that could be considered native on some distros. And on Windows there are so many different frameworks and approaches used by MS for the shell that even a Webview could be considered native

Win32 is the native way, MFC and Windows Forms build on top Win32, UWP is also native as thin layer above Win32 and COM (with some extras).

WPF is managed, only uses a bit of Win32 and DirectX 9, everything else is rendered by itself.

According to Microsoft WinUi3 and WinUi2 are also native https://learn.microsoft.com/en-us/windows/apps/winui/

Naturally, they build on top of UWP.

There are some details on what that exactly means, but I am on the go for lengthy comments.

None of which is used by for example the Office team, which maintains their own UI Framework just for Office.

Which itself is not used by Teams, which uses electron/WebView2, even though Teams is part of Office.

And let’s not forget about MAUI, which has its own components and UI library, which as far as I know is not used by anyone at Microsoft.

And I’ve heard from people at Microsoft that the future story of .NET UI framework is “Blazor WASM”. Is that considered native? Probably not. But I’d argue it should be considered “first party”.

Let’s be honest, Microsoft’s UI framework landscape is a mess.

Moving goalposts, the point was what are the native APIs.

Office framework would not exist without Win32, and usually it is made available on Win32, e.g. ribbon as common control.

Xamarin was never used at Microsoft, how to expect the rewrite to go any better. This acquisition was a mess, almost everything from Xamarin is gone.

Again, not a native API.

Blazor only matters for Web applications and PWAs, unless Windows turns into ChromeOS there is nothing native about it.

Blazor is only for web applications, until you run into Blazor Hybrid, which doesn’t produce web applications!

That is marketing gimmicks trying to get additional market share, and the current adoption failure of MAUI customers, as teams leave Xamarin ecosystem after the Xamarin.Forms to MAUI (incompatible) rewrite.

I give zero value to Blazor Hybrid, from my point of view it doesn't exist.

On macOS you now have to account for SwiftUI, which sometimes uses AppKit views and sometimes uses its own renderer. Kind of similar to UWP.

iOS and Android definitely have native toolkits too.

Pretty sure native as in "not web". AFAIK, everything is drawn using the various GPU APIs (GPUI started with Metal on macOS, for example).

I write both swiftUI and flutter daily. I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform. But in terms of language adaptability for UI, Swift is king.

> I think SwiftUI is the winner if we're going to put names forward. But arguably, not cross platform.

I must have a very different understanding of the word "arguably" than you. To me, it's arguable whether Swift itself is a viable cross-platform language today. SwiftUI, on the other hand, supports literally zero devices not manufactured by Apple.

Is it really arguable that when people say "cross plaform" when referring to a GUI framework, they aren't counting "both macOS and iOS, but not any of Windows, Android, Linux, web"? It might be accurate from an pedantic standpoint, but I have trouble imagining a context where someone would bother using that phrase as a qualifier if they understood it that broadly.

I would say the opposite and it sounds like a personal preference at which point I think lack of cross platform compatibility ceases to anything else other than a major major problem.

I didn't explain myself well. The point I was trying to make is the language of Swift is far more flexible than Dart. And in terms of UI implementation, it then looks a lot more like a DSL.

Because () are optional and a function call can look like this Button { stuff }. Meanwhile in dart, it's lines, and lines and indentation of 2 because it becomes a massive manuscript. I hope that makes more sense.

Rust's definitely well-suited to writing the low-level infrastructure pieces (the implementations of the renderer, layout, text, etc). You really want something with fast and predicatable performance there. Whether it pans out for writing actual applications we'll have to see, but a lot of big popular applications are written in C++ which is surely less suitable.

Yeah but sometimes you don't want to write connectors between high performance code and convenient to use UI code.

I welcome this, I want to write cross platform lightweight UI applications without going to C or C++.

I think it's native as in "native executable".

GPUI is not "native OS widgets".

Native as in "not web". No OS integration.