Using existing WinUI controls with Maui for cross-platform desktop apps

[praneetloke]

Disclaimer: I am a newbie when it comes to Windows desktop app development. I know nothing about UWP, WPF, WinUI. They are all just acronyms to me.

As the title states, I am looking for clarification on what, as a developer, can I do with this platform? I was assuming that it was the Electron-equivalent for the dotnet world but without embbeded webview being the renderer and instead, the app would run native to the respective platform using any control from the WinUI library. Instead, it seems that that is not true (at least that last part)? For instance, I was thinking I could use any control from the WinUI3 library and it would "just" work the same way regardless of the platform, but that doesn't seem to be the case? For example, I tried using a NavigationView and other controls showcased in the WinUI3 gallery app but VS (VS 2019 Community 16.11 Preview 1) can't find any of those controls. Is this just a limitation of the preview right now and the plan is to support all controls from the WinUI library for all platforms? Or am I grossly misunderstanding how this all works?

FWIW, I read the FAQs in this repo and it seems most, if not all, questions are geared towards developers who are well-aware of the development ecosystem surrounding UWP, Xamarin.Forms, WinUI, WPF etc. I have zero experience working with those. I am sort of thinking that Electron is still truly the best cross-platform desktop platform out there, even though it uses an embedded webview-based rendering and there are some cons related to its use of embedded webviews and the packaging mechanism. But at least it "just" works.

[dansiegel]

@praneetloke the question you pose is pretty broad, and potentially open to a certain amount of subjective opinion here, but I'll try to help give you some info that may help you understand this a bit better from a high level.

WPF & UWP are pretty tightly coupled Windows application development frameworks. UWP in particular not only requires the user to be on Windows 10 but on a new enough service release to what you've built for. One of the chief benefits to something like WinUI for those developers in the WPF/UWP world is that it really lets the frameworks introduce new things where they may not have been able to previously due to limitations caused by the tighter coupling with the OS. Without getting into the weeds here... WinUI by itself still is going to constrain you desktop development for Windows.

Maui on the other hand is the evolution of Xamarin.Forms. The code base is largely based (and started from) Xamarin.Forms 5. This means that you have an application framework for building Native Apps. You ultimately have the ability here to get into very platform specific code as much or as little as you want/need. For example you could simply only ever care about the Maui abstracted control of a Label, however you could interact directly with the underlying UILabel on iOS or the TextView on Android.

Where perhaps some confusion may be coming from may be the Experimental Mobile Blazor Bindings. It's perhaps certain models of this where you are truly utilizing WebUI within the Maui app where I think your comparison to Electron is most accurate. As a consultant in this space I would be extremely unlikely to suggest this or give a client any guidance besides rip it out of your code. However I do understand that if you already have skills with Blazor this is likely a very appealing way to bring your skills over to be able to see code you wrote running outside of a Browser on Desktop and Mobile.

[praneetloke]

Thanks, @dansiegel. Your comment cleared up a few things for me! My confusion isn't so much from the comparison to Electron. I just used Electron as an example it seems to be the most prominent desktop app development framework right now. I know there are others, though, and specifically, Flutter and Jetpack Compose for Desktop from JetBrains run natively rather than using an embedded webview.

My confusion is actually about what Maui is trying to solve and what does using it buy for a developer looking to develop cross-platform desktop apps? It seems that with the lack of out-of-box rich controls, as a developer I would need to develop the controls myself if I want to go beyond the basic input controls that Maui offers? If that's the case, why wouldn't someone just use Electron and package a web-based app easily that has a very rich ecosystem, or even Flutter, if you don't mind using Dart as a language.

When I first came across Maui I was excited that I could use C# to make desktop apps and use any of the controls offered through WinUI3 library but I am sad to see that that isn't the case.

[praneetloke]

I forgot to mention that I checked out Uno and have been playing with it. Its promise seems to be that you can use UWP controls for developing cross-platform apps. I have had some success with a prototype but the development environment is quite messy. One wrong move and things seem to break for me. It feels fragile. But again, it could very well be my fault and not knowing enough about the UWP ecosystem in general.

[dansiegel]

As I said this is the Evolution of Xamarin.Forms which has been around for years and powers many thousands of apps. There is a rich ecosystem of controls and tools that help you deliver high quality beautiful apps. In fact Telerik already has introduced support for their existing UI Libraries for Maui. Remember that Maui is still an early preview, so many 3rd party libraries either haven't had a chance yet to release packages for Maui, or are waiting for a later preview.

why wouldn't someone just use Electron and package a web-based app easily that has a very rich ecosystem

Developers constantly want to cheat and use Web apps as desktop and Mobile apps... the simple truth that web developers never like to hear is that the UI's do not produce results as a Native app that results in the good user experience that the everyday user appreciates. This results in lower adoption, greater dissatisfaction, and bad reviews in the App Store. Also look at Javascript dependencies... it's a joke that results in ridiculous download sizes. As for ecosystems... you might check out nuget.org and search "xamarin", "xamarin.forms", etc... you'll find thousands of packages available many with millions of downloads... some of those packages have already started making the Maui migration (ones that target native iOS/Android don't really even need to change anything), and others will be making the migration by the time Maui is out of Preview.

or even Flutter, if you don't mind using Dart as a language.

In many ways Maui takes some lessons from Flutter in addition to the lessons learned from the first 5 versions of Xamarin.Forms and @Clancey's Comet. Maui does have a distinct advantage IMO being that you're not actually bouncing between languages when you need to get into the Native code.

... I checked out Uno and have been playing with it.

Uno is a great alternative for those who may be coming from a Desktop background with UWP/WinUI. In many ways Uno is very similar to Xamarin.Forms/Maui in that it is ultimately providing a UI abstraction to build native apps. The advantage for those developers is that they can continue to just write a UWP/WinUI app and have it just work on Mobile targets, MacOS, Linux and WASM. Ultimately though for the purposes of looking at the .NET 6 timeframe, whether you use Maui or Uno you'll still be building on top of pieces of what we call Maui since this includes Microsoft.Maui.Essentials which you might be using to do things like Geolocation, get the App Version, etc.

[praneetloke]

I couldn't agree more with you on the cheating/shortcut mentality when it comes to making cross-platform mobile apps. Although, I do think in the desktop space it is somewhat less of a problem. I mean, VS Code is probably one of the best examples of a well-executed Electron-based desktop app. Like it, there are many others too.

some of those packages have already started making the Maui migration (ones that target native iOS/Android don't really even need to change anything), and others will be making the migration by the time Maui is out of Preview.

Yep I saw that Telerik has a preview of their library, but it is a free trial. I actually came across that from the MS Build 2021 blog post about Maui. (I am closely following the developments of Maui.) FWIW, I also came across https://github.com/dotnet/Microsoft.Maui.Graphics.Controls which looks promising but it is early to tell which path it'll take.

Uno is a great alternative for those who may be coming from a Desktop background with UWP/WinUI. In many ways Uno is very similar to Xamarin.Forms/Maui in that it is ultimately providing a UI abstraction to build native apps. The advantage for those developers is that they can continue to just write a UWP/WinUI app and have it just work on Mobile targets, MacOS, Linux and WASM.

Yeah I am actually taking a fresh look at Uno today now that I have a slightly better understanding of things. I think my problem also was that I was mixing UWP and WinUI in Uno and just was not having a good time. I am hoping to get a fresh start and incrementally build something out. Uno does look promising and they also have a Linux story whereas Maui hasn't quite got a roadmap for that. For what I am building, I want to target the 3 main desktop platforms, i.e. Linux, macOS and Windows.

Ultimately though for the purposes of looking at the .NET 6 timeframe, whether you use Maui or Uno you'll still be building on top of pieces of what we call Maui since this includes Microsoft.Maui.Essentials which you might be using to do things like Geolocation, get the App Version, etc.

Oh interesting... I am learning something new with each of your replies 😄

[GeraudFabien]

This is how i would explain it (I was writing it but cannot found a answer to one of you're question)

I was assuming that it was the Electron-equivalent for the dotnet world but without embbeded webview

Maui has nothinks to do with electron. Electron offer a way to pack WebUI into desktop application. It can be back by many language since but mostly web language and no native control (It's not impossible to do but it's not the goal).

• WPF, UWP : You can thinks of it has windows native control.
• WinUI : It's an extention of UWP and WinUI but package with your app. This way you are not dependent of the version of windows used by you're client.
• Xamarin.Form : It's a cross plateform UI framework based on Mono (One of the .net implemenetation) for mobile developpement. One of the core idea behind Xamarin is to share the logic but for the UI you will make one UI for each plateform. You can make cross plateform UI but it was not how it was thinks.
• MAUI : The same than xamarin but will bring desktop.
• MAUI+Blazor: Blazor use MAUI to package the application to desktop and mobile. In this case Maui look like Electron.

Some part to understand :

• Maui use WinUI
• MAUI + Blazor : Use html have a back in C#, work everywhere and share 100% of the UI.
• Maui equivalent are UNO Plateform, Flutter and ReactNative. Electron is realy a tool to package web application to desktop and mobile. It's not a UI framework.
• Xamarin.Form : It's the old name of MAUI

was assuming that it was the Electron-equivalent for the dotnet world but without embbeded webview being the renderer and instead

You can do webview in maui if you want (See my MAUI + Blazor comment).

cross-platform desktop platform

I'm not sure i understand what this mean

But at least it "just" works.

You say you don't know but you seem to have already done you're judgement.

Is this just a limitation of the preview right now and the plan is to support all controls from the WinUI library for all platforms? Or am I grossly misunderstanding how this all works?

For your main question. I'm sorry i don't know.

For what you can do with each :

• UWP, WinUI, WPF : Windows only (IOT, hololens , Xbox, and other may be include if not windows and framework and device are recent enough)
• MAUI : Android, Mac, IOS, Windows, Tizen, (Linux ?) Native or not
• Blazor : Android, Mac, IOS, Windows, Tizen, (Linux ?), Web not native (HTML based)

[praneetloke]

@GeraudFabien thank you for the reply with details! I realize Maui has nothing to do with Electron. Electron was just an example I used as another cross-platform desktop app development framework. Electron's motive is clear: to allow developers to leverage web technologies to build apps and to package, and distribute them as desktop apps. It's sort of like what Cordova/PhoneGap did for mobile apps. So what is Maui's story? Is Maui eventually going to offer more cross-platform UI controls beyond just the basic controls? I guess I started digging into Maui expecting a bit more than what it supports today and maybe ever? I guess one could compose the basic elements to create an cross-platform app like they showcased with the WeatherTwentyOne app at MS Build this year. There is a lot of reference to WinUI3 and Project Reunion associated with Maui that I was misled (probably on my own) into thinking that I could uses WinUI3 controls to develop desktop apps with Maui that will work across platforms.

I did checkout Uno by the way. But honestly, I have not had the best experiences of doing daily development with it. It is a hit or miss as far as keeping a stable working environment for me. Have you used Uno?

[GeraudFabien]

I tried it. But i more interest in blazor recently.
I have no time to really try it correctly so i can't say much. The small app i tried work but that all.

WinUI3 is new. Again i can't find enougth time to know the answer. But if you look at WeatherTwentyOne it work on IOS, Android, Mac and windows and share the UI so it can't use WinUI for most of the UI. You can look at the source if you want to understand how they use it. But has i understand it. It's more a target.

[praneetloke]

After trying many things with Uno too, I decided to give up on using C# for cross-platform native desktop apps for the time being. The platform maturity and tooling just isn't good enough for my taste. Maybe once Maui has had a year or two out in the wild, it could be a formidable cross-platform desktop framework. For now, I just can't see anything better than using Electron that is a complete package for developing cross-platform desktop apps. It's a shame Uno didn't work out for me because it actually does work the way I thought Maui would. Maybe one day Maui would replace Uno.

[francoistanguay]

@praneetloke Not to hijack this thread but if you had issues with Uno or the underlying VS/Runtime environment, we'd love to hear more about it. You can reach us on Discord, on Twitter DMs or via email.
Thank you and looking forward to hearing back!

[praneetloke]

@francoistanguay sure thing. I don't use Twitter or Discord. So here are some notes about my experience:

• There were constant compilation errors which were very distracting to the development process.
• I didn't have a Mac connected to my project and every time I saw a red squiggly line I had to mouse over it to find out if it is just a problem with the macOS head project or something else. This really slowed me down.
• Examples for how to use the WinUI controls on the UWP docs page recommends that you install the WinUI3 XAML Controls app, which has succinct, and in my opinion incomplete, code snippets. There were pieces of code references missing here and there which made it super difficult to hunt down how it all fits together.
• I got super distracted with using Mvvm. In retrospect I shouldn't have gone down that route. I should have just stuck all event handlers in the code-behind file and moved on with my prototype.
• Then I installed the Windows Community Toolkit (Uno.Microsoft.Toolkit.* packages) which really broke my entire solution. My solution totally stopped building and even the UWP head project couldn't run anymore suddenly. I only discovered that the root cause was something in the Uno.Microsoft.Toolkit.* packages when I started a brand new solution from the Uno template and incrementally added some of my changes. It was when I started adding in code for the ListDetailView (a control provided by MS Toolkit) things broke.
• At that point I sort of cut my losses and gave up because even if I were to fix that issue with MS toolkit somehow, everything felt a bit too brittle for my experience. I can't imagine spending time fighting issues at every step of the way.

I am also sure that my lack of familiarity with the UWP development lent to some of my problems. An opinion I share with the Maui development platform too. There is a lot to learn but I don't know what is relevant and what is not anymore. There seems to be a lot of changes happening in this ecosystem, i.e. cross-platform development with C#, right now. I just don't think it is the right time for me to dip my toes into this.

Having said all that, I must say that the template project created from Uno worked exactly like I would have expected. Every platform rendered the code exactly the same way. So in essence, it is what I wanted with Maui but the inability to use out-of-box controls from WinUI3 pushed me away from Maui. I don't want to build core UI components from scratch. If I was building a component library, sure. But not as an app developer.

Disclaimer: some of what I experienced may not match up with yours. Ultimately, I think for me, it was a combination of my inexperience UWP-based development, lack of a single source of docs (try reading docs for UWP and you'll see references to WinUI which will take you to another set of docs with different code snippets) and a clear explanation of when you should use something, not enough resources on how to diagnose issues, inability to tell apart user error vs. platform error. This applies to both Maui and Uno as I trialed both.

[jfranki]

Regarding MVVM, I always recommend to go that route if the app is not going to be extremely simple. It makes the code testable, mantainable, and more in line with pure coding best practices, things that you will appreciate along the way.

If you want something fast and simple sure, use the code-behind and forget about view-models and such, otherwise I like to keep my code-behind as empty as possible (if I don't want to dinamically generate my XAML code that is).

[cesarchefinho]

Avalinia has an project to port winui controls to it and facilitate migration of laegacy apps.

wy not maui too ?

also there are github levitalli/compiled bindings project to implement xBind in maui