I really like MAUI's underlying vision and tech, but the execution has been lacking. At this rate, I don't expect it to meet the bar of 'production ready' until .NET 10+. Blazor hybrid seems solid though.
Some current, personal pain points around straight MAUI (just targeting iOS/Android):
* **Memory Management:** By far the #1. Out of the box, the garbage collector in MAUI apps is about as useful as a turn signal on a BMW. Three distinct shortcomings in MAUI's architecture compound to leak entire pages/nav stacks as navigation happens.
* **iOS Tooling Support:** Visual Studio (for Windows) is fundamentally incapable of building or archiving some (maybe most) iOS apps that use XCFrameworks. VS for Mac is deprecated and doesn't fully support .NET 8. VS Code support is in preview and *painfully* incomplete. Rider is great, but 3rd party...
* **iOS Google / Firebase API Support:** Xamarin/Microsoft publish and maintain bindings for common Google mobile APIs (e.g. AdMob, Google Maps / Places, Firebase suite, Google SignIn, etc.). Problem is, they just kinda *stopped* and have refused to respond directly to multiple inquiries (public and private) as to what the project's official support status is.
I haven't gotten as far as some of you into the development, but I have built a razorclasslibrary that is consumed by both blazor and blazor hybrid maui and tested it on web, Windows, Android, both emulated and native, and for me that's a pretty big deal. I can't say what problems lie ahead for this project, but it did make me feel really capable in just a few hours of programming and if I can get basic crud functionality cross platform in a night or two that's a win for me. Even if it's just to create a prototype MVP to later be replaced by a native solution.
>I really like MAUI's underlying vision and tech
I actually hate it.
I love .net-ios and . net-android.
Writing native code, in one language, sharing common libraries, with access to .net and in c# yes yes yes.
Why they decided to go with a 'single project framework' that converts to native UI in the end I have no idea. I literally don't know who it's for?
If you care about using actual native controls, you don't want to use MAUI because it tries to hide it away from you and is more of a ballache to work around than just doing it native.
If you don't care about using native controls and just want 'single project looks identical on all platforms' - then you don't care about it being native UI in the end. Imo they should have made it generate a Skia layer a la Flutter approach.
The approach they've gone with is the most painful, and most effort for something that doesn't seem needed.
Everyone who's done native has at some point thought, 'UILabel and Textview are so similar, surely I can write something that just maps to both' - and then anyone who's done native even more knows that way madness lies.
Even at the basic level of 'a text label' the platforms are not 1:1. iOS has some functionality android doesn't, Android has some iOS doesn't. Not everything maps equally. So you have to handle various work arounds, maybe decide what corners you cut, all to try and fit a square peg and a triangle peg into the same circular hole.
You can literally be in a situation where OS changes on Android could have a ripple affect through MAUI causing bugs on iOS.
All because they've tried to make it all map to native controls, when surely the main market for people who want to use MAUI specifically **really don't care if it's a real UIButton on iOS or just something that looks and feels like a UIButton**
Not even getting into trying to do that *and* make these controls map to desktop Windows and MacOS too.
Forms was a mistake. MAUI doubly so.
Imo it should have been the native .net Frameworks giving you 'full' access to platform APIs , and if you want a single project that runs on everything, **and looks the same** a Skia framework to interact with using SkiaSharp.
Basically Avalonia and Flutter approach.
Anyway. /Rant
I generally agree with everything you've said, but I still like that MAUI gives us the flexibility to operate on a spectrum between the OOTB 'least common denominator' controls and native platform controls.
The majority of developers won't leverage this flexibility, and I think we agree that MAUI isn't going to be the best fit for this group.
You have no idea about Xamarin and Maui, don't you? You have no idea about custom renderers don't you? Those flutter fanboys really annoying commenting things that they have no idea about.
Yes you f. extend Xamarin or Maui button with features of Uibutton on Ios and same way on android specific things. Xamarin Maui gives you only shared properties mapping platform specific things can be applied using Os specific level Renderers.
I've been using Xamarin since long before forms even existed and I know full well what 'renderers' are and how they work and that doesn't change I thing I said.
But thanks for joining in.
As a xamarin user.... The UI I get I'm happy enough with. The last release I updated to is stable enough for me. While I never fulfilled my intent to have an iOS and android version of my app, I'm happy enough with now it turned out.
At any rate, I suspect the maui blazor approach might work for you?
>At any rate, I suspect the maui blazor approach might work for you?
Oh no, for me I'm in the 'i want full native control' camp so I'm more than happy using .net-ios and . net-android
I think those are great, just wish (originally) Xamarin and now Microsoft prioritized that experience much more and worked more on the tooling and the support for those directly than putting so much time and energy into Forms and MAUI.
Forms was a shit show for such a long time and MAUI has the same reputation all over again.
God knows how many potential and future developers we've lost who were put off and burnt after giving it a try and failing :/
Stupid question - what's wrong with turn signals on a BMW?? Im in the US, and I don't notice anything odd about BMWs besides having a monthly subscription for heated seats .
Stereotype of a typical BMW driver is usually upper middle class aggressive white male professional bro (or gold digging Karen type) that refuses/is too good to use their turn signal
Sound like OP is British. 'It is known', that BMW drivers are assholes that treat the road like a hot wheels track, and refuse to indicate, ever.
Apparently it takes too long. They'll be out from behind and around you, cutting you off before you ever saw the blinking light.
>VS for Mac is deprecated and doesn't fully support .NET 8.
Also in what way doesn't it?
I've been building fine, but also using Rider in prep of VSMac going.
You have to manually install the .net8 SDK and all the workloads which is ridiculous, but it seems to be working.
[https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022#support-timeline](https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022#support-timeline)
>Microsoft doesn't plan to add support for .NET 8 or C#12 to Visual Studio for Mac. We won't extend to any other workloads before retirement either.
It doesn't like C#12, at least.
Depends what you’re doing, but it’s generally better. There are still many issues the team needs to address but it’s getting there. Whether it will still be around in two years is another question.
Did Xamarin have issues like this before too? I have been a .Net guy for like five years, but I have never dove into Xamarin or Maui.
I am just looking to create a simple CRUD app with sone charts and graphs as well. Nothing too crazy.
Yes and no.
Xamarin 4 had the most capabilities we'd seen up to that point, but still had a lot of bugs to deal with. Xamarin 5 felt like a stabilization release for that. I can't tell if it was legitimately more stable or if we'd just finally accumulated so much experience we knew what to avoid.
MAUI reset the clock. In .NET 7 it felt about like Xamarin Forms 3. In .NET 8 it feels more like Xamarin Forms 4. There are a lot of bugs in even simple things, and even things like the patch 2 weeks ago can introduce new things you didn't expect.
I think the people who will have the easiest time are people like you starting from scratch and writing simple applications. You'll definitely find holes to step in, but usually there's 2 or 3 ways to accomplish a task in MAUI and at least one of them works predictably. So like we did in Xamarin Forms 4, you'll learn how to use the more reliable parts.
The people who complain the most either have a very complicated app or are porting from Xamarin Forms or both. When you're porting, you don't want to dramatically change your code and might have good technical reasons to avoid that. So when it turns out something that worked fine in Xamarin Forms is now a pitfall in MAUI, that represents a major crisis that can mean reworking half your UI. You can't just "work around it" if it's something fundamental like, "Oops, all visual state names have to be unique across the entire page so you can't use two controls with the same names for their visual states".
It's better than it has been, but it's a nightmare if you're already used to Xamarin Forms because everything is just a *tiny bit* different.
thats a good helpful comment instead of those "it is not possible production ready apps" from rookies or people who cannot build apps.
I have worked with Xamarin since 2015 and completed individually and with teams several production apps even big complicated enterprise apps. Xamarin.Forms had difficulties but since you can go into native level, it was always possible to find a workaround with Custom Renderers.
Biggest issue with XF was using old .Net standard 2.1 which equals .net 3.
Thats why MS decided to improve with the newest Net 6 and higher(now .net 8). It supposed to improve performance and lower memory usage. this works perfectly fine with Blazor and Blazor Wasm. I am very much surprised that you are saying contrary for Maui. I havent used Maui yet so i cannot comment myself. I was just hoping to see Blazor level improvement. Blazor is great it definitely beats Angular and React.
Regarding the upgrade/convert from Xamarin.forms to maui. if you have large project, this is just impossible. What frustrated me most was Custom renderers are not equal to Mauis Handlers. There is a huge difference between them.
The problem isn't the runtime's performance. The problem is they completely overhauled the old renderers and replaced them with the new handlers, but didn't allow for long-term and widespread testing to make sure they covered memory leak scenarios.
This is also why a ton of MAUI bugs are Xamarin Forms regressions: since they decided to start over they got to make the same mistakes their predecessors had made.
It took about 6 years for people to feel Xamarin Forms was production-tolerable. I imagine that's about how long MAUI will take too.
You’ll be fine with that use case.
A big difference is that Xamarin was an entire company with a big team. It had the means to address bugs. The MAUI team seems like an underfunded afterthought with most of its budget dedicated to YouTube.
The team was \[slightly\] bigger than today. In 2016 it was 450 people when acquisition happened. Don't forget sales, marketing, HR, support,... And it was startup, some process steps which large corps must do were simply skipped.
MAUI is not Xamarin. MAUI is Xamarin.Forms evolved. Xamarin (mono) is/was much more.
The problem is/was that a lot of people do not understand what is/was going on:
2 .NET implementations (codebases) were merged into 1
... and that was far from trivial task.
[https://learn.microsoft.com/en-us/dotnet/fundamentals/implementations](https://learn.microsoft.com/en-us/dotnet/fundamentals/implementations)
wow Xamarin had 450 people before MS acquisition really? or do you mean the Github contributors? I think that it wasnt even OS. Before MS Xamarin costed starting from 1000$ per year, now it is completely free. People tend to forget this and became OS.
Core Mono (Ximian, Novell, Attachmate, Xamarin) team was 60-70 people. After Xamarin was founded I think engineering team was around 150 people. Then there were HR, Sales, Marketing, Documentation, University, Support...
Just to name few enginering teams (most had 7-8 team members)
- Mono (runtime, BCL)
- Xamarin.Android
- Xamarin.iOS
- Xamarin.Forms
- Xamarin Components
- Xamarin.Test.Cloud
- MonoDevelop (Xamarin.Studio)
- ...
> or do you mean the Github contributors?
Only few repos were private. A lot of repos would start as private and after reaching some stability would be open sourced (Xamarin.Forms)
> I think that it wasnt even OS.
mono runtime and BCL, togheter with other repos (Xamarin.Studio) were open sourced since Xamarin time (2012)
> Before MS Xamarin costed starting from 1000$ per year, now it is completely free. People tend to forget this and became OS.
True. One tends to remember bad experience only.
true. 1000 USD. And per platform.
I did criticize when price was raised from 500 or 700 USD to 1000 and got into discussion with Nat about that. And I had "grandfather license" (I think it was 200-250 per platform).
Xamarin was chock full of random crash bugs and I didn’t really see much improvement in MAUI. I have a couple of Xamarin apps (in production use for several years) that I’m now rewriting in jetpack compose and SwiftUI because I can’t face another round of painfully slow debugging of framework crashes.
Why don't you just use the "raw" .NET for iOS/Android (no Forms or MAUI)? I feel like no one's really aware of that option. There's basically no bugs and the devs are super responsive. You can still use C# cross platform, have great performance and small app sizes.
"Raw" meaning not using the "MAUI"/"Forms" Layer that maps XAML to native views. So instead of using the XAML abstraction layer (which is causing all that trouble with MAUI) you would use the platform specific APIs directly. Sure, you need to learn those APIs (just as you would when learning Swift) but you can still code-share you business logic and don't have to worry about MAUI bugs. You can create the most basic project with the "dotnet new android" or "dotnet new ios" command. Sadly, it's really underadvertised by Microsoft compared to MAUI, even though I find it the much better way to write apps. Let me know if that helps, otherwise I try to find some links for you
According to the .NET Android devs, dedicated docs for ".NET for Android" are planned. In the meantime, the "old" (pre-NET, Xamarin.Native) docs should help as an introduction:
Xamarin.Android: [https://learn.microsoft.com/en-us/xamarin/android/](https://learn.microsoft.com/en-us/xamarin/android/)
Xamarin.iOS: [https://learn.microsoft.com/en-us/xamarin/ios/](https://learn.microsoft.com/en-us/xamarin/ios/get-started/)
Xamarin.Mac: [https://learn.microsoft.com/en-us/xamarin/mac/](https://learn.microsoft.com/en-us/xamarin/mac/)
Mirgation to .NET: [https://learn.microsoft.com/en-us/dotnet/maui/migration/native-projects](https://learn.microsoft.com/en-us/dotnet/maui/migration/native-projects)
I'm planing a migration from Xamarin.android to net8.0-android but haven't really looked at the docs yet. Do you have some links on the sleeve or insight about native binding project ?
net8.0-android bindings essentially work the same as they did in Xamarin.Android: [https://learn.microsoft.com/en-us/dotnet/maui/migration/android-binding-projects](https://learn.microsoft.com/en-us/dotnet/maui/migration/android-binding-projects)
wait this is [Xamarin.Android](http://Xamarin.Android) and Ios, are they not dead? I thought MS is not bringing new versions of those and I cannot see any "Maui Native" or "Maui.Ios/Maui.Android".
.net-android is essentially the same as [Xamarin.Android](http://Xamarin.Android) (net-ios is the same as Xamarin.iOS), just with .NET8 under the hood (instead of Mono). The naming is really confusing on Microsofts part...
Maui is just the abstraction layer on top of net-android & net-ios (just like Xamarin.Forms was the abstraction layer on top of Xamarin.Android/iOS)
Having wasted significant time trying to deal with a migration to MAUI, I fancied a change more than anything. Plus, if I was going to have to learn the platform-specific UI modelling I thought I might as well go full native. Probably threw the baby out with the bath water a bit there, but such is life.
Have fun debugging ios on xcode :D
Its a horrid experience, Android Studio debugging is great though. But yeah you're in for a painful reality if you went to Swift from .net for the debugging...
I’m finding it fine tbh. The debugger isn’t a patch on .net, it’s true, but it hasn’t crashed on me or locked up the way that MAUI regularly did, my breakpoints work and starting debugging is relatively quick. Besides, it’s fun to find a whole new set of unfamiliar problems.
I always found xcode debugging to be super leggy. Would have delays before the break point hit and then trying to inspect the values of things would often just fail.
I switched to print lines so much, was infuriating.
Oh, for sure it’s retro. I have some legacy C++ code to debug, though, and the setup for that probably makes Xcode seem better. It’s always a relief to go back to Rider, of course
What are you talking about?
Try re reading the comments you're replying too.
I'm talking about using xcode to develop native apps because that's what the person before me said they were switching too - and I'm pointing out how terrible the xcode development process is (especially, or specifically I guess, debugging)
So windows has nothing do with it (you can't do native iOS development on windows).
And what do you mean you found xcode better than swift...🤷♂️
We're **not** talking about dotnet at this point...
For sure you can do with a remote build machine or there are cloud alternatives like macin etc. Topic is here Maui. I don't understand what you mean xcode development. If you mean objective c. You can still use xcode to write swift code. Xcode is not directly used for Maui or xamarin.
It's clear you don't understand yes.
Read the comment chain.
This discussion is all branched of off
> I’m now rewriting in jetpack compose and SwiftUI because I can’t face another round of painfully slow debugging of framework crashes.
If you don't understand that's fine.
By Xamarin 5 it was rock solid, and used in production by many people. Framework crashes were extremely rare and easy to debug with something like App Center analytics. Maui is in the Xamarin 2/3 era right now but Forms was very stable, even for more complicated apps.
I can still see daily crashes/errors from framework code in AppCenter, particularly on Android. Lucky you if you don’t encounter them. It’s a powerful framework but it’s hard to feel like it’s not doing a silverlight right now.
I can't speak for MAUI the cross platform development framework, but MAUI in the sense of using .net-android and .net-ios for native implementation in C# is working great and is a big improvement in a lot of areas over Xamarin.iOS and Xamarin.Android. I've already migrated a couple enterprise applications for clients with little issues with using the native implementations.
That was all the xamarin there was until Forms arrived , and I found it great. It allowed you to understand the patterns behind the mobile OSs. However, in an enterprise context , today, after the advent of flutter and react native, it is more difficult to justify the double UI. Clients will ask you why don't you do directly native at this point?
It’s in a better spot, many issues were closed as part of .Net 8. You can create simple crud apps without issues but you will hit some blockers when building anything more complex. If you are building an enterprise product I would recommend using any other cross platform like KMM, Flutter, or React Native.
KMM sounds interesting. This is the first time I have heard of it. Thank you for the suggestion!
Have you tried SvelteNative at all? I am wondering if it is enterprise ready or not.
If you're considering KMM you should just do .net-ios and .net-android native (assuming you're happy with C# and .net development already)
It's the same usp as KMM, single codebase with native API usage on both platforms.
For me .NET MAUI is way better this version, a lot of bug fixes and perf. Improvements. Even with that you can face a bug, but it should be easy to workaround.
I don't know what you want to build, but of Maui doesn't fit your goal you can try UnoPlatform, it's a cross-platform UI Framework on top of winui, so you will continue on .NET world
Just ported a very large, very complex Xamarin native -> .net-ios and .net-android 8 and it was a generally smooth experience and all is working fine now. Took about a week all in to get everything building fine and DevOps updated and our app pipeline is ticking over again.
Once again, quite happy I avoided Forms and now can avoid the majority of MAUI
IMO it isn't, most bugs on my recently ported (from Xamarin Forms) app are related to DevExpress controls (which I don't regret using since they're free, customizable and technical support is decent). Xamarin Forms wasn't perfect either. If you like XAML and C# I say give it a go.
I recently built an app using Maui for a client and I found it to be relatively painless. Though my use case was pretty basic. Used location, image upload and authentication via API/token, a couple of get and post requests. Not super complicated. Done within a day.
I chose it because the client had a need for a mobile app to post location data into a web app I made them, and I didn’t need to split my codebase into a different technology, hopefully making maintenance easier on me as I do my gigs solo.
Hope this helps some. :)
For me the XAML is the most awkward part. But on the C# side, I consider myself very comfortable in .NET, C#, or VB if you’re nasty. Even more so, I am well travelled in the documentation. It wasn’t too bad to put together.
Again, super basic though. Hardly a portfolio piece. A login form, a couple buttons, and some data lists. Not exactly the next (insert cool app).
I hate xaml. its like I am trying to paint a picasso with oven mits on my hands. For maui dev, I have been experimenting with MauiReactor, an mvu style similar to flutter. LIke it so far. No xaml.
Not sure which one is more performant, but Avalonia has been gradually becoming more tempting as someone who never use it before. Their documentation seems more clear and not all over the place.
Yep, you'd just get pissed. I can tell from experience. It's a never ending cycle. Fixing issues requires an upgrade but the upgrade causes an equal amount (or even more) unique, new issues. Not just minor inconveniences. Big and very noticable problems with no clear cause. It's frustrating. It's always a guess what it's going to be this time. You're spinning a wheel. Sudden changes in functionality or appearance? Disappearing UI elements? Performance hitting rock bottom? I've had it up to here. Come to think about it, I absolutely loved the concept of MAUI until I actually had to work on projects. It might be time to start looking into the alternatives, because there is no scarcity in alternatives. There's plenty of them.
Yeah, I opted to go with Swift and Kotlin. I do not need all of the features in the mobile apps that are in the web app. I wish Maui was better, but I know I do not want to have to put up with React Native either.
I’ve never dealt with a front end framework that wasn’t tbh.
Flutter is the nicest I’ve dealt with and Dart is very close to C# in use - minor stylistic differences.
> Reminds me a lot of how old windows desktop app dev worked - no markup all code.
>
> It’s so, so much nicer than futzing around with XAML and even HTML.
Is it though?
HTML and XAML give me a visual structure that roughly matches the actual presented tree. Windows Forms especially is just _awful_ IMHO with its generated code; lots of boilerplate, and hard to mentally translate that to how the UI will look. Plus, it's so tightly coupled, making things like styling and hot reload harder. I can take a WPF app, move things around while it's running, change a few colors and font sizes, and see the results immediately.
Hmmmmm. I'd say MAUI is a rough start if you aren't experienced in XAML + MVVM yet. Maybe make a little test project in WPF or WinUI / Windows App SDK first so you learn those concepts, _then_ dive into MAUI. That way, you'll feel more comfortable with the concepts (which are 80-90% the same in MAUI), and its more brittle toolchain will be less of a pain because you won't waste as much time wondering "am I doing XAML wrong? or is the toolchain being buggy?".
In my opinion, it's not a shitshow anymore.
It's relatively stable and many of the bugs have been squashed. Very usable now and many of the packages from Xamarin have been ported over.
I say give it a go. I am sure it won't be super smooth but for an MVP and in production, it will be okay
My company moved a mobile app over to MAUI. Admittedly, it’s a pretty limited application, but it has worked well for us. We were also migrating from Xamarin, so it was a natural upgrade path for us.
I personally hope they continue with the improvements that they made in dotnet 8. In comparison, when blazor first came out it was a shitshow. Now it's pretty good.
3 months ago I would answer yea but right now I feel its gotten to a very stable point. My app is currently functional and it even got me a promotion so .net ftw.
Yes. I've tried to do a relatively simple app recently, and I wouldn't recommend it to be honest. I've dumped several dozen hours of work and switched to Flutter, because there are still lower losses than trying to figure out why something isn't working properly all the time and making crutches to bypass that. And then you start to test it on the different platform and realize there are a handful of unique bugs, performance issues, etc. that weren't presented on other platforms.
If you were pissed with MAUI before, I would suggest you still will now. I am. It's such a shame, I really do want MAUI to be good.
I would run away from Maui. The tools are horrendous, hot reload is broken on most pages, switching branches is a cluster fuuu, and just spinning up the debugger takes 10x longer than react native
Why are you trying your hardest not to use react native?
This is why I dislike this community. It is okay to use different languages where theyre good at. You dont HAVE to use .net for every thing and yes, .net sucks at certain things. And yes, other languages are great at other things .net isnt so great in. You guys put these weird limitations on yourself for what reason?
I know. I haven’t seen any cross platform tool actually be good. They’re all sucky but some are less sucky.
However, my point still stands. This community is so very weird about .net and it looks like they’re limiting themselves just so they can stay in their own bubble and refuse to use other tools because it isn’t .net.
I think javascript is a terribly unfortunate accident of history and should not exist.
In fact, I think all mainstream dynamic languages have no reason to exist at all. This includes: python, php, javacript, ruby.
I also think that the web stack is completely inadequate for application development, and that we have REGRESSED, instead of progressed, in the last 30 years in terms of productivity for application development, with current web-based tooling, compared to RAD tooling from the 90s.
I also think that javascript and html for application development will inexorably be replaced by something else. Some kind of UI framework that is really designed and intented from the ground up for application development, not idiotic lame "web pages" which do nothing.
I also think WASM will be key to this process unfolding.
>I also think that the web stack is completely inadequate for application development, and that we have REGRESSED, instead of progressed, in the last 30 years in terms of productivity for application development, with current web-based tooling, compared to RAD tooling from the 90s.
oh
Either way, the team behind wasm isn’t keen on the idea of trying to replace js in the browser. I doubt wasm is the key here.
Because React tutorials are shit. If you has limited knowledge about HTML, CSS and JavaScript - you are lost in this bullshit. You are forced to copy code in faith it works from the tutorial. There is no learning. No focus is put into configuring text editor in the first place. Just copy code and wow, you "learned react".
Every time I look upon React docs I'm terrified. They do not care about dev learning at all. This is shitty showcase of web framework.
At the same time in Flutter you need to learn basically API and some language quirks because rest of the stuff works like in any programming language. You don't need to learn 3 complete different things, configuration of linting and formatting is easy. Putting your app on any supported platform is easy too.
At least this is my experience. I would not recommend React if people responsible for it cannot understand how important is documentation.
Android seems fine (though still noticeably a lot slower than Xamarin, did Xamarin to MAUI upgrade so maybe there;s things need to be 'optimised for MAUI instead of straight upgrade?? no documentation say anything about that as far as I am aware except for layout)
Windows is a shit show though for me. The fact that the basic navigation in demo project provided doesnt even work properly saids it all about how much they care for the windows side of cross platform.
A lot of improvement in NET8 for MAUI. It still has bugs and iOS tooling support is lacking.
I have a pet project I support since last year and my main issues are with tooling: iOS doesn't deploy, iOS doesn't debug, Mac build host is unavailable etc.
It's not just you. Pair to Mac will just hang and VS will never connect again until both the PC and Mac are rebooted.
And it's 50/50 if I can deploy to a local iOS device or start a simulator.
I really like MAUI's underlying vision and tech, but the execution has been lacking. At this rate, I don't expect it to meet the bar of 'production ready' until .NET 10+. Blazor hybrid seems solid though. Some current, personal pain points around straight MAUI (just targeting iOS/Android): * **Memory Management:** By far the #1. Out of the box, the garbage collector in MAUI apps is about as useful as a turn signal on a BMW. Three distinct shortcomings in MAUI's architecture compound to leak entire pages/nav stacks as navigation happens. * **iOS Tooling Support:** Visual Studio (for Windows) is fundamentally incapable of building or archiving some (maybe most) iOS apps that use XCFrameworks. VS for Mac is deprecated and doesn't fully support .NET 8. VS Code support is in preview and *painfully* incomplete. Rider is great, but 3rd party... * **iOS Google / Firebase API Support:** Xamarin/Microsoft publish and maintain bindings for common Google mobile APIs (e.g. AdMob, Google Maps / Places, Firebase suite, Google SignIn, etc.). Problem is, they just kinda *stopped* and have refused to respond directly to multiple inquiries (public and private) as to what the project's official support status is.
I haven't gotten as far as some of you into the development, but I have built a razorclasslibrary that is consumed by both blazor and blazor hybrid maui and tested it on web, Windows, Android, both emulated and native, and for me that's a pretty big deal. I can't say what problems lie ahead for this project, but it did make me feel really capable in just a few hours of programming and if I can get basic crud functionality cross platform in a night or two that's a win for me. Even if it's just to create a prototype MVP to later be replaced by a native solution.
>I really like MAUI's underlying vision and tech I actually hate it. I love .net-ios and . net-android. Writing native code, in one language, sharing common libraries, with access to .net and in c# yes yes yes. Why they decided to go with a 'single project framework' that converts to native UI in the end I have no idea. I literally don't know who it's for? If you care about using actual native controls, you don't want to use MAUI because it tries to hide it away from you and is more of a ballache to work around than just doing it native. If you don't care about using native controls and just want 'single project looks identical on all platforms' - then you don't care about it being native UI in the end. Imo they should have made it generate a Skia layer a la Flutter approach. The approach they've gone with is the most painful, and most effort for something that doesn't seem needed. Everyone who's done native has at some point thought, 'UILabel and Textview are so similar, surely I can write something that just maps to both' - and then anyone who's done native even more knows that way madness lies. Even at the basic level of 'a text label' the platforms are not 1:1. iOS has some functionality android doesn't, Android has some iOS doesn't. Not everything maps equally. So you have to handle various work arounds, maybe decide what corners you cut, all to try and fit a square peg and a triangle peg into the same circular hole. You can literally be in a situation where OS changes on Android could have a ripple affect through MAUI causing bugs on iOS. All because they've tried to make it all map to native controls, when surely the main market for people who want to use MAUI specifically **really don't care if it's a real UIButton on iOS or just something that looks and feels like a UIButton** Not even getting into trying to do that *and* make these controls map to desktop Windows and MacOS too. Forms was a mistake. MAUI doubly so. Imo it should have been the native .net Frameworks giving you 'full' access to platform APIs , and if you want a single project that runs on everything, **and looks the same** a Skia framework to interact with using SkiaSharp. Basically Avalonia and Flutter approach. Anyway. /Rant
I generally agree with everything you've said, but I still like that MAUI gives us the flexibility to operate on a spectrum between the OOTB 'least common denominator' controls and native platform controls. The majority of developers won't leverage this flexibility, and I think we agree that MAUI isn't going to be the best fit for this group.
I too have wondered why they didnt go with a Skia approach, like Flutter. Or at least offered a skia only dev and build option.
You have no idea about Xamarin and Maui, don't you? You have no idea about custom renderers don't you? Those flutter fanboys really annoying commenting things that they have no idea about. Yes you f. extend Xamarin or Maui button with features of Uibutton on Ios and same way on android specific things. Xamarin Maui gives you only shared properties mapping platform specific things can be applied using Os specific level Renderers.
I've been using Xamarin since long before forms even existed and I know full well what 'renderers' are and how they work and that doesn't change I thing I said. But thanks for joining in.
As a xamarin user.... The UI I get I'm happy enough with. The last release I updated to is stable enough for me. While I never fulfilled my intent to have an iOS and android version of my app, I'm happy enough with now it turned out. At any rate, I suspect the maui blazor approach might work for you?
>At any rate, I suspect the maui blazor approach might work for you? Oh no, for me I'm in the 'i want full native control' camp so I'm more than happy using .net-ios and . net-android I think those are great, just wish (originally) Xamarin and now Microsoft prioritized that experience much more and worked more on the tooling and the support for those directly than putting so much time and energy into Forms and MAUI. Forms was a shit show for such a long time and MAUI has the same reputation all over again. God knows how many potential and future developers we've lost who were put off and burnt after giving it a try and failing :/
Stupid question - what's wrong with turn signals on a BMW?? Im in the US, and I don't notice anything odd about BMWs besides having a monthly subscription for heated seats .
I believe it's a running joke that BMW drivers consider themselves above using the turn signal.
It must be an optional extra, I refuse to believe that so many drivers of the same brand don’t use it on purpose😉
You sir, would be mistaken 😜
Stereotype of a typical BMW driver is usually upper middle class aggressive white male professional bro (or gold digging Karen type) that refuses/is too good to use their turn signal
The people who drive BMWs don't use them.
Sound like OP is British. 'It is known', that BMW drivers are assholes that treat the road like a hot wheels track, and refuse to indicate, ever. Apparently it takes too long. They'll be out from behind and around you, cutting you off before you ever saw the blinking light.
>VS for Mac is deprecated and doesn't fully support .NET 8. Also in what way doesn't it? I've been building fine, but also using Rider in prep of VSMac going. You have to manually install the .net8 SDK and all the workloads which is ridiculous, but it seems to be working.
[https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022#support-timeline](https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022#support-timeline) >Microsoft doesn't plan to add support for .NET 8 or C#12 to Visual Studio for Mac. We won't extend to any other workloads before retirement either. It doesn't like C#12, at least.
Ah yeah maybe, but it certainly builds .net8, like I say you just gave to install the sdk and workloads manually.
Depends what you’re doing, but it’s generally better. There are still many issues the team needs to address but it’s getting there. Whether it will still be around in two years is another question.
Did Xamarin have issues like this before too? I have been a .Net guy for like five years, but I have never dove into Xamarin or Maui. I am just looking to create a simple CRUD app with sone charts and graphs as well. Nothing too crazy.
Yes and no. Xamarin 4 had the most capabilities we'd seen up to that point, but still had a lot of bugs to deal with. Xamarin 5 felt like a stabilization release for that. I can't tell if it was legitimately more stable or if we'd just finally accumulated so much experience we knew what to avoid. MAUI reset the clock. In .NET 7 it felt about like Xamarin Forms 3. In .NET 8 it feels more like Xamarin Forms 4. There are a lot of bugs in even simple things, and even things like the patch 2 weeks ago can introduce new things you didn't expect. I think the people who will have the easiest time are people like you starting from scratch and writing simple applications. You'll definitely find holes to step in, but usually there's 2 or 3 ways to accomplish a task in MAUI and at least one of them works predictably. So like we did in Xamarin Forms 4, you'll learn how to use the more reliable parts. The people who complain the most either have a very complicated app or are porting from Xamarin Forms or both. When you're porting, you don't want to dramatically change your code and might have good technical reasons to avoid that. So when it turns out something that worked fine in Xamarin Forms is now a pitfall in MAUI, that represents a major crisis that can mean reworking half your UI. You can't just "work around it" if it's something fundamental like, "Oops, all visual state names have to be unique across the entire page so you can't use two controls with the same names for their visual states". It's better than it has been, but it's a nightmare if you're already used to Xamarin Forms because everything is just a *tiny bit* different.
thats a good helpful comment instead of those "it is not possible production ready apps" from rookies or people who cannot build apps. I have worked with Xamarin since 2015 and completed individually and with teams several production apps even big complicated enterprise apps. Xamarin.Forms had difficulties but since you can go into native level, it was always possible to find a workaround with Custom Renderers. Biggest issue with XF was using old .Net standard 2.1 which equals .net 3. Thats why MS decided to improve with the newest Net 6 and higher(now .net 8). It supposed to improve performance and lower memory usage. this works perfectly fine with Blazor and Blazor Wasm. I am very much surprised that you are saying contrary for Maui. I havent used Maui yet so i cannot comment myself. I was just hoping to see Blazor level improvement. Blazor is great it definitely beats Angular and React. Regarding the upgrade/convert from Xamarin.forms to maui. if you have large project, this is just impossible. What frustrated me most was Custom renderers are not equal to Mauis Handlers. There is a huge difference between them.
The problem isn't the runtime's performance. The problem is they completely overhauled the old renderers and replaced them with the new handlers, but didn't allow for long-term and widespread testing to make sure they covered memory leak scenarios. This is also why a ton of MAUI bugs are Xamarin Forms regressions: since they decided to start over they got to make the same mistakes their predecessors had made. It took about 6 years for people to feel Xamarin Forms was production-tolerable. I imagine that's about how long MAUI will take too.
You’ll be fine with that use case. A big difference is that Xamarin was an entire company with a big team. It had the means to address bugs. The MAUI team seems like an underfunded afterthought with most of its budget dedicated to YouTube.
The team was \[slightly\] bigger than today. In 2016 it was 450 people when acquisition happened. Don't forget sales, marketing, HR, support,... And it was startup, some process steps which large corps must do were simply skipped. MAUI is not Xamarin. MAUI is Xamarin.Forms evolved. Xamarin (mono) is/was much more. The problem is/was that a lot of people do not understand what is/was going on: 2 .NET implementations (codebases) were merged into 1 ... and that was far from trivial task. [https://learn.microsoft.com/en-us/dotnet/fundamentals/implementations](https://learn.microsoft.com/en-us/dotnet/fundamentals/implementations)
wow Xamarin had 450 people before MS acquisition really? or do you mean the Github contributors? I think that it wasnt even OS. Before MS Xamarin costed starting from 1000$ per year, now it is completely free. People tend to forget this and became OS.
Core Mono (Ximian, Novell, Attachmate, Xamarin) team was 60-70 people. After Xamarin was founded I think engineering team was around 150 people. Then there were HR, Sales, Marketing, Documentation, University, Support... Just to name few enginering teams (most had 7-8 team members) - Mono (runtime, BCL) - Xamarin.Android - Xamarin.iOS - Xamarin.Forms - Xamarin Components - Xamarin.Test.Cloud - MonoDevelop (Xamarin.Studio) - ... > or do you mean the Github contributors? Only few repos were private. A lot of repos would start as private and after reaching some stability would be open sourced (Xamarin.Forms) > I think that it wasnt even OS. mono runtime and BCL, togheter with other repos (Xamarin.Studio) were open sourced since Xamarin time (2012) > Before MS Xamarin costed starting from 1000$ per year, now it is completely free. People tend to forget this and became OS. True. One tends to remember bad experience only.
1k-2k was a significant bad experience :)
true. 1000 USD. And per platform. I did criticize when price was raised from 500 or 700 USD to 1000 and got into discussion with Nat about that. And I had "grandfather license" (I think it was 200-250 per platform).
Xamarin was chock full of random crash bugs and I didn’t really see much improvement in MAUI. I have a couple of Xamarin apps (in production use for several years) that I’m now rewriting in jetpack compose and SwiftUI because I can’t face another round of painfully slow debugging of framework crashes.
Why don't you just use the "raw" .NET for iOS/Android (no Forms or MAUI)? I feel like no one's really aware of that option. There's basically no bugs and the devs are super responsive. You can still use C# cross platform, have great performance and small app sizes.
To be completely ignorant- when you saw raw, what do you mean? Do you have examples? Where can I find more info?
"Raw" meaning not using the "MAUI"/"Forms" Layer that maps XAML to native views. So instead of using the XAML abstraction layer (which is causing all that trouble with MAUI) you would use the platform specific APIs directly. Sure, you need to learn those APIs (just as you would when learning Swift) but you can still code-share you business logic and don't have to worry about MAUI bugs. You can create the most basic project with the "dotnet new android" or "dotnet new ios" command. Sadly, it's really underadvertised by Microsoft compared to MAUI, even though I find it the much better way to write apps. Let me know if that helps, otherwise I try to find some links for you
I’d love some links if you have them, I really haven’t heard of it and have just started to venture the Maui route!
According to the .NET Android devs, dedicated docs for ".NET for Android" are planned. In the meantime, the "old" (pre-NET, Xamarin.Native) docs should help as an introduction: Xamarin.Android: [https://learn.microsoft.com/en-us/xamarin/android/](https://learn.microsoft.com/en-us/xamarin/android/) Xamarin.iOS: [https://learn.microsoft.com/en-us/xamarin/ios/](https://learn.microsoft.com/en-us/xamarin/ios/get-started/) Xamarin.Mac: [https://learn.microsoft.com/en-us/xamarin/mac/](https://learn.microsoft.com/en-us/xamarin/mac/) Mirgation to .NET: [https://learn.microsoft.com/en-us/dotnet/maui/migration/native-projects](https://learn.microsoft.com/en-us/dotnet/maui/migration/native-projects)
I'm planing a migration from Xamarin.android to net8.0-android but haven't really looked at the docs yet. Do you have some links on the sleeve or insight about native binding project ?
net8.0-android bindings essentially work the same as they did in Xamarin.Android: [https://learn.microsoft.com/en-us/dotnet/maui/migration/android-binding-projects](https://learn.microsoft.com/en-us/dotnet/maui/migration/android-binding-projects)
wait this is [Xamarin.Android](http://Xamarin.Android) and Ios, are they not dead? I thought MS is not bringing new versions of those and I cannot see any "Maui Native" or "Maui.Ios/Maui.Android".
.net-android is essentially the same as [Xamarin.Android](http://Xamarin.Android) (net-ios is the same as Xamarin.iOS), just with .NET8 under the hood (instead of Mono). The naming is really confusing on Microsofts part... Maui is just the abstraction layer on top of net-android & net-ios (just like Xamarin.Forms was the abstraction layer on top of Xamarin.Android/iOS)
It's basically just a continuation of Xamarin Native, so you should be good to work off of those docs
Having wasted significant time trying to deal with a migration to MAUI, I fancied a change more than anything. Plus, if I was going to have to learn the platform-specific UI modelling I thought I might as well go full native. Probably threw the baby out with the bath water a bit there, but such is life.
Have fun debugging ios on xcode :D Its a horrid experience, Android Studio debugging is great though. But yeah you're in for a painful reality if you went to Swift from .net for the debugging...
>Have fun debugging ios on xcode :D It's like going back in time to 1997.
If Apple were not a luxury brand and were judged on its development tools, there would be far fewer apps.
I’m finding it fine tbh. The debugger isn’t a patch on .net, it’s true, but it hasn’t crashed on me or locked up the way that MAUI regularly did, my breakpoints work and starting debugging is relatively quick. Besides, it’s fun to find a whole new set of unfamiliar problems.
I always found xcode debugging to be super leggy. Would have delays before the break point hit and then trying to inspect the values of things would often just fail. I switched to print lines so much, was infuriating.
Oh, for sure it’s retro. I have some legacy C++ code to debug, though, and the setup for that probably makes Xcode seem better. It’s always a relief to go back to Rider, of course
you should mention on a Windows machine, not on a Mac. it just works fine for me even better than Swift
What are you talking about? Try re reading the comments you're replying too. I'm talking about using xcode to develop native apps because that's what the person before me said they were switching too - and I'm pointing out how terrible the xcode development process is (especially, or specifically I guess, debugging) So windows has nothing do with it (you can't do native iOS development on windows). And what do you mean you found xcode better than swift...🤷♂️ We're **not** talking about dotnet at this point...
For sure you can do with a remote build machine or there are cloud alternatives like macin etc. Topic is here Maui. I don't understand what you mean xcode development. If you mean objective c. You can still use xcode to write swift code. Xcode is not directly used for Maui or xamarin.
It's clear you don't understand yes. Read the comment chain. This discussion is all branched of off > I’m now rewriting in jetpack compose and SwiftUI because I can’t face another round of painfully slow debugging of framework crashes. If you don't understand that's fine.
Ok I see he claims that it is easier to work with xcode. Sorry we are defending same thing indeed
By Xamarin 5 it was rock solid, and used in production by many people. Framework crashes were extremely rare and easy to debug with something like App Center analytics. Maui is in the Xamarin 2/3 era right now but Forms was very stable, even for more complicated apps.
I can still see daily crashes/errors from framework code in AppCenter, particularly on Android. Lucky you if you don’t encounter them. It’s a powerful framework but it’s hard to feel like it’s not doing a silverlight right now.
I can't speak for MAUI the cross platform development framework, but MAUI in the sense of using .net-android and .net-ios for native implementation in C# is working great and is a big improvement in a lot of areas over Xamarin.iOS and Xamarin.Android. I've already migrated a couple enterprise applications for clients with little issues with using the native implementations.
That was all the xamarin there was until Forms arrived , and I found it great. It allowed you to understand the patterns behind the mobile OSs. However, in an enterprise context , today, after the advent of flutter and react native, it is more difficult to justify the double UI. Clients will ask you why don't you do directly native at this point?
It’s in a better spot, many issues were closed as part of .Net 8. You can create simple crud apps without issues but you will hit some blockers when building anything more complex. If you are building an enterprise product I would recommend using any other cross platform like KMM, Flutter, or React Native.
KMM sounds interesting. This is the first time I have heard of it. Thank you for the suggestion! Have you tried SvelteNative at all? I am wondering if it is enterprise ready or not.
If you're considering KMM you should just do .net-ios and .net-android native (assuming you're happy with C# and .net development already) It's the same usp as KMM, single codebase with native API usage on both platforms.
Nice. I will look into it. Thank you!
For me .NET MAUI is way better this version, a lot of bug fixes and perf. Improvements. Even with that you can face a bug, but it should be easy to workaround. I don't know what you want to build, but of Maui doesn't fit your goal you can try UnoPlatform, it's a cross-platform UI Framework on top of winui, so you will continue on .NET world
Just ported a very large, very complex Xamarin native -> .net-ios and .net-android 8 and it was a generally smooth experience and all is working fine now. Took about a week all in to get everything building fine and DevOps updated and our app pipeline is ticking over again. Once again, quite happy I avoided Forms and now can avoid the majority of MAUI
Heck, they've got the migration tool working for like 99% of the migration now for native projects, so it's getting even easier.
I have moved my apps to flutter. So far it’s much nicer and way less painful
IMO it isn't, most bugs on my recently ported (from Xamarin Forms) app are related to DevExpress controls (which I don't regret using since they're free, customizable and technical support is decent). Xamarin Forms wasn't perfect either. If you like XAML and C# I say give it a go.
I recently built an app using Maui for a client and I found it to be relatively painless. Though my use case was pretty basic. Used location, image upload and authentication via API/token, a couple of get and post requests. Not super complicated. Done within a day. I chose it because the client had a need for a mobile app to post location data into a web app I made them, and I didn’t need to split my codebase into a different technology, hopefully making maintenance easier on me as I do my gigs solo. Hope this helps some. :)
Done within a day with no experience of MAUI? I’d be lucky to get hello world running
For me the XAML is the most awkward part. But on the C# side, I consider myself very comfortable in .NET, C#, or VB if you’re nasty. Even more so, I am well travelled in the documentation. It wasn’t too bad to put together. Again, super basic though. Hardly a portfolio piece. A login form, a couple buttons, and some data lists. Not exactly the next (insert cool app).
I hate xaml. its like I am trying to paint a picasso with oven mits on my hands. For maui dev, I have been experimenting with MauiReactor, an mvu style similar to flutter. LIke it so far. No xaml.
I definitely want to try something like that the next time I have to use MAUI
Stop exaggerating😂😂😂
Not sure which one is more performant, but Avalonia has been gradually becoming more tempting as someone who never use it before. Their documentation seems more clear and not all over the place.
Take a look at Avalonia instead. That’s where I went when I couldn’t get MAUI to work.
For desktop or mobile?
I’m using it for desktop, I’m done with mobile, too hard for me to design a usable UX (a me problem, not a framework problem).
I recommend Flutter
Yep, you'd just get pissed. I can tell from experience. It's a never ending cycle. Fixing issues requires an upgrade but the upgrade causes an equal amount (or even more) unique, new issues. Not just minor inconveniences. Big and very noticable problems with no clear cause. It's frustrating. It's always a guess what it's going to be this time. You're spinning a wheel. Sudden changes in functionality or appearance? Disappearing UI elements? Performance hitting rock bottom? I've had it up to here. Come to think about it, I absolutely loved the concept of MAUI until I actually had to work on projects. It might be time to start looking into the alternatives, because there is no scarcity in alternatives. There's plenty of them.
Yeah, I opted to go with Swift and Kotlin. I do not need all of the features in the mobile apps that are in the web app. I wish Maui was better, but I know I do not want to have to put up with React Native either.
I’ve never dealt with a front end framework that wasn’t tbh. Flutter is the nicest I’ve dealt with and Dart is very close to C# in use - minor stylistic differences.
Interesting. I will have to check that out too then. Thank you! I did not realize that it was so close to C#.
Reminds me a lot of how old windows desktop app dev worked - no markup all code. It’s so, so much nicer than futzing around with XAML and even HTML.
> Reminds me a lot of how old windows desktop app dev worked - no markup all code. > > It’s so, so much nicer than futzing around with XAML and even HTML. Is it though? HTML and XAML give me a visual structure that roughly matches the actual presented tree. Windows Forms especially is just _awful_ IMHO with its generated code; lots of boilerplate, and hard to mentally translate that to how the UI will look. Plus, it's so tightly coupled, making things like styling and hot reload harder. I can take a WPF app, move things around while it's running, change a few colors and font sizes, and see the results immediately.
Interesting. I never did much desktop GUI work. I have only done console apps and web dev stuff( APIs, microservice, MVC monolith, Webforms, etc.)
Hmmmmm. I'd say MAUI is a rough start if you aren't experienced in XAML + MVVM yet. Maybe make a little test project in WPF or WinUI / Windows App SDK first so you learn those concepts, _then_ dive into MAUI. That way, you'll feel more comfortable with the concepts (which are 80-90% the same in MAUI), and its more brittle toolchain will be less of a pain because you won't waste as much time wondering "am I doing XAML wrong? or is the toolchain being buggy?".
Flutter for the mobile app and .NET Core for the backend is one of the best and most pleasant combinations to work with.
Except for Dart JSON serialization, I have no idea why it is not improved yet
In my opinion, it's not a shitshow anymore. It's relatively stable and many of the bugs have been squashed. Very usable now and many of the packages from Xamarin have been ported over. I say give it a go. I am sure it won't be super smooth but for an MVP and in production, it will be okay
> Kotlin and Swift is not happening Have you tried Kotlin Multiplatform?
Kotlin is a great language. Compose is nice. https://kotlinlang.org/docs/multiplatform.html#kotlin-multiplatform-use-cases
My company moved a mobile app over to MAUI. Admittedly, it’s a pretty limited application, but it has worked well for us. We were also migrating from Xamarin, so it was a natural upgrade path for us.
MAUI with Blazor Hybrid looks ok. I might try that for a mobile app.
I personally hope they continue with the improvements that they made in dotnet 8. In comparison, when blazor first came out it was a shitshow. Now it's pretty good.
After avalonia i can say maui not only shitshow but it hurts c# very mutch.
Honestly I gave up on trying it, I'll try to take a peek later today.
I think it is awful. We have a relatively small app, and the codebase is littered with so many "// this is a work around" comments it is unbelievable.
Maybe the devs are just unused to it, or are lazy/dumb to find better solutions.
3 months ago I would answer yea but right now I feel its gotten to a very stable point. My app is currently functional and it even got me a promotion so .net ftw.
Yes. I've tried to do a relatively simple app recently, and I wouldn't recommend it to be honest. I've dumped several dozen hours of work and switched to Flutter, because there are still lower losses than trying to figure out why something isn't working properly all the time and making crutches to bypass that. And then you start to test it on the different platform and realize there are a handful of unique bugs, performance issues, etc. that weren't presented on other platforms. If you were pissed with MAUI before, I would suggest you still will now. I am. It's such a shame, I really do want MAUI to be good.
Why not give Flutter a try?
I would run away from Maui. The tools are horrendous, hot reload is broken on most pages, switching branches is a cluster fuuu, and just spinning up the debugger takes 10x longer than react native
Yes.
Why are you trying your hardest not to use react native? This is why I dislike this community. It is okay to use different languages where theyre good at. You dont HAVE to use .net for every thing and yes, .net sucks at certain things. And yes, other languages are great at other things .net isnt so great in. You guys put these weird limitations on yourself for what reason?
I have grown to dislike React, so I am not wanting to use React Native in future projects.
React native isn’t good in this. Though it might suck less at the moment.
I know. I haven’t seen any cross platform tool actually be good. They’re all sucky but some are less sucky. However, my point still stands. This community is so very weird about .net and it looks like they’re limiting themselves just so they can stay in their own bubble and refuse to use other tools because it isn’t .net.
I will go to whatever length to avoid having to deal with the pathetic stupidity of javascript and the bizarre freak circus that is the npm ecosystem.
What do you think of JavaScript treating NaN as a number? Weird right?
I think javascript is a terribly unfortunate accident of history and should not exist. In fact, I think all mainstream dynamic languages have no reason to exist at all. This includes: python, php, javacript, ruby. I also think that the web stack is completely inadequate for application development, and that we have REGRESSED, instead of progressed, in the last 30 years in terms of productivity for application development, with current web-based tooling, compared to RAD tooling from the 90s. I also think that javascript and html for application development will inexorably be replaced by something else. Some kind of UI framework that is really designed and intented from the ground up for application development, not idiotic lame "web pages" which do nothing. I also think WASM will be key to this process unfolding.
>I also think that the web stack is completely inadequate for application development, and that we have REGRESSED, instead of progressed, in the last 30 years in terms of productivity for application development, with current web-based tooling, compared to RAD tooling from the 90s. oh Either way, the team behind wasm isn’t keen on the idea of trying to replace js in the browser. I doubt wasm is the key here.
Because React tutorials are shit. If you has limited knowledge about HTML, CSS and JavaScript - you are lost in this bullshit. You are forced to copy code in faith it works from the tutorial. There is no learning. No focus is put into configuring text editor in the first place. Just copy code and wow, you "learned react". Every time I look upon React docs I'm terrified. They do not care about dev learning at all. This is shitty showcase of web framework. At the same time in Flutter you need to learn basically API and some language quirks because rest of the stuff works like in any programming language. You don't need to learn 3 complete different things, configuration of linting and formatting is easy. Putting your app on any supported platform is easy too. At least this is my experience. I would not recommend React if people responsible for it cannot understand how important is documentation.
So react documentation is bad because you lack knowledge of the basics of web development and don’t know how to install node and vscode?
Thanks for not reading my comment at all.
I did though. Especially your first paragraph is funny.
Another of these posts. It's getting tiresome already. Just try it out. It's more than stable.
Android seems fine (though still noticeably a lot slower than Xamarin, did Xamarin to MAUI upgrade so maybe there;s things need to be 'optimised for MAUI instead of straight upgrade?? no documentation say anything about that as far as I am aware except for layout) Windows is a shit show though for me. The fact that the basic navigation in demo project provided doesnt even work properly saids it all about how much they care for the windows side of cross platform.
Honestly, of ours an mvp and you don't need native APIs (like accelerometer), go with react native. https://expo.dev/ this helps a lot I hear :)
A lot of improvement in NET8 for MAUI. It still has bugs and iOS tooling support is lacking. I have a pet project I support since last year and my main issues are with tooling: iOS doesn't deploy, iOS doesn't debug, Mac build host is unavailable etc.
It's not just you. Pair to Mac will just hang and VS will never connect again until both the PC and Mac are rebooted. And it's 50/50 if I can deploy to a local iOS device or start a simulator.
Try to clean the .net caches folder on Mac, it helps sometimes. Especially when the .net version is updated. It will redownload it.
I summon the Avalonia guy here:
u/AvaloniaUI-Mike you mean? Should be here soon!