Replies: 56 comments 206 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.
-
@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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Q&A at Build 2023: https://www.youtube.com/watch?v=_IxzKLFNMWA |
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.
-
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.
-
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.
-
|
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.
-
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.
-
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.
-
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'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.
-
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.
-
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.
-
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.
-
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.
-
Does Microsoft use MAUI in any of its products? |
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.
-
maui is the best 👍 |
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.
-
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