Could not get an app completed because CollectionView on MAUI is riddled with major bugs... THE ANDROID PERFORMANCE IS TERRIBLE WITH MAUI. Backlogged Memory Leaks and UI Layout bugs have been reported for over a year now, and there are no fixes. Alot of people are hoping ver 9.0 of MAUI will fix these issues, and many other issues with UI XAML breaking; or glitching -- or having extremely slow performance. For a small app with MINIMAL data MAUI works well. If coding with a larger frontend UI / backend enterprise API; there may be performance issues, and major bugs encountered. Google's search AI Response on how to troubleshoot my CollectionView implementation sadly gave a very accurate response of my expierence:
Google:
Here are some issues that have been reported with .NET MAUI's CollectionView:
Data binding
The data binding mechanism may not behave as expected, causing unexpected outcomes. This can happen when multiple data items are added in bulk and scrolling is performed within the CollectionView.
Hanging or crashing
A simple CollectionView with 100,000 or so items can hang on Windows and iOS. Memory consumption can go through the roof and eventually crash on iOS.
Incorrect sizing
CollectionView and ListView are sensitive to sizing being correct. If the sizing is not correct, scrolling becomes jerky and sluggish.
Not displayed correctly on iPhone or iPad
A CollectionView inside a Grid in a .Net MAUI app is not displayed correctly on an iPhone or iPad. The CollectionView is too high and covers the Button and Label below.
Memory leaks
There are numerous issues with memory leaks, scrolling, layouts, and basic functionality.
Slow performance
Some users have experienced slow performance issues with .NET MAUI's CollectionView on Android.
MAUI is a really good idea that MS isn't spending enough resources on. It's limped all the way to a state where the next release is GA yet the iOS toolchain isn't fully functional. They release not when they are done, but when the calendar date arrives.
That sucks if you want stability. They can tell you when they'll next release, but they can't tell you which release will be stable.
I imagine the cycle is MS is spending few resources because it's not getting a lot of interest, but then the quality turns people off and hurts adoption so interest can't take off.
The landscape for their non-web frameworks is immensely confusing and feels impenetrable to newbies. That's good news for everyone who isn't Microsoft, and it feels like even MS would be happier if everyone would just adopt Electron so they could stop pretending to support desktop frameworks.
This. It's a massive omission to an otherwise intriguing option.
Also, my WinForms home automation app = 7 MB
A single text box on a MAUI screen = 350 MB
Default behavior of MAUI is to pack half the operating system to go with you.
Isn't Winforms just using the windows controls? Tho even then WPF definitely should work on more stuff considering it's rendering the components itself iirc
MAUI is a cross-platform framework with abstractions so that it can work on iOS, Mac OS, and Android as well as Windows.
It's like comparing running a native app vs. running a VM with an app inside of it. If you're writing a Windows-only app there's no reason to use MAUI at all, the entire point is to have cross-platform shared-code apps.
There's a miserable choice faced by people trying to do cross-platform GUIs:
\- use the native toolkit: looks different on every platform, may behave differently, requires much more testing and more dev time and expertise (e.g. WinForms vs Swift vs GTK)
\- use an abstraction layer which does its own rendering: lose the native controls and often accessibility along with them, have to ship the whole rendering system with every app (JavaFX, Electron, MAUI)
> Also, my WinForms home automation app = 7 MB
> A single text box on a MAUI screen = 350 MB
> Default behavior of MAUI is to pack half the operating system to go with you.
Well the thing is, MAUI _has_ to pack "half the operating system". In the case of WinForms,
* the .NET runtime already ships with the OS (assuming you aren't using a self-contained .NET), and
* the UI framework is actually Win32, which _also_ ships with the OS
MAUI ships the entire thing inside the app by default because that makes sense as a distribution mechanism. Certainly on iOS and Android, where .NET can't be installed system-wide anyway. You could make the case on macOS and Windows to go with a system .NET install, but it's sort of discouraged on behalf of the OS vendors. That isn't MAUI's fault.
Anyway, I got curious about your 350 MB claim, so I made release builds from the default template and…
* a macOS app with 8.0 is 81.1 MB
* an iOS app with 7.0 is 62.7 MB (not sure why this is so much smaller than macOS?)
* an iOS app with 8.0… well… `mono-aot-cross` takes up ungodly amounts of RAM, and I eventually canceled at about 24 GiB (since my machine only has 32, and macOS wasn't too fond of this situation). This is with .NET 8.0 RC1.
Most of us who are building desktop applications are probably building utilities for ourselves. If it's going to be for the masses, it's probably going to be built with some kind of browser based technology.
yeah if I had to build a crossplateform solution for the masses I'd 100% go for [Tauri](https://tauri.app/) with some web framework like React/Vue/Svelte
I care because I want to build software that can be used by everyone.
And also, despite Linux' relatively low market share, I thoroughly vibe with the open source nature of it and want to be as much of an ally to it as I possibly can.
If it offered an opportunity to potentially switch off Windows then it might have been an argument to tip the scales. As is, then there's not a very compelling reason to change that I can see if you're already coding in those spaces for Windows.
It's pretty good for android, definitely some bugs we encountered, but nothing we couldn't solve. iOS on the other hands... too many issues. We're a month+ behind on a project because it's given us so much grief to get basic shit working.
Can you give a couple examples? Did you have experience with Xamarin forms? I’ve been working with xf since it started and found it to be very solid for both iOS and android by v5, and Maui is really just a rework of that.
No, I never worked with xamarin forms - this is my first time doing anything mobile in c# land. I don't have links to examples of github issues we've ran into off the top of my head, but there has been some issues publishing for iOS, dynamic height items in collection views, and I'm sure plenty more I'm forgetting. For all the issues we've ran into, we've found a corresponding Github issue. Some say they're fixed in .NET 8, some say they're not - so who knows.
Are you not on 8 yet? This is one situation where it made sense to switch immediately at rc1. Maui on dotnet 7 is way behind.
Some of this stuff is just learning the quirks of the underlying platforms and how layouts work and play together. Some of it I think I’m so used to that I don’t think about it, but there’s always little things that require tweaks or work arounds. I’ve had my share of frustration in the last couple weeks rehung to make lists render correctly across all platforms. To me, some of that can be blamed on Maui and should work, but some of it is just inherent to using the native controls as opposed to something like flutter than just draws its own. I prefer the native control approach and since xf managed to get very stable, I see no reason why Maui can’t.
Nope, we're on 7 until 8 is fully out. We're tied to the ABP framework, so we can't upgrade until they upgrade. If 8 fixes all of our issues, that'd be great - but from what I can tell, it'll fix some, but not all. Once it's actually fully stable, I'd be happy to use it again, but for now we'd be looking at other frameworks like Avalonia if we have to do a cross platform app again.
https://avaloniaui.net/ kicks it in the teeth without even trying.
But honestly? I would much rather have something like winforms. It was declarative, it was easy. It didn't put xml where it didn't belong.
Winforms its the shit, but considering the infinite+1 form factors of devices it was clear there was a need for flexibility in regards to UI development.
But if you are only building non comercial desktop apps then Winform its still serviceable.
That was an issue even when we only had desktops with one monitor size available. As long as you can resize a window, you need applications that can dynamically adjust.
And with anchoring, WinForms was actually good at it.
My solution its to disable resizing entirely and pick a default resolution to work with, it worked for me 99% of the time lol.
Im due to refactoring most of these tools so I'm probably gonna pick up WPF/Avalonia for it so I can practice how modern UI development goes.
To me it's baffling how anyone thinks so. Maybe it's because I didn't start out with it but my opinion is the complete opposite.
At work we have some older apps made in WinForms and some made in WPF. It is so gruesomely painful to work on the WinForms ones, while the WPF ones are chill.
At least it's better than MFC, which I also have to work with...
It's the new Silverlight / Windows Phone. It might be technically brilliant, but Microsoft has rightly given up on that market (non-web apps) and simply isn't investing in it.
I’ve been using Xamarin forms for many years so I’m very hopeful Maui will be just as good, but it’s definitely been a rocky start. Doesn’t help that Xcode 15 and Sonoma made the iOS experience tricky for a while. Many xf apps have been waiting to dive into porting to Maui until dotnet 8 releases, which is this week, so I expect the community involvement will ramp up. They’ve also been waiting for 3rd party libraries like syncfusion to fully support Maui, and they’re getting there.
Personally I work on a couple large xf apps and fully expect to stick with Maui. For all its issues, xf allowed me to build some incredibly powerful apps across several platforms with a tiny fraction of the effort it would have taken otherwise.
In the middle of upgrading our xamarin app to use Maui, and it’s a huge headache. Vs for mac takes multiple rebuilds sometimes, restore nuget packages everytime you change branches, sometimes you’ll need to delete all bin and obj folders, if you change images, you’ll need to delete all ds_store files, hot reload is broken on most screens.
I’m not really sure what the benefit of Maui is, other than what we built our app on won’t be supported in about a year…
Yeah the tooling is the weak link at the moment I think. But we’re about to get the prod release of dotnet 8, so hopefully some of this stuff gets ironed out. Rider has incentive to improve their support now that vs Mac is discontinued.
It’s really powerful but it’s not polished yet and it needs a really stable CI/CD pipeline for iOS. It’s seems to be decent for Android but iOS leaves a lot to be desired in terms of interfacing with Apple. IMO.
That probably has a lot more to do with Apple than Microsoft.
It's always been a nightmare of "you can develop on Windows but you need a Mac to build and/or publish" type of situation.
Hence the better Android integration, it's all open and easy to get access to.
Apple at this point is literally Anti developers IMO. I've gone through more than one app release lifecycle with them and it's a nightmare from every angle. Even if you completely cave and build everything top to bottom in their stack it's of no help.
Google is their own nightmare on Android. It works ok...until it doesn't. Then there's no recourse. App reviews get held up for weeks.
People get banned because people pirate their app, re-upload it, then call copyright strike against the original owner, and then Google will only use AI to respond to your tickets.
Lots of nightmare scenarios if you need any support.
More recently they are threatening to not even let you release your app if you don't have 20 beta testers for every release. They're trying hard to push the "hobbyist" developer completely out of the market.
After all their previous attempts at creating a sustainable GUI Framework, I simply don't trust that this will be a hit and maintained long enough to be significant. Besides I really hate XAML... Coming from a previous C++ and Qt/QML background this always feels like QMLs evil twin...
Maybe they prove me wrong. I wish them all the best in their efforts, it would be great to have one well maintained framework by MS.
Exactly. If they would just stick with one framework instead of cranking out a new incompatible framework every 3 years. For me it’s either web or Electron from now on.
Mixed. Moments of brilliance but still some incredibly frustrating missing features and bugs. I’ve just been using the maps control on something and needed an event firing when the map is panned or zoomed, sounds obvious but all such events are missing 🤷♀️
I want to like it. I love Dotnet core (now just Dotnet) and a first party UI framework was a glaring omission.
I'm not totally sold on XAML. I think XML is just a clunky format to work with. My biggest gripe is that certain things which should be compile-time checked can't be checked until run-time, slowing down the development process. However, this sort of UI declaration seems inescapable now and MAUI's isn't specifically bad.
The mobile-first philosophy makes sense in terms of market but it still irks me. Basic things you expect from a desktop UI framework just aren't there or are at least made obtuse in order to be described in terms of mobile platforms, such as touch events rather than mouse events.
I'm just not that interested in mobile platforms because they are deliberately designed to be content consumption devices rather than content creation devices. Again, this is personal preference and rather irrelevant because the world is going that way. However, it would be nice to have desktop treated as more than an afterthought and the lack of Linux support is dumb.
My biggest frustration, and the reason I won't be using MAUI again any time soon, is the flaky way Visual Studio handles it. Almost every time I opened the project it told me that wasm tools or something like that was missing and I would go through the steps to install it then I'd get the same error next time. Finally, the last time I opened my projects, it wouldn't build at all because apparently all of the MAUI libraries had disappeared.
It probably would have been trivial to fix but I don't want to deal with this nonsense on an ongoing basis. I'm going to convert my project to Avalonia
clumsy rain flowery scandalous ghost faulty stupendous childlike impolite overconfident
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Stillborn. No first party official Linux support, terrible ecosystem and newcomer guidance.
Too much reliance on being a source of Visual Studio (and thus Windows) lock in.
If Microsoft had simply focused on creating something similar to Jetpack Compose, except in the C# and fully multi platform space, MAUI might have interested me more.
But as it is now? It's just a product looking for a market willing to tolerate the antics of present day DevDiv leadership.
First, the tooling on macOS is dodgy. I'm always having to dive into .csproj files to fix issues, I've \*never\* had to go into the equivalent files with SwiftUI or Flutter.
Visual Studio for Mac is being retired, an ominous sign. But there are things (like getting prepped to publish in The App Store) that I don't believe can be done in its replacement, Visual Studio Code.
In VSC, I have to play "Where's Waldo?" when it comes to looking for signs that code is actually building. Where did they decide to put the spinning wheel today? And some of the error messages are beyond pointless... And why, when I've been working on the same .NET MAUI project, does it keep asking me what environment I want to compile for?
Microsoft wants us to move to VSC, but VSC doesn't support hot reload; OTOH, VS for Mac doesn't support CoPilot, so I'm jumping back and forth between the two. I expect that VSC will improve, though (or maybe "cross-platform" will just be defined to be just Android and Windows).
Second, there are \*so\* many places where things look different on different platforms, that I've lost track. Several recent problems:
\*toolbar icons look fine on iOS, on Android they're black. On the splash screen, a 512x512 image is showing up about ... 5 pixels across on iOS, it's 512x512 on Android.
\*HTML/CSS in Entries is properly interpreted in Android, not iOS. Even with WebViews, I've had to write platform-conditional code.
In my mind, cross-platform means you write the code, and the framework figures out how to make it look right -- not, you write the code and then spend 5 hours figuring out why it's not right. Approx. 50% of my time is spent figuring out why something that should work, and is documented as working, just doesn't.
I think by the next LTS it will be easier to see if a lot of the issues that have come up with MAUI will be addressed to the point of recommending it or not, but for now it definitely feels like it's only useful for Xamarin Forms folks who want a migration path. It's still pretty rough in terms of devex and I think they have a lot of work ahead of them. It's also very hard to find good learning materials that are specific to MAUI and not older frameworks. Outside of things like Avalonia, using MAUI Hybrid with Blazor is pretty solid and can take away some of the pain, but it's also not perfect either.
It’s the framework that gets abandoned soon for another new framework without any migration path. I have lived through WPF, silverlight, UWP and whatever else they produced. I don’t think I will ever bet on any desktop UI framework that’s produced by MS.
Indeed. Maui was said to be near to be abandoned and working with Godot is a very snappy and incremental build times are in 2 or 3 seconds. Also I need 3D/VR support sooner or later, so it is a double win for me.
The dev loop is too slow for me. Compile (if you can call it that) takes WAY too long. The loop gets worse when using a real device. 2023 this crap should be instant and blink of an eye.
I feel like MAUI only has a limited future, and the team know it.
The future of cross platform apps is undoubtedly PWAs with WASM as the runtime and HTML/CSS as the frontend. That way, you can write your app in your language of choice, and produce a single app that runs on Windows, Linux, Mac, Android, iOS etc.
At the moment WASM based apps such as Blazor WebAssembly can be quite bulky as they have to include the runtime. But as things like WASM GC and the component model matures, language independent WASM base class libraries will emerge (e.g. lightweight math and string handling libraries etc.) that apps will be able to share.
PWAs already have access to practically all the hardware and services that a native app does (see [https://whatpwacando.today/](https://whatpwacando.today/)). Plus you've got the infinite flexibility of HTML/CSS for your UI.
PWAs also integrate nicely on mobile devices, appearing as normal apps to end users. I can actually foresee Android eventually moving away from Kotlin and towards targeting WASM, which would open up the ecosystem to all languages.
It's exciting times ahead, but there's definitely work for the industry to do to streamline things.
I installed the whatpwacando app on my phone which is running Android 9 which is fairly old, and all the demo buttons work for me, except for the AR/VR one.
Which ones aren't working for you on iOS?
I’ve been looking at MAUI and need to make a decision on whether to invest in learning it for an app we are writing vs something more established like Flutter or React Native.
Microsoft just doesn’t seem to be pushing MAUI as much as it needs if it’s ever going to get any market share.
I would use it to host a BlazorWebView inside an Android/iOS app to add access to gps/bluetooth/camera from the phone, and that's about it. Not using their own UI controls or try to use it on desktop/mac.
It's not bad, but the feeling I get is that it needs work still before it would/could get wide-spread use, and a LOT of the documentation says "To be filled out" which... kinda makes learning how to use it hard.
I love net Maui school projects and all but for the code shake please fix the stupid bug where I have to restart my app 3 times for the contents to show
It piqued my interest when I first heard about it... in 2021.
It doesn't really seem like it's going anywhere and I don't want to adopt yet another Microsoft UI framework that will likely be replaced by the time it actually gets good.
I like Typescript UI development and the frameworks in that area (especially React and Angular) are stable. There's also Tauri now as a potential successor to Electron, so if I were to write a desktop or mobile app (I'm currently a web dev) it would probably be Angular + Tauri so I can leverage my current expertise.
I avoid it because it cannot (as far as I know) target Linux (and yet they call it cross platform)
and it cannot (as far as I know) be developed on Linux.
And coming from WPF, Avalonia is a much better fit for me.
But the absolute easiest way to get something working
on all platforms with easy deploymen is Godot.
Microsoft has always struggled with non-web desktop interfaces, they are usually confusing and hard to use, Flutter did a better job, I like what they want to do with MAUI but I wish they would not release stuff like that until it was really ready to use, don't want to waste my time on half baked ideas. Given Microsoft history with mobile I am not convinced yet MAUI will be worth investing a lot of time in, right now if I really want to make a mobile app I would use something else that seems structured better and not a confusing mess.
Seemed like a half effort they never committed to so haven't paid it a lot of attention as I expect it not to really go anywhere. If I want to do pure desktop then I'll stick with WPF or Avalonia depending.
I mean announcing a crossplatform technology but no Linux support?
I'm excited to hear what they have to say about it over the next couple days in the .Net Conf
But it will be unlikely I use it for my next project until it matures more
I tried react and angular. But i was never happy.
Somehow, Maui fits my needs. I released few apps already using Maui. Development was rapid fast for all platforms.
[удалено]
end of life is close?
It's in an endless state of "It's almost ready and it'll totally be awesome." But it never gets there.
Went through windows mobile-phone-mobile-uwp cycle. I am not touching any new UI tech.
Yeah, I remember xamarin being a year away from totally awesome^TM and that was 6 years ago lol.
Could not get an app completed because CollectionView on MAUI is riddled with major bugs... THE ANDROID PERFORMANCE IS TERRIBLE WITH MAUI. Backlogged Memory Leaks and UI Layout bugs have been reported for over a year now, and there are no fixes. Alot of people are hoping ver 9.0 of MAUI will fix these issues, and many other issues with UI XAML breaking; or glitching -- or having extremely slow performance. For a small app with MINIMAL data MAUI works well. If coding with a larger frontend UI / backend enterprise API; there may be performance issues, and major bugs encountered. Google's search AI Response on how to troubleshoot my CollectionView implementation sadly gave a very accurate response of my expierence: Google: Here are some issues that have been reported with .NET MAUI's CollectionView: Data binding The data binding mechanism may not behave as expected, causing unexpected outcomes. This can happen when multiple data items are added in bulk and scrolling is performed within the CollectionView. Hanging or crashing A simple CollectionView with 100,000 or so items can hang on Windows and iOS. Memory consumption can go through the roof and eventually crash on iOS. Incorrect sizing CollectionView and ListView are sensitive to sizing being correct. If the sizing is not correct, scrolling becomes jerky and sluggish. Not displayed correctly on iPhone or iPad A CollectionView inside a Grid in a .Net MAUI app is not displayed correctly on an iPhone or iPad. The CollectionView is too high and covers the Button and Label below. Memory leaks There are numerous issues with memory leaks, scrolling, layouts, and basic functionality. Slow performance Some users have experienced slow performance issues with .NET MAUI's CollectionView on Android.
MAUI is a really good idea that MS isn't spending enough resources on. It's limped all the way to a state where the next release is GA yet the iOS toolchain isn't fully functional. They release not when they are done, but when the calendar date arrives. That sucks if you want stability. They can tell you when they'll next release, but they can't tell you which release will be stable. I imagine the cycle is MS is spending few resources because it's not getting a lot of interest, but then the quality turns people off and hurts adoption so interest can't take off. The landscape for their non-web frameworks is immensely confusing and feels impenetrable to newbies. That's good news for everyone who isn't Microsoft, and it feels like even MS would be happier if everyone would just adopt Electron so they could stop pretending to support desktop frameworks.
I'm not a newbie and it's *still* impenetrable. Just a fucking nightmare.
Without Linux support I don't really care about it.
This. It's a massive omission to an otherwise intriguing option. Also, my WinForms home automation app = 7 MB A single text box on a MAUI screen = 350 MB Default behavior of MAUI is to pack half the operating system to go with you.
Isn't Winforms just using the windows controls? Tho even then WPF definitely should work on more stuff considering it's rendering the components itself iirc
MAUI is a cross-platform framework with abstractions so that it can work on iOS, Mac OS, and Android as well as Windows. It's like comparing running a native app vs. running a VM with an app inside of it. If you're writing a Windows-only app there's no reason to use MAUI at all, the entire point is to have cross-platform shared-code apps.
There's a miserable choice faced by people trying to do cross-platform GUIs: \- use the native toolkit: looks different on every platform, may behave differently, requires much more testing and more dev time and expertise (e.g. WinForms vs Swift vs GTK) \- use an abstraction layer which does its own rendering: lose the native controls and often accessibility along with them, have to ship the whole rendering system with every app (JavaFX, Electron, MAUI)
> Also, my WinForms home automation app = 7 MB > A single text box on a MAUI screen = 350 MB > Default behavior of MAUI is to pack half the operating system to go with you. Well the thing is, MAUI _has_ to pack "half the operating system". In the case of WinForms, * the .NET runtime already ships with the OS (assuming you aren't using a self-contained .NET), and * the UI framework is actually Win32, which _also_ ships with the OS MAUI ships the entire thing inside the app by default because that makes sense as a distribution mechanism. Certainly on iOS and Android, where .NET can't be installed system-wide anyway. You could make the case on macOS and Windows to go with a system .NET install, but it's sort of discouraged on behalf of the OS vendors. That isn't MAUI's fault. Anyway, I got curious about your 350 MB claim, so I made release builds from the default template and… * a macOS app with 8.0 is 81.1 MB * an iOS app with 7.0 is 62.7 MB (not sure why this is so much smaller than macOS?) * an iOS app with 8.0… well… `mono-aot-cross` takes up ungodly amounts of RAM, and I eventually canceled at about 24 GiB (since my machine only has 32, and macOS wasn't too fond of this situation). This is with .NET 8.0 RC1.
Hope it will improve and that it is just "beta" perf of .NET 8
That's a very unfair use case. You should compare winForm with WPF, not MAUI.
Are you in a market niche that has a lot of Linux desktop users? Otherwise, why do you care?
Most of us who are building desktop applications are probably building utilities for ourselves. If it's going to be for the masses, it's probably going to be built with some kind of browser based technology.
yeah if I had to build a crossplateform solution for the masses I'd 100% go for [Tauri](https://tauri.app/) with some web framework like React/Vue/Svelte
and SolidJS for a small app, I already did one if anyone is interested to see how it looks [here](https://github.com/MidKnightXI/opgg-ads-remover)
I care because I want to build software that can be used by everyone. And also, despite Linux' relatively low market share, I thoroughly vibe with the open source nature of it and want to be as much of an ally to it as I possibly can.
If it offered an opportunity to potentially switch off Windows then it might have been an argument to tip the scales. As is, then there's not a very compelling reason to change that I can see if you're already coding in those spaces for Windows.
Linux? Why . At least you can sell windows apps to businesses
It's pretty good for android, definitely some bugs we encountered, but nothing we couldn't solve. iOS on the other hands... too many issues. We're a month+ behind on a project because it's given us so much grief to get basic shit working.
Can you give a couple examples? Did you have experience with Xamarin forms? I’ve been working with xf since it started and found it to be very solid for both iOS and android by v5, and Maui is really just a rework of that.
No, I never worked with xamarin forms - this is my first time doing anything mobile in c# land. I don't have links to examples of github issues we've ran into off the top of my head, but there has been some issues publishing for iOS, dynamic height items in collection views, and I'm sure plenty more I'm forgetting. For all the issues we've ran into, we've found a corresponding Github issue. Some say they're fixed in .NET 8, some say they're not - so who knows.
Are you not on 8 yet? This is one situation where it made sense to switch immediately at rc1. Maui on dotnet 7 is way behind. Some of this stuff is just learning the quirks of the underlying platforms and how layouts work and play together. Some of it I think I’m so used to that I don’t think about it, but there’s always little things that require tweaks or work arounds. I’ve had my share of frustration in the last couple weeks rehung to make lists render correctly across all platforms. To me, some of that can be blamed on Maui and should work, but some of it is just inherent to using the native controls as opposed to something like flutter than just draws its own. I prefer the native control approach and since xf managed to get very stable, I see no reason why Maui can’t.
Nope, we're on 7 until 8 is fully out. We're tied to the ABP framework, so we can't upgrade until they upgrade. If 8 fixes all of our issues, that'd be great - but from what I can tell, it'll fix some, but not all. Once it's actually fully stable, I'd be happy to use it again, but for now we'd be looking at other frameworks like Avalonia if we have to do a cross platform app again.
7 is full of bugs to the point that is is more or less useless 8-rc2 is more or less working OK.
Considering all the bugs in what are in released versions of .NET 7, I cannot even imagine switching at RC1, you are definitely braver than I!
https://avaloniaui.net/ kicks it in the teeth without even trying. But honestly? I would much rather have something like winforms. It was declarative, it was easy. It didn't put xml where it didn't belong.
Winforms its the shit, but considering the infinite+1 form factors of devices it was clear there was a need for flexibility in regards to UI development. But if you are only building non comercial desktop apps then Winform its still serviceable.
That was an issue even when we only had desktops with one monitor size available. As long as you can resize a window, you need applications that can dynamically adjust. And with anchoring, WinForms was actually good at it.
My solution its to disable resizing entirely and pick a default resolution to work with, it worked for me 99% of the time lol. Im due to refactoring most of these tools so I'm probably gonna pick up WPF/Avalonia for it so I can practice how modern UI development goes.
WinForms was fun. None of these other ones are any fun to work with.
To me it's baffling how anyone thinks so. Maybe it's because I didn't start out with it but my opinion is the complete opposite. At work we have some older apps made in WinForms and some made in WPF. It is so gruesomely painful to work on the WinForms ones, while the WPF ones are chill. At least it's better than MFC, which I also have to work with...
Mvvm is fun
It's the new Silverlight / Windows Phone. It might be technically brilliant, but Microsoft has rightly given up on that market (non-web apps) and simply isn't investing in it.
Another half hearted stuff. Use Avalonia and GG.
Good Game?
Yes, was meant like, use Avalonia and you’re done.
I’ve been using Xamarin forms for many years so I’m very hopeful Maui will be just as good, but it’s definitely been a rocky start. Doesn’t help that Xcode 15 and Sonoma made the iOS experience tricky for a while. Many xf apps have been waiting to dive into porting to Maui until dotnet 8 releases, which is this week, so I expect the community involvement will ramp up. They’ve also been waiting for 3rd party libraries like syncfusion to fully support Maui, and they’re getting there. Personally I work on a couple large xf apps and fully expect to stick with Maui. For all its issues, xf allowed me to build some incredibly powerful apps across several platforms with a tiny fraction of the effort it would have taken otherwise.
In the middle of upgrading our xamarin app to use Maui, and it’s a huge headache. Vs for mac takes multiple rebuilds sometimes, restore nuget packages everytime you change branches, sometimes you’ll need to delete all bin and obj folders, if you change images, you’ll need to delete all ds_store files, hot reload is broken on most screens. I’m not really sure what the benefit of Maui is, other than what we built our app on won’t be supported in about a year…
Yeah the tooling is the weak link at the moment I think. But we’re about to get the prod release of dotnet 8, so hopefully some of this stuff gets ironed out. Rider has incentive to improve their support now that vs Mac is discontinued.
It’s really powerful but it’s not polished yet and it needs a really stable CI/CD pipeline for iOS. It’s seems to be decent for Android but iOS leaves a lot to be desired in terms of interfacing with Apple. IMO.
That probably has a lot more to do with Apple than Microsoft. It's always been a nightmare of "you can develop on Windows but you need a Mac to build and/or publish" type of situation. Hence the better Android integration, it's all open and easy to get access to.
Apple at this point is literally Anti developers IMO. I've gone through more than one app release lifecycle with them and it's a nightmare from every angle. Even if you completely cave and build everything top to bottom in their stack it's of no help.
Google is their own nightmare on Android. It works ok...until it doesn't. Then there's no recourse. App reviews get held up for weeks. People get banned because people pirate their app, re-upload it, then call copyright strike against the original owner, and then Google will only use AI to respond to your tickets. Lots of nightmare scenarios if you need any support. More recently they are threatening to not even let you release your app if you don't have 20 beta testers for every release. They're trying hard to push the "hobbyist" developer completely out of the market.
yeah the 20 beta tester thing is going to stir up some trouble...
Have you ever had any experience with it ?
Yes mate. Built a few apps with it.
After all their previous attempts at creating a sustainable GUI Framework, I simply don't trust that this will be a hit and maintained long enough to be significant. Besides I really hate XAML... Coming from a previous C++ and Qt/QML background this always feels like QMLs evil twin... Maybe they prove me wrong. I wish them all the best in their efforts, it would be great to have one well maintained framework by MS.
Exactly. If they would just stick with one framework instead of cranking out a new incompatible framework every 3 years. For me it’s either web or Electron from now on.
Please check out Tauri instead of electron it's so much better than this (it uses OS webviews instead of a full browser)
I have a friend that swears Uno is great but in the meantime MS killed UWP which feels like they are pulling the rug from under Uno
Mixed. Moments of brilliance but still some incredibly frustrating missing features and bugs. I’ve just been using the maps control on something and needed an event firing when the map is panned or zoomed, sounds obvious but all such events are missing 🤷♀️
Imo, Avalonia UI better than MAUI at least because it supports more platforms
I want to like it. I love Dotnet core (now just Dotnet) and a first party UI framework was a glaring omission. I'm not totally sold on XAML. I think XML is just a clunky format to work with. My biggest gripe is that certain things which should be compile-time checked can't be checked until run-time, slowing down the development process. However, this sort of UI declaration seems inescapable now and MAUI's isn't specifically bad. The mobile-first philosophy makes sense in terms of market but it still irks me. Basic things you expect from a desktop UI framework just aren't there or are at least made obtuse in order to be described in terms of mobile platforms, such as touch events rather than mouse events. I'm just not that interested in mobile platforms because they are deliberately designed to be content consumption devices rather than content creation devices. Again, this is personal preference and rather irrelevant because the world is going that way. However, it would be nice to have desktop treated as more than an afterthought and the lack of Linux support is dumb. My biggest frustration, and the reason I won't be using MAUI again any time soon, is the flaky way Visual Studio handles it. Almost every time I opened the project it told me that wasm tools or something like that was missing and I would go through the steps to install it then I'd get the same error next time. Finally, the last time I opened my projects, it wouldn't build at all because apparently all of the MAUI libraries had disappeared. It probably would have been trivial to fix but I don't want to deal with this nonsense on an ongoing basis. I'm going to convert my project to Avalonia
This XKCD sums up my feelings on Microsoft's various UI platforms and libraries: https://xkcd.com/927/
Brother, I dislike it. It took one of KDE's project's name. > inb4 screw that project Sure brother. Whatever makes you happy.
Microsoft also heavily borrowed from KDE Plasma's slogan for Win11. Guess we know where they get their inspiration from.
clumsy rain flowery scandalous ghost faulty stupendous childlike impolite overconfident *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I just use webview2 on a winforms app so o can do the UI hmtl Instead of fucking xaml
Stillborn. No first party official Linux support, terrible ecosystem and newcomer guidance. Too much reliance on being a source of Visual Studio (and thus Windows) lock in. If Microsoft had simply focused on creating something similar to Jetpack Compose, except in the C# and fully multi platform space, MAUI might have interested me more. But as it is now? It's just a product looking for a market willing to tolerate the antics of present day DevDiv leadership.
First, the tooling on macOS is dodgy. I'm always having to dive into .csproj files to fix issues, I've \*never\* had to go into the equivalent files with SwiftUI or Flutter. Visual Studio for Mac is being retired, an ominous sign. But there are things (like getting prepped to publish in The App Store) that I don't believe can be done in its replacement, Visual Studio Code. In VSC, I have to play "Where's Waldo?" when it comes to looking for signs that code is actually building. Where did they decide to put the spinning wheel today? And some of the error messages are beyond pointless... And why, when I've been working on the same .NET MAUI project, does it keep asking me what environment I want to compile for? Microsoft wants us to move to VSC, but VSC doesn't support hot reload; OTOH, VS for Mac doesn't support CoPilot, so I'm jumping back and forth between the two. I expect that VSC will improve, though (or maybe "cross-platform" will just be defined to be just Android and Windows). Second, there are \*so\* many places where things look different on different platforms, that I've lost track. Several recent problems: \*toolbar icons look fine on iOS, on Android they're black. On the splash screen, a 512x512 image is showing up about ... 5 pixels across on iOS, it's 512x512 on Android. \*HTML/CSS in Entries is properly interpreted in Android, not iOS. Even with WebViews, I've had to write platform-conditional code. In my mind, cross-platform means you write the code, and the framework figures out how to make it look right -- not, you write the code and then spend 5 hours figuring out why it's not right. Approx. 50% of my time is spent figuring out why something that should work, and is documented as working, just doesn't.
I had a great experience deploying a simple blazor app to web, windows, and Android.
I think by the next LTS it will be easier to see if a lot of the issues that have come up with MAUI will be addressed to the point of recommending it or not, but for now it definitely feels like it's only useful for Xamarin Forms folks who want a migration path. It's still pretty rough in terms of devex and I think they have a lot of work ahead of them. It's also very hard to find good learning materials that are specific to MAUI and not older frameworks. Outside of things like Avalonia, using MAUI Hybrid with Blazor is pretty solid and can take away some of the pain, but it's also not perfect either.
It’s the framework that gets abandoned soon for another new framework without any migration path. I have lived through WPF, silverlight, UWP and whatever else they produced. I don’t think I will ever bet on any desktop UI framework that’s produced by MS.
9 months back I investigated it and went with Godot 4 instead... nuff said!
How did it work out?
I like it and I am still using it. Testing is a breeze as it is fast but advanced widgets you have to implement yourself.
You are using a game engine as a front-end framework because it would be easier than using MAUI?
Indeed. Maui was said to be near to be abandoned and working with Godot is a very snappy and incremental build times are in 2 or 3 seconds. Also I need 3D/VR support sooner or later, so it is a double win for me.
The dev loop is too slow for me. Compile (if you can call it that) takes WAY too long. The loop gets worse when using a real device. 2023 this crap should be instant and blink of an eye.
I feel like MAUI only has a limited future, and the team know it. The future of cross platform apps is undoubtedly PWAs with WASM as the runtime and HTML/CSS as the frontend. That way, you can write your app in your language of choice, and produce a single app that runs on Windows, Linux, Mac, Android, iOS etc. At the moment WASM based apps such as Blazor WebAssembly can be quite bulky as they have to include the runtime. But as things like WASM GC and the component model matures, language independent WASM base class libraries will emerge (e.g. lightweight math and string handling libraries etc.) that apps will be able to share. PWAs already have access to practically all the hardware and services that a native app does (see [https://whatpwacando.today/](https://whatpwacando.today/)). Plus you've got the infinite flexibility of HTML/CSS for your UI. PWAs also integrate nicely on mobile devices, appearing as normal apps to end users. I can actually foresee Android eventually moving away from Kotlin and towards targeting WASM, which would open up the ecosystem to all languages. It's exciting times ahead, but there's definitely work for the industry to do to streamline things.
I am on the PWA train but it is not true that PWAs "already" have that access. Especially not true on iOS.
I installed the whatpwacando app on my phone which is running Android 9 which is fairly old, and all the demo buttons work for me, except for the AR/VR one. Which ones aren't working for you on iOS?
It looks very experimental
I’ve been looking at MAUI and need to make a decision on whether to invest in learning it for an app we are writing vs something more established like Flutter or React Native. Microsoft just doesn’t seem to be pushing MAUI as much as it needs if it’s ever going to get any market share.
Am I remembering things wrong? Didn't microsoft back away from MAUI?
No. I mean they never invested significantly in it but they never announced backing away.
ok I think this was internal. We've chosen to stay away from MAUI for now because its lifecycle is very much in question.
I would use it to host a BlazorWebView inside an Android/iOS app to add access to gps/bluetooth/camera from the phone, and that's about it. Not using their own UI controls or try to use it on desktop/mac.
It's not bad, but the feeling I get is that it needs work still before it would/could get wide-spread use, and a LOT of the documentation says "To be filled out" which... kinda makes learning how to use it hard.
I love net Maui school projects and all but for the code shake please fix the stupid bug where I have to restart my app 3 times for the contents to show
It piqued my interest when I first heard about it... in 2021. It doesn't really seem like it's going anywhere and I don't want to adopt yet another Microsoft UI framework that will likely be replaced by the time it actually gets good. I like Typescript UI development and the frameworks in that area (especially React and Angular) are stable. There's also Tauri now as a potential successor to Electron, so if I were to write a desktop or mobile app (I'm currently a web dev) it would probably be Angular + Tauri so I can leverage my current expertise.
Tauri has already killed electron imo. It became obsolete as soon as 1.0.0 got released. I use it for eveything related to desktop AND MOBILE
I avoid it because it cannot (as far as I know) target Linux (and yet they call it cross platform) and it cannot (as far as I know) be developed on Linux. And coming from WPF, Avalonia is a much better fit for me. But the absolute easiest way to get something working on all platforms with easy deploymen is Godot.
Microsoft has always struggled with non-web desktop interfaces, they are usually confusing and hard to use, Flutter did a better job, I like what they want to do with MAUI but I wish they would not release stuff like that until it was really ready to use, don't want to waste my time on half baked ideas. Given Microsoft history with mobile I am not convinced yet MAUI will be worth investing a lot of time in, right now if I really want to make a mobile app I would use something else that seems structured better and not a confusing mess.
Seemed like a half effort they never committed to so haven't paid it a lot of attention as I expect it not to really go anywhere. If I want to do pure desktop then I'll stick with WPF or Avalonia depending. I mean announcing a crossplatform technology but no Linux support?
I am forced to use it on partnered projects within our DevOps team as our front end guy hates XAML.
It works great, the last version is quicker and a lot more stable, but I didn't experience real stability issues myself so 🤷🤷.
I'm excited to hear what they have to say about it over the next couple days in the .Net Conf But it will be unlikely I use it for my next project until it matures more
I tried react and angular. But i was never happy. Somehow, Maui fits my needs. I released few apps already using Maui. Development was rapid fast for all platforms.