Replies: 56 comments 205 replies
-
|
MAUI is free open source project. Calling it SCAM because it has some bugs is ridicoulus. The team is working hard to fix issues one by one, but it takes time. It is still a new platform that hasn't matured yet. It's up to debate whether it should have been marked production ready so early in the process and whether enough resources were comitted to the developement, but it certainly isn't SCAM and I'm sure it will become really great technology by .NET 8 release. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, some are paying Microsoft for other services. MAUI is a product they offer to make you enticed to pay for their other services, such as Visual Studio license, etc. Just because they have a business model where you don't pay for the framework directly doesn't mean they have fewer obligations. Well, legally maybe, but not in the eyes of people. I completely understand the OP's frustration. Many people here said "It's not production ready, but it's not a scam", what is Microsoft's "production ready" advertising if not a scam then? :) |
Beta Was this translation helpful? Give feedback.
-
|
@Vroomer: You miss the logic line, that's why final word "scam" looks too heavy for you. Look: MS tries to play "multiplatform" (and obviously fails here). Having DECLARATIVE(!) GUI, they gave up, saying "it's unportable" (WHAT!?!? I remember, it's DECLARATIVE thing, how the hell it become non-portable??). Brave M$ managers took open source project Xamarin (sorry, what?? Big company cannot write "portable WPF", but one enthusiast can?? ), renamed it to MAUI and presented it from their own name. THIS is the main scam point: completely unprofessional "home-made" Xamarin they present as "MS' made GUI"! TOTAL LIE. MAUI never was written by MS. Moreover: it's not (and never was) production ready. FOSS - it is not about quality at all! But MS keeps good face with poor game and continues to "fix on the fly" STREAM of found issues. Not even checking that Xamarin is architected properly. Just "home-made" library and bunch of mediocres in MS, trying to make it "work". THIS is what we name SCAM! |
Beta Was this translation helpful? Give feedback.
-
|
@LexaGV Well, name it whatever you want, but you are clearly clueless. Microsoft acquired Xamarin in 2016, when Xamarin.Forms were pretty much useless for any complex task. Since then they turned Xamarin.Forms into stable, polished and production ready platform. In 2020 they decided to change it into MAUI, completely rework its architecture and enable desktop development. The whole abstraction layer was overhauled into lighter handler based architecture. Loads of core mechanisms were also reworked, including meassuring, bindings etc. New features like Shell navigation and Dependency Injection were imlemented. Calling proffesional software engineers with in some cases over a decade of cross platform development experience "mediocres" creating "home-made library" speaks volumes about your judgement. |
Beta Was this translation helpful? Give feedback.
-
|
btw welcome to .NET 8 |
Beta Was this translation helpful? Give feedback.
-
|
Well, we've got .NET 8 and MAUI still has an incredible number of shortcomings. Things that worked "fine" in Xamarin.Forms just don't work in MAUI, even after rewriting code to conform to new and recommended paradigms. I wouldn't recommend that anyone build an app with this tech. |
Beta Was this translation helpful? Give feedback.
-
|
@Sebosek I completely agree with the sentiment of your post and support your right to vent at the substantial issues that we have with .NET Maui. I vent on a daily basis in fact! |
Beta Was this translation helpful? Give feedback.
-
Although relying on Microsoft too much is at least to me a bad way to do programming, to this day input in their webview can't handle a lot of text typed into it or the input is going to lag everytimes you type something, so you can't expect to finish your novel on your brand new application that's using BlazorWebView or Webview 1 2 3... Instead you find out in the end when you are almost finished with your app that there's a performance issue that removes the use case for your application |
Beta Was this translation helpful? Give feedback.
-
|
@Xyncgas not relying on Microsoft? hope you're using Linux! In fact worse; Linux is open source; they owe you nothing so you'd better write your own OS quickly! ;) |
Beta Was this translation helpful? Give feedback.
-
Wait... what? There's me paying Visual Studio license fees all these years, and you are getting it for free? How? |
Beta Was this translation helpful? Give feedback.
-
|
@williambuchanan2 , our company also pays huge amounts for VS Studio licenses and assistance. I think @janseris uses the community version which we cannot use in our company |
Beta Was this translation helpful? Give feedback.
-
|
@JohnHSE : I explained in details why it's scam in reply to @Vroomer. But I can repeat: Xamarin itself is not a scam, while it's presented as FOSS, made by enthusiasts. But once MS hide the name "Xamarin" and present GUI library as MAUI, company completely takes RESPONSIBILITY for design, architecture and quality of the code. Needless to say, how many bugs and "incompleteness" were found in Xamarin! So when MS says "you have .NET Core and can make GUI with MAUI", they simply LIE! Because MAUI/Xamarin never was properly designed and implemented for production use. Whatever "beta1", "beta2"... status you put on library, it will be "beta forever", since wasn't designed by professionals. That's why MAUI is a scam. It's "cork" in .NET platform just to say in public "we have GUI for .NET Core". Period. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think profanity is doing anyone a service but I do understand there's a lot of frustration pent up and certainly some miscommunication. Let's see if I can present my view in a comprehensive way. Me & my 2 colleagues we're coming from a former non-trivial Xamarin.Forms app. We have lots of Html&Javascripts to interact with (Hello HybridWebViewRenderer), need to support background-syncing of resources, need to display several documents in a tabbed view, need to switch between list- & grid-representations on-the-fly (Lots of DataTemplateSelectors) and much more... Gotcha #1: End of life for XamarinMay 2024 sounds like a lot of time is still left but that is only if you are content with the current target platforms ("Android 13 and Xcode 14 SDKs (iOS and iPadOS 16, macOS 13) will be the final versions Xamarin will target"). If iOS 17 or Android 14 break compatibility with Xamarin.Forms 5 for whatever reason, then good luck requesting a new service release. Gotcha #2: "production ready"?Ok, that one has been pointed out to death so let's summarize: Gotcha #3: Migration best practices?As I mentioned: We had/have a pretty complex app (Personal opinion: Anything more complex than a ToDo-app in Xamarin or Maui requires deviation from the standard templates) and couldn't really rely on any migration tools. Gotcha #4: RegressionsWith .Net 7 we finally felt like the framework was getting better. We had our own HybridWebViewHandler ready, got lots of the views to display something meaningful. Gotcha #5: So fix it yourself, you nagger. It's open source!Excellent point! And that I haven't succeeded at this is likely due to my lazyiness and/or incompetence. Gotcha #6: Dotnet... beta?From the recent PullRequests and monitoring the Service Releases it seems like .Net 7 is already considered stale and all improvements happen on .Net 8. In hindsight: I experienced a lot of helpful remarks in issues, discussions, blog posts, etc. and I see skillful people commiting to the project! |
Beta Was this translation helpful? Give feedback.
-
|
"From the recent PullRequests and monitoring the Service Releases it seems like .Net 7 is already considered stale and all improvements happen on .Net 8." This is something I only recently became aware of. .NET 7 is production, and yet any issues found are fixed in .NET 8 and back ported 'if deemed high importance'. Which means we could be waiting until November before seeing some fixes, even fixes for regressions that were introduced in .NET 7. I don't understand this at all. We cannot and will not release apps built against a beta .NET, and we cannot begin migration to a beta .NET. |
Beta Was this translation helpful? Give feedback.
-
|
i also feel must use net8 is very strange |
Beta Was this translation helpful? Give feedback.
-
|
Yes, where MAUI is concerned the .NET 6 to 7 to 8 story is strange in that it feels very fast. MAUI 6 was never a stable release and we avoided it on our team bar numerous experiments whilst we assessed its suitability. We're well within the MAUI 7 support window but it does feel like support is fading fast, as many important improvements and bug fixes are seemingly being saved for .NET 8 in November. It concerns me that the moment .NET 8 is released most new changes will begin to be targeted at .NET 9. |
Beta Was this translation helpful? Give feedback.
-
|
If you had used other technology for cross platform app you would've made 5 instead of 0 app |
Beta Was this translation helpful? Give feedback.
-
|
Well we have 2 production apps on Xamarin and 1 on MAUI today, so not 0 ;) then again, not 5 either to be fair. |
Beta Was this translation helpful? Give feedback.
-
|
I don't consider MAUI to be a scam, but I am a little disappointed that after three years since the blog post (https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/#mvu), there is still no official support for MVU or Comet framework(https://github.com/dotnet/Comet). |
Beta Was this translation helpful? Give feedback.
-
|
comet's developer have go to facebook, so official mvu have died |
Beta Was this translation helpful? Give feedback.
-
|
I‘d like to give some hope on Comet |
Beta Was this translation helpful? Give feedback.
-
|
Comet is dead, take a look at MauiReactor: https://github.com/adospace/reactorui-maui |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I agree MAUI doesn't fit the definition of a scam, but I do feel for the OP as our team has been in the same boat. Whilst the framework is financially free, you pay for it with your time - either as an individual or as a business. The reason many dev teams use a cross platform tool is to save time, especially those of us who are heavily invested in the .NET ecosystem. Having inaccurate or confusing statements from the project maintainers, bugs etc. can make people feel robbed of that time. Our team are in the late stages of porting a non-trivial Xamarin app over and overall I'd say MAUI works, and the fact it works at all is nothing short of a miracle. I dread to think of the complexity and number of man-hours that have gone into the glue layer between the native platform APIs and .NET and it's a feat of engineering they've got it working as well as they have. Despite my own complaints it has still saved our team countless hours we would've spent battling with native tooling and keeping multiple app versions at feature parity. That said, they did initially promote it as something it was not, which was much a product much less flawed than it actually is. This perception has led to misplaced expectation from developers and in turn lots of frustration, but I'd ask anyone reading this to stick with it as what I'm hearing more recently seems to be the right message. |
Beta Was this translation helpful? Give feedback.
-
|
or you can use progressive web app that runs on any platform |
Beta Was this translation helpful? Give feedback.
-
|
The impression we have of PWA apps is lack of lower level platform API and having to bring in reams of stuff just to render a button. Maybe that isn't the case and we should look more closely at it, but it feels like too much of a compromise to us to reduce the UI down to a set of essentially web pages. |
Beta Was this translation helpful? Give feedback.
-
|
In XAML I do There are pros and cons to every approach - would you write a 3D engine from the ground up to make a game? Some would, but many don't. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry for your experience. I've developed one app in Maui Blazor so I didn't encounter so many issues even tho I agree it's a struggle. I feel lucky to have witness this so early on in my career. |
Beta Was this translation helpful? Give feedback.
-
|
Blazor is a safe heaven because you are not using XAML and data binding the way they are using, also you don't have to deal with gesture control etc |
Beta Was this translation helpful? Give feedback.
-
|
It's not a scam, but it is an absolute shambles. It wouldn't be so bad if there was some kind of response or accountability from Microsoft, but it's like they are all asleep at the wheel, and nobody is around to wake them. |
Beta Was this translation helpful? Give feedback.
-
You make it sound easy, so can I get you to tell my CEO that all the work the entire team have done in the last 12 months has been a complete waste of time, and we're now just going to start again? That said - every day that goes by makes me think that is exactly what will happen... |
Beta Was this translation helpful? Give feedback.
-
|
I don't know what sounds easy, I just asked why you're using it? As I stated earlier, I am on your side but we can't expect that they put the whole resources into this one framework, it would be better for everybody but it's not the case. Maybe if Xamarin is discontinued and the support is dropped, the remaining developers switch over to MAUI. I just think that's how they will handle it, even though it's a bit late then. |
Beta Was this translation helpful? Give feedback.
-
|
I just don't want this thread to explode, summarized we all are not happy or satisfied. Microsoft should rethink how they handle the resources and put a lot more manpower into MAUI |
Beta Was this translation helpful? Give feedback.
-
The problem is that if you are doing everything in .NET, it's much easier to integrate .NET mobile app than any other mobile app. |
Beta Was this translation helpful? Give feedback.
-
As I elaborated earlier: We had a prior investment in Xamarin.Forms and a migration to a completely different technology stack would have been a substantial effort. |
Beta Was this translation helpful? Give feedback.
-
|
Q&A at Build 2023: https://www.youtube.com/watch?v=_IxzKLFNMWA |
Beta Was this translation helpful? Give feedback.
-
|
The video is private, what did you post? |
Beta Was this translation helpful? Give feedback.
-
|
Lol they hide the video as well. It was just. NET MAUI presentation on latest. NET Build conference - questions and answers session but I haven't watched much because in first 10 minutes they haven't said anything useful. |
Beta Was this translation helpful? Give feedback.
-
|
The second session with David and Maddy: https://youtu.be/arxsDF__uFA
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting, historically, voting for issues was applied only for feature requests and not for fixing bugs. Bugs should be fixed all |
Beta Was this translation helpful? Give feedback.
-
|
Nightly Maui nuget builds coming - that's what I was talking the other day lol That might help a lot |
Beta Was this translation helpful? Give feedback.
-
|
I totally understand your feelings and frustrations because currently MAUI does have a lot of bugs that need to be fixed before it can be really used in the production. IMO the current quality of MAUI doesn't meet the bar of "production-ready". It may suit for demo apps and prototypes but once you start to put it in real use, you will encounter endless issues including but not limited to memory leaking, binding bugs, slowness (though it may be due to the bad performance of mono and mono-aot), and AOT-related (especially while using AOT with LLVM, which is almost unusable) issues. It is also why I haven't use MAUI in my apps but instead choosing Avalonia or Xamarin.Forms. Microsoft really shouldn't have rushed a GA version of MAUI instead of baking it until the real mature. I even haven't mentioned about MVU/Comet because there are just too many fundamental issues before we can start to talk about patterns and features on a higher level. While the quality of MAUI does become better and better every year, so I would like to expect the next year MAUI in .NET 8 can finally meet the production-ready bar for extensive app development. |
Beta Was this translation helpful? Give feedback.
-
|
Seeing how all the issues are going and have been going so far, it's not possible that it just improves out of nowhere by November 2023 (.NET 8). |
Beta Was this translation helpful? Give feedback.
-
|
if MAUI is not stable in November 2023. I think that will be the end of this framework. It's their last chance |
Beta Was this translation helpful? Give feedback.
-
|
What I want to say is that no matter how good the tools are, there are projects that are not suitable. No matter how bad the tool is, there is a suitable position. Choose to use it, but not blindly. It is hoped that maui will speed up the repair speed, and at the same time, better optimization, blooming sunshine. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure why all the complaints with Maui. I've been using Xamarin since it first appeared over a decade ago and yes, after MS took it over the path got a little more rocky with each iteration. But having developed over 45 apps/platforms since the launch of Xamarin over the last decade+ (ios/android native, forms, and 3 new ones in Maui set to launch over the next 2 months), the biggest thing I've found with devs having issues is because many apps are "over-engineered". What I've seen is they try to throw in every code structure and methodology into every component of the app. Believe it or not, you can create an app that has some components that use MVVM and some that don't. Not every page needs a view model, dependency injection is great but if you don't plan it ahead it will be painful to implement properly (hence all those memory leaks everyone complains about). It's ok to let the back-end do some of the work (servers were designed to do the heavy lifting so the app doesn't need all the biz rules and algorithms inside). Sometimes you don't need layered services (save the "I" service implementations for another day - maybe you don't need the structure). Yes, MAUI has issues but so far, I've been able to work through every issue I've had with it in some way or another and not experiencing the many complaints that everyone is seeing. My biggest recommendation with Maui now is that before writing a single line of code, take a good look at the structure, architecture, and pre-plan ahead. Because as devs, once we start running with the code it gets hard for us to change direction. I'm guilty of this and have learned over the last 10 years that my best dev work comes when I've 80% planning and 20% coding. I wish it was something they taught in these bootcamps, coding classes, and videos. But they focus purely on the code aspect and functionality versus the "how", and "why" of doing something. So is MAUI a scam? No, not in my opinion. Does it take some work to make it "work"? Well, yes, start the coding with understanding what needs to be built and then answering the question "what's the best way to build it?" |
Beta Was this translation helpful? Give feedback.
-
|
Because for me I created a custom solution that can do things like having one or more rendering engine and you make request to the engine like open window or put this layer behind another one or whatever and the rendering engine does it for you while rendering the screen in parallel, without using Xmal, works with MAUI / MAUI.Blazor / truly cross platform |
Beta Was this translation helpful? Give feedback.
-
Actually, you make some valid points here. I've been guilty of this, and see it at work every day. I think going forward i'm just going to find workarounds rather than try to get things working like they are supposed to. That said, my main gripe is the lack of response or accountability from MS, which has lead to lots of lost hours. |
Beta Was this translation helpful? Give feedback.
-
You also said you have been able to work through many issues. Yes, we can definitely work around many issues, but shouldn't MAUI just work as it is supposed to? Many developers don't continuously check issues every day to see what workaround should be applied to what issue, and when it comes to a new developer, this will become a huge waste of hours. What's worse is that MAUI is quite new so the documents and answers to issues in forums (such as StackOverflow) are few, which makes it really hard to find those workarounds without hours of searching and experimenting. MAUI tends to be a native cross-platform GUI framework, but the most stable, polished and production-ready part of MAUI is using Blazor for a hybrid app which is actually running a web app and totally not native. What a shame. As I said above, MAUI is a great framework and it is actually improving every year. However, currently, the quality of MAUI just doesn't meet the bar of "production-ready" unless you want to use blazor-hybrid for a non-native app. I would like to expect MAUI to be a polished GUI framework in the future (maybe in .NET 8), but not now. |
Beta Was this translation helpful? Give feedback.
-
|
Do you know how demotivating and demeaning it is to work with this stuff? Instead of progressing with your work for the client you constantly need to fix broken things that should just work. Fighting with things that you know nothing about and shouldn't know anything about. Imagine if the String class was broken and you had to do some crazy workaround to make it work. Then you look to the side and see Flutter guys or native android/iOS devs having fun and working with no issues, occasionally complaining that the new SDK was only in 98% documented not 99%. That's career-questioning depressing sometimes... |
Beta Was this translation helpful? Give feedback.
-
You hit the nail on the head here. It is utterly demotivating. |
Beta Was this translation helpful? Give feedback.
-
|
A lot of features inside MAUI is tricky to use, for example the point of providing a bunch different component out of the box is for people not having to implement the wheels based on positions and dimension on screen and drawing the UI and handling input events themselves, but if you can't put a StackLayout Inside a ScrollLayout or things will break or many other situations that we are familiar with that's a mine field to walk through it is kinda counter productive. It's ok to provide options, but the way it's done was causing problem, look at the web you can put img in div or style the img directly nothing would go wrong you can put div in img too |
Beta Was this translation helpful? Give feedback.
-
Javascript. The difference is that in XAML databindings are a first class feature. Note syntax such as |
Beta Was this translation helpful? Give feedback.
-
|
data-* attribute is the equivilent, you can parse it like you can parse XAML {Binding} https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes |
Beta Was this translation helpful? Give feedback.
-
HTML is over-bloated and not very suit for UIElement rather than Document. HTML is not designed for template usage and its layout system is also not suited for GUI development. Not to mention the CSS styling system consists of non-orthogonal APIs and makes it a pain to work with layout and styling. If you have any experience with Angular/React/Vue/Svelte/Solidjs/Blazor, they are definitely not using the original HTML but a XAML-like templating system with a customized binding syntax. As for XAML vs HTML, I would like to use XAML rather than HTML. |
Beta Was this translation helpful? Give feedback.
-
|
XAML is not the problem, nor is the Binding system. It's the controls that are bugged as hell, and instead, they try to do everything else but fix them. |
Beta Was this translation helpful? Give feedback.
-
Nope. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
so you created new application using flutter, congratulations, better making something than making nothing |
Beta Was this translation helpful? Give feedback.
-
|
I feel your pain! |
Beta Was this translation helpful? Give feedback.
-
|
Calling it a scam is not appropriate. But I agree that it is still not production ready. And that Microsoft should have dedicated more development resources to it. Feels like people high up in Microsoft don't understand that one of their key assets is superior developer tools and technologies. Or they are under the delusion that "Blazor" and "Maui Blazor" means they have an adequate response to ReactJS/ReactNative and to Flutter. Nope. Personally, I pulled my current client out of both Maui and Xamarin Forms. Even though I pray that Maui eventually manages to become robust. We rolled our own UI, on top of Xamarin Native (will switch to .Net 8 cross-platform at some point). Similar to Uno Platform, AvaloniaUI, and Unity 3D, not to mention Flutter, we don't attempt to map to native controls on each platform. That way lies madness. SkiaSharp FTW. |
Beta Was this translation helpful? Give feedback.
-
|
Could not agree more, it's a shitty framework. It does not even properly check audio privileges, it simply relies on the OS (for iOS). What I've encountered so far does not display any kind of capacity for mid to enterprise level applications. It's basically Xamarin, which was shitty as well. I cannot understand why would a company like Microsoft would want to deal with the same problems even after the failure of Xamarin. MAUI still uses Xamarin libraries which in itself proves the stability will never arrive to MAUI. I'm sad that they do not choose a technology similar to Flutter. Even Microsoft has a lot of things to learn. I hate MAUI, would never suggest it, try to use Flutter which is far better on all aspects. |
Beta Was this translation helpful? Give feedback.
-
|
Is that an official, guaranteed endorsement that all Xamarin apps will continue working on the next OS versions? At least that makes the waiting time more worthwile, when .Net/MAUI 10 will maybe finally be as stable as Xamarin.Forms 5 used to be 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
I think the situation is this;
However...
Therefore I the official line is "get updated to MAUI ASAP or you cannot maintain your app". If you do not update your Xamarin app to MAUI you will be left in a situation where your app is on the store and runs, but you cannot submit updates anymore, in effect making your app somewhat "orphaned". The friction with the community is that many of us with existing production Xamarin apps are finding porting an uphill struggle as MAUI was released too early and has many showstopping bugs. The promise is that .NET 8 will resolve this situation but developers have to largely go on faith, as the two stable released (.NET 6 and .NET 7) are fairly woeful. For example, we've taken 9 months to port our main app from Xamarin and testers are reporting issues with the app just displaying a blank screen from time to time - we have traced it to a side effect of Android image loading being broken which was raised in March, fixed in .NET 8 in June and is pending a possible backport to .NET 7. This is the sort of thing that is making developers sweat and feels like being stuck between a rock (Xamarin EoL) and a hard place (MAUI issues). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the summary @RobTF. To complete, regarding Android. It will no longer be possible to update a Xamarin Forms app from August 2024. @davidortinau, timing is not possible for many compagnies. You should review the end of support date and accept Android 14. As said just before we are stuck between an end too close to Xamarin Forms and a still unfinished version of MAUI. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I think the real problem is we have all lost faith. I'm more inclined to believe the bad news than the good (not that there is much in the way of good news when it comes to Maui). |
Beta Was this translation helpful? Give feedback.
-
|
There is generally a cost to having faith, if a person speaking of problems to be address don't take it as making people lose faith in fact the person is helping the society to understand the cost for people to have faith, by not addressing the issues one may never pay the cost and by ignoring the issues one doesn't know where to pay the cost even if one intends to. Different people have different values, which means some loses faith more difficult than other, because we all have some fundamental value. For example components in MAUI being buggy is unacceptable to some people, xamarin support dropped might be unacceptable to mobile developers, for me I don't care because I use MAUI.Blazor so if there is anything that drives me stop using MAUI it might be how competing framework can produce smaller faster program that's more useful. A stronger belief was obvious good for marketing but it needs competency to respond to people who believes in you, saying you love linux but no visual studio on linux for example is ok but how do I know what you mean by you love linux is anything more than forking linux to make your own OS. It seems Microsoft needs to prove themselves with good product for example tool tips in Visual Studio to help one learn a 'Visual' langauge (C/C++, C#, F#, Basic) while a developer doing programming and using AI and documentations to point out "Hey, you can use System.Threading.Monitor here" is all you need to get back to the top and if making programming like playing a video game with new player tutorial is going to get a lot people liking Microsoft and reputation higher than other industry leader why couldn't they do it ten years ago |
Beta Was this translation helpful? Give feedback.
-
|
I feel like this page is full of "skill issue" and not acting high and mighty, I have faced issues with .NET MAUI and a lot of them, But not gonna lie Flutter is no different, You should be happy you were not a Flutter dev back in 2020-21 otherwise you would be writing about Flutter somewhere, it had bugs like adding images automatically rotated it randomly, image pickers did nothing and a lot more. All developers work with products that have issues in them, it's our job. |
Beta Was this translation helpful? Give feedback.
-
|
I am not entirely with you. Most of the things I faced as issues were problems that turned out to be a bug. I just remember when I turned the orientation of the Phone and layouts got damaged and even colors turned. Or let's take just .NET MAUI 8 were still the Switch is not handling On/Off-Colors correctly. We can't argue and say its just us and we are not mature enough to handle issues. There are certain expectations on basic things that have to work. Issues just in special cases. I also remember basic things like in a Flyout when the first Item could not be clicked anymore when you had a Flyout-Header. This for instance worked in .NET 7 without any problems. I could go on and on with things. The biggest problem right now is really not that there are more things supported for Windows or MacCatalyst, but that the basic things work reluctantly without problems all around. And the next problem is that when one issue is fixed you get the impression two new issues were introduced. In my opinion this is what get's this negative impression. Once the bug level decreases and it gets stable with all the things, I would imagine there are no more complaints. And just think of a company that has to pay their developers and they should try do their development around issues and find ways to solve an issue that is not their own one, that's a pretty damn thing to so and expect. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that MAUI has a lot more issues than you would expect but saying that it is unusable or just a SCAM is perhaps not the way to go, because if that's the case you should call out each and every framework similar to MAUI a scam for having the same issues. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately this isn't the case. Our team is well seasoned in MAUI and Xamarin before it. It is down to the skill of my team that we are able to use MAUI at all as they constantly need to understand the intricacies of how MAUI works well enough to work around the various problems, such as the following off the top of my head;
My team have had to put in multiple hacks/shims in both our application code as well as the build tools to keep things running. We have had to completely re-implement the carousel control on iOS but due to the gesture recognizers not working on Android with ScrollView we've had to work around the Android specific CarouselView bugs there. This is only possible becasue of the skill of the team and their understanding of the issues of the platform, not lack of skill. It's at the point where delays due to these issues are raised at board level and senior management meeting notes have occasionally contained Github links to issues so the wider business is aware of why the issues exist. We think MAUI is a valuable tool for the .NET ecosystem, but we do feel somewhat lied to that it is as production ready as stated, I think this is where the concept of "it's a scam" comes from - it's the vast difference between the Microsoft PR and the reality that people (developers) have a hard time reconciling. It feels as though Microsoft needs to send out representatives into the businesses using MAUI to understand the day-to-day issues as they seem somewhat ignorant or naïve about it. |
Beta Was this translation helpful? Give feedback.
-
Yea, I thought it's 'Observable', we all thought that's what Microsoft thought : We can all agree, that it's Microsoft who decided to use that name to imply an ability for them to observe it that's why you are required to bind an observable collection in the first place, so is it our fault when they seem incompetent to observe a collection with this interface which 99% times were using Microsoft's own implementation of collection under the hood, of course not, they would like you to think it's your fault, so you can put up with their tardiness in fixing their system, and who doesn't like the sound they make when they say it's open source and you are using it for free, which seems reasonable for the statement that usually comes next : Because you are using a free product you should expect no warranty of it and fix it yourself if anything goes wrong because you can, there was the question however which is was it truly free, as many people already answered it no it's not something Microsoft offered to people in the spirit of charity, it was advertised for development of an ecosystem for people to commit in, it painted a good future but it wasted many people's hours, false advertisement at the very least, some might even say a scam, and it was a scam due to the incompetence of the people managing this project, we can do their jobs better than them building a multi-platform UI framework, and we can refer to all the amazing frameworks we had already built, flutter for example allows a developer to present UI as pixels on a canvas therefore by supporting interaction of the canvas, various devices can interact with your applications. It's unsurprising to see Microsoft losing its creativity and soon the top dog of S&P 500 might belong to another company if this continues. |
Beta Was this translation helpful? Give feedback.
-
Here's my take on .Net MAUI As a professional developer of 20 years and having over 36 years programming experience, it's obvious our job is to implement, fix, improve and document our work… OUR WORK! However, I disagree with your statement of “skill issue.” (I'm assuming you're referring to general developers) when in fact it’s .Net MAUI not being fit for purpose. If you’ve ever developed in Xamarin Forms you would see instantly how bad MAUI really is as a product. To give you a comparison, it’s like being a web developer and having your website display perfectly in FireFox, Safari, Google Chrome, Opera etc… and having to do workarounds and even more workarounds for that website to display properly in Internet Explorer... to the point that developers placed an 'unsupported alert' to any users using IE. Yes, as a developer, it’s my job to find solutions to problems and to fix them. My job is not to fix the tool which is supposed to help me to do my job. |
Beta Was this translation helpful? Give feedback.
-
|
The biggest problem is really not MAUI is having a lot of bugs and do not compatible very well with Xamarin. The biggest issue is the date Microsoft mark the EOL for Xamarin, while they introduce new framework that do not even work as good as the old tool! MAUI teams should try their new tool with a really complex application, combining with MAUI + a lot of iOS Extensions for example. At this state, they don't even have an official guideline on how to implement iOS Extensions on MAUI, so how comes MAUI will be able to replace Xamarin.Forms with lack of support / tools and having a tons of bugs leftover? And the biggest issue with my "port" is the CollectionView, which is a very important control for most of the app, and it won't work well at all with complex layouts inside. What will we suppose to do when Xamarin EOL date is coming close and we don't have an alternative? If we choose to rewrite everything, we will just simply choose another framework like RN or Flutter, definitely we don't want to spend time with a framework that we no longer trust. Upgrading to a new version of the same framework (well maybe that's why they changed the name) shouldn't take a lot of effort like rebuilding an entire application again. Telling about myself, I used to work with various mobile frameworks such as Native iOS + Android / Flutter / RN, and i never face so many difficulties for custom controls / debugging comparing with while working with Xamarin (although i spend most of time working with Xamarin because of most of remote jobs). And i have to say that MAUI is now at even worse state than Xamarin. I appreciate the team that they are working on improving the architecture like introducing Handler / Declarative UI / Blazor, etc .... |
Beta Was this translation helpful? Give feedback.
-
I think that's because they're moving to new packages, and namings. As it was answered |
Beta Was this translation helpful? Give feedback.
-
|
@ziomek64 in the case of Xamarin it looks like nothing will happen as it stands today!!. |
Beta Was this translation helpful? Give feedback.
-
|
@developer9969 they just released support for to build Xamarin on Android SDK 34 and Xcode 15, so i think we have at least 1 year now. Bad news is on azure devops, the macOS-13 doesn't support xcode 15, which sucks. So in this time, we either have to use our own agent or building it manually locally |
Beta Was this translation helpful? Give feedback.
-
|
@huyvuskedulo is there an official link we can look at thanks |
Beta Was this translation helpful? Give feedback.
-
|
@developer9969 https://devblogs.microsoft.com/dotnet/announcing-dotnet-maui-in-dotnet-8-rc-2/#bonus-2-xcode-15-and-android-api-34 They released it couple months ago. And I'm still able to build Xamarin apps in Xcode 15, so can confirm it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a solo developer, very experienced, I have 2 patents and an ICP million-in-one award. I was able to get my first app working and distributed on Android and iOS, and expect windows this spring. Moderate complexity, not trivial but not pushing the envelope at all It was very difficult. Things not working for no apparent reason, some issues took me a week to figure out, some things I had to redesign around, debugging 3 times for windows then android then iOS. Many hours online searching for resolutions to issues. I developed on Windows then transitioned to android, then to iOS. I had to carefully retest everything using a detailed test plan for each environment, and for both light and dark theme. Not what I wanted to do but going thru end-to-end testing many times made it a better app. I'm about to implement notifications and images so these items noted by RobTF are scary: |
Beta Was this translation helpful? Give feedback.
-
|
@DaveBrask if you'd like any conversations on these items offline just drop me a PM. It would be useful to swap ideas with someone like yourself. |
Beta Was this translation helpful? Give feedback.
-
|
Github should implement End-to-End PM directly in the comment sessions |
Beta Was this translation helpful? Give feedback.
-
|
We did a bigger project for a customer using Maui native. So far, ok, we are still stuck at 7.059 because of later bugs - and there are a lot of them. The app is available in the Apple App-Store and on Google Play. We have more than 10k users and there are only a few problems. |
Beta Was this translation helpful? Give feedback.
-
|
I think. NET MAUI hybrid is the only way to continue at this point. Microsoft can go on fighting with the bugs in the native cross-platform controls for the next few years. Maybe we'll get a stable framework within 3-5 years. Maybe not. By that time, everyone would have lost interest, moving on to other UI frameworks, possibly leaving the .NET stack entirely. History tends to repeat itself. Let me remind you of other popular technologies like Java and Delphi that tried the same cross-platform native approach in the past, only to abandon it at some point, to replace it with their own rendering. This is what Flutter and Qt are currently doing (and some third-party .NET UI frameworks) and what .NET MAUI could do from the start, but it is too late now. The next best thing is to rely on the browser to do essentially the same. Not ideal, but at least it relieves Microsoft from having to implement their own rendering. There is also the added benefit of attracting people from the largest developer ecosystem - Web, who are not necessarily interested in .NET. That would also make it possible to add more platforms later, like Linux, at a minimal cost. The only downside, the way I see it, is for people who absolutely refuse to learn or use HTML/CSS, but they are a minority these days. |
Beta Was this translation helpful? Give feedback.
-
|
Yea web app already is good enough |
Beta Was this translation helpful? Give feedback.
-
We gotta convince people HTML is basically byte codes because browser is really fast, you can change these HTML and the 'virtual machine' the browser is can interpret these code to do things, that're difficult for people to do them from scratch (pixel by pixel):
|
Beta Was this translation helpful? Give feedback.
-
Except it uses Javascript to manipulate the visual tree and that is hell slow. HTML is nothing like byte code. That would be WebAssembly. |
Beta Was this translation helpful? Give feedback.
-
|
We can manipulate dom from Webassembly soon, but to the point of 'HTML is basically byte codes', in my opinion it's because browser use SIMD-Processing for parsing text so its performance is close to byte codes I agree native capabilities attract people's attentions, because it's an important feature for people to use. Yet the native capabilities is separate from the way MAUI choose to be an UI framework by using native controls, for example people can have these capabilities in hybrid setup by using browser (webview) to present their content, while still having access to native capabilities in for example Blazor's 'Code Behind' because .NET is running natively with this option |
Beta Was this translation helpful? Give feedback.
-
|
My problem with using HTML over native widgets is;
There are massive advantages to XAML, which was designed for application front ends from the ground up. XAML however is just a markup language, its real power comes from the tools that support it. WPF is evidence of just how well this can work as WPF is absolutely fantastic - Microsoft did an amazing job on WPF and on the whole it was a huge improvement over WinForms and pretty much everything else at the time. The problem with MAUI is they have not got the tooling into a place where developers can work as cleanly as they can with something like WPF, which causes the dev loop to be extremely long and the runtime is full of bugs partly because they've tried to overgeneralise things without taking the time to fully take into account each platforms idiosyncrasies. Adding yet more platforms as part of the Xamarin -> MAUI migration has just made this worse. |
Beta Was this translation helpful? Give feedback.
-
|
I'd try to choose a point you made to discuss :
XAML for building applications is putting certain benefits on the table when combine with the frameworks we have now that use it : Native controls, on the platforms it's running, out of the box But I do not consider applications adhering to the platform's 'looks and feels' mandatory, and the frameworks offered that use XAML currently doesn't let me manipulate it as easily as it would manipulating HTML DOM in javascript, I doubt it would be helpful to the applications that wants to be as expressive as to the extend of freedom you have when using web application's approach Overall the stance I have on XAML are :
|
Beta Was this translation helpful? Give feedback.
-
Perhaps not mandatory, but I'm sure Apple/Microsoft/Google have spent $$$ in R&D getting things right whereas the custom UI widgets in the latest novelty app for viewing cat photos probably hasn't. |
Beta Was this translation helpful? Give feedback.
-
There are also massive disadvantages to XAML, like it being a whole new thing to work or the fact that it incentivizes enormous ammounts of data sharing and sticking with things like MVVM instead of allowing the construction of dynamic and interactive UI's. For anything but a corporate software it is a pain to work with. |
Beta Was this translation helpful? Give feedback.
-
|
I'm feeling stupid, I am wrong, I should reconsider how I can write an application without writing XAML using it |
Beta Was this translation helpful? Give feedback.
-
|
XAML is a meta-language that lets you instantiate objects and set their properties. It has a 1:1 translation to C# code (or F# or VB.net, per your pleasure). |
Beta Was this translation helpful? Give feedback.
-
Trouble is there is so little documentation on avoiding xml. I just use a lot of trial and error unfortunately. |
Beta Was this translation helpful? Give feedback.
-
You can basically convert XAML 1:1 to any other layout definition language, sometimes with a few adjustments. Structurally, it can be converted back and forth to JSX. That said, XAML doesn't need to be as bulky or restrictive as it once was. It worked fine 15-16 years ago when WPF was released, but it no longer meets modern UI/UX development standards. Of course, it's still convenient for some older developers who want to rely on students' knowledge until their retirement. But just look at how much C# has evolved over the years. I've been writing in C# since 2009 and started developing mobile apps for Windows Phone (and other Windows platforms) in 2014-15. I switched to React Native after seeing and experiencing the slow progress of MAUI last year, and I have no regrets. Of course, I now face different challenges, but none are as frustrating as those I encountered with Xamarin Forms. I would love to see the React Native UI paradigm integrated into Microsoft's project infrastructure and ecosystem—especially the ability to continue using C#/DLLs/NuGet packages, etc. It's ironic that Microsoft has never managed to deliver commercial-grade (*) applications based on Xamarin Forms/MAUI. Most, if not all, of their products are built using native code or a mix of web technologies, including React (Native). It’s clear that management is out of sync with developers and other technical staff who could provide proper requirements before developing a new stack. The same misalignment happened with Windows Phone (Mobile) and is now happening with Boeing. (*)—It's worth noting that when I refer to commercial-grade applications, I'm not talking about apps with simple layouts, a few pages, and a login screen with a menu. While those types of applications may work fine for certain use cases, they don't fully showcase the capabilities of a robust development stack. So, when someone says, "I have an app and it's working fine," I acknowledge that, but I’ve seen and worked on many similar apps myself, especially during my time developing for Windows Phone in 2015-2016. |
Beta Was this translation helpful? Give feedback.
-
|
@bondarenkod can you elaborate on "XAML no longer meets modern UI/UX development standards"? |
Beta Was this translation helpful? Give feedback.
-
|
Does Microsoft use MAUI in any of its products? |
Beta Was this translation helpful? Give feedback.
-
|
The Azure mobile app is built using MAUI. |
Beta Was this translation helpful? Give feedback.
-
|
Can you post a link to sources |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't matter |
Beta Was this translation helpful? Give feedback.
-
|
We asked this a couple of times before and the conclusion is "yes they do" although not on anything you'd call mainstream. The biggest is probably the Azure app, but despite it's name making it sound important the app is pretty basic in terms of functionality. I can't see them porting something like Teams, for example, as they'd likely never get it stable enough for production. I'd seriously love to be proven wrong on that last point! |
Beta Was this translation helpful? Give feedback.
-
|
The Azure mobile app is listed here: https://dotnet.microsoft.com/platform/customers/maui and we're actively working right now to get more stories on here, so stay tuned! Additionally, during .NET Conf (and some other events since then), a couple more Microsoft products were pointed out. |
Beta Was this translation helpful? Give feedback.
-
|
I just want to say that MAUI + Blazor is not bad. |
Beta Was this translation helpful? Give feedback.
-
|
Yea you literally are writing an app that can be deployed to
|
Beta Was this translation helpful? Give feedback.
-
|
To get started using photino instead of MAUI for blazor so you can run your app on Linux / MacOS / Windows |
Beta Was this translation helpful? Give feedback.
-
|
maui is the best 👍 |
Beta Was this translation helpful? Give feedback.
-
|
It sounds like you have experience with a wide range of tech stacks. Aside from the one you’ve mentioned like MAUI (probably, Xamarin Forms), have you worked with other stacks or platforms and for how long? |
Beta Was this translation helpful? Give feedback.
-
|
@davidortinau Is it maybe time to close this discussion? It keeps getting pushed to the top without any real new insights. |
Beta Was this translation helpful? Give feedback.
-
|
Before this discussion gets closed, I would like to add that my experience with Maui has been pleasant and I really like it. I think with .Net 8, things have been lot better. Last week I launched my app "Notezilla" successfully on both Play Store and App Store. Thanks to the generous community. I hope Microsoft keeps the same attitude and improves WinUI 3 too at much faster rate. |
Beta Was this translation helpful? Give feedback.
-
|
I'm pleased to see reports that our efforts and investments are recognized, and success is being achieved using .NET MAUI. I'm closing this thread as it seems to have run its course. We welcome constructive criticism as it is often the best feedback for guiding our future investments. Please do continue to share both reports with us, and keep in mind the https://dotnetfoundation.org/about/policies/code-of-conduct. |
Beta Was this translation helpful? Give feedback.
and others
-
I tried Dotnet MAUI in version 6 for the first time, but back then I decided to go back and backport back the application in Xamarin.Forms. I've released the app in Xamarin, does the app suffer from the fact it was written using the Xamarin.Forms? No. Not at all. Sometimes it only required more typing, because I'm used to relying on the dependency injection and writing unit tests and Xamarin.Form is full of static calls, so I have to wrap it.
A little bit of background about myself, I'm a contractor, working with from small fintech startups to global tech companies and banks, but from time to time I'm helping non-profit organizations for pro-bono. I've worked on several such projects, usually for a couple of months, and then a little bit of maintenance. I've developed 2 apps in Xamarin.Forms and one React Native. The React Native base was the bigger so far. For the current project, I've decided to give a shot MAUI for the second time. I did a prototype, to verify that the required features are supported (Lottie animations, local notifications, database, ...). Sure, my prototypes worked, it wasn't perfect, but it somehow worked (the first warning sign, #14911), so I prepared CI/CD for the project, agreed with the client, and finally started working on implementation.
The application is very simple, with a very simple design.
Regarding the custom navigation, I was a little bit worried, and after reading the documentation about Shell navigation I got the feeling like, it would be quite problematic to use it with my navigation, so I gave it a day and a half and create my own including the animation, it worked like a charm until I hit the wall for the first time. The data binding between View and ViewModel does work only for buttons, using gesture recognizers it just does not work, #15147.
Along the way, I also found that the border control is broken on Android and it renders 1px space around, so the green background is visible on edges, but it was already reported and planned for a fix in version 8, a second warning sign.
I tried a different approach, using the Shell. It "worked", but the animation does not. I should describe the animation, once you tap on the icon, the active page (the one with the green color and title in the menu) becomes blackish and slowly hide the text (text width becomes 0) on changing the page and the icon for a new active page becomes green and shows the title. The animations were broken by changing the page. You can't put in the shell something other than page content, so every page has to have the same menu control. Bummer.
What other options do I have... After some research, I found, that some ppl are using Carousal View and I was like: "Oh, why I haven't occurred to me before." I was a little bit ashamed of myself.
So, I created the DataTemplateSelector, and prepare views, the menu worked, and the animations worked, but the data binding in views are completely broken. Even the controls aren't bound to the view model properties, it is just completely broken. Kick into the face.
I'm losing hope, but let's it take from a different angle, let's create an observable collection with content views and render them in the content view in the carousal view, similarly for the very first attempt. IllegalStateException. Kict into the nuts.
Let's use the Content presented, exactly like the very first attempt. IllegalStateException. What the hell?!
I'm giving up.
💩
Beta Was this translation helpful? Give feedback.
All reactions