[Enhancement] MAUI Must Emulate UNO/Flutter UI Architecture and Ditch Native UI Entirely #1058
Replies: 9 comments 14 replies
-
|
While the approach of using a graphics library might seem very appealing, I don't think Microsoft should ditch using native controls. Native controls do a huge part of the heavy lifting. Using a graphics library to render UI views requires a HUGE (and I can't stress this enough) effort and for that effort you won't get what you expect. Sure, UI itself might be implemented moderately easily without bugs given sometime invested in it, but can you say the same thing about interactivity (touches, drags, keyboard-view interactions, system-view interactions)? What about accessibility? That's probably out the window unless it is recreated in .NET somehow. What about theming and dark mode? What about new features rolling out in newer OSes? What about performance? Those native views have been developed over literal decades and used by millions and millions of people and pretty much every bug possible that appeared in those views has been addressed. Starting over by creating your own views will cause you to eventually hit much of the same bugs Google and Apple hit, even if you have the most tested code base in the world. And bar the bugs, performance is a huge issue too. Again, native views are battle tested and every performance optimization you can think of was used to get the views to have the performance you see today. Throwing all of that away doesn't make sense. "But hey, Google did it, why not Microsoft?" Well, Google has the advantage of already being the mobile space through Android and I willing to bet that much of the same engineers who worked on Android also worked/working on Flutter and they brought their experience (and maybe the code) with them. I am not saying Microsoft doesn't have they expertise. Microsoft have developed UI frameworks before but I don't think it will be the same. With native views it is a matter of creating an interface to expose those features and maybe emulate or shim a feature that isn't there. The cost of adding a new feature is much much MUCH lower. The Xamarin.Forms team in the last year or so have changed their strategy from only exposing supported features by all platforms to shimming a feature if it is not there and I think that will continue. As for looking identical, this is a matter of providing a base styling for all views that would make the default view without any styles look identical so that the developer can then apply their styles. I think this was already partially done in Xamarin.Forms with Material Design Components. If the problem you have with MAUI is controls not looking identical, throwing away the whole OS provided controls and drawing your own seems a bit much. There are easier ways to solve that problem. |
Beta Was this translation helpful? Give feedback.
-
|
The effort of develoing without bugs a single drawn control is much lower than maintaining multiple bindings to native objects.
Touches and drags are easy but some degree of platform interop and native controls may be needed for keyboard interaction. |
Beta Was this translation helpful? Give feedback.
-
|
@AmrAlSayed0 Sure the native controls may be battle-tested and bugfree, but Xamarin Forms itself is so buggy that this argument goes down the drain. |
Beta Was this translation helpful? Give feedback.
-
|
No, my argument doesn't go down the drain. What is the argument here? Xamarin.Forms is very buggy so Microsoft should develop something that has a higher chance of turning out to be more buggy? Using native controls should still be the approach that yields the least buggy code the easiest. Also, we're forgetting something here. When YOU are developing for several platforms say Android and iOS and the client asks for identical UI and some fancy styling like drop shadows and curved borders or whatever, what is the approach YOU will take to get that? Of course you won't go thinking "I will draw my own controls". You will take the sensible approach and try to implement those styles and features using the native controls. The fact that the native controls are not identical by default is not deal-breaking thing that forces you to draw your own controls. It has been like this for the web for example. The base styles of HTML tags are different between browsers, what did we do to fix that? We created CSS resets style sheets that level the playing field. At no point will a developer just give up and say "I will draw my own controls" except if there is some really complex control like charts and graphs or some domain specific control. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @brencode . Full disclosure, I am with Uno team. I'm doing market research and it looks like you can help me. I am curious, and I am happy to take the conversation offline not to distract this thread. In a hypothetical scenario you move away from your current stack, what makes you chose Flutter over Uno. Feel free to reach me at sasha at platform.uno . I don't want to higjack this thread but I have no other way to get in touch with you. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't realize that Uno had a pixel-perfect option. That is great. I assume it gives higher perf than native controls too? |
Beta Was this translation helpful? Give feedback.
-
|
More than happy to. If you use LinkedIn, feel free to reach out to me here: linkedin.com/in/brennan-christen-045263206. Off the top of my head, lack of support for Cuptertino styled controls out of the box would be the only limitation I can think of off the top of my head. Looks like you guys have Material support (awesome) https://platform.uno/docs/articles/features/uno-material.html |
Beta Was this translation helpful? Give feedback.
-
Hi, for me I dont use Uno because of the startup time too slow... But Uno platform also the best cross platform. |
Beta Was this translation helpful? Give feedback.
-
|
@brencode If I may ask, how many clients do you have? And I believe the Surface team is working with flutter to providing dual screen support for Android and Surface duo. For Windows support, some community guys are doing that. But if they come to Windows team for technical support, Windows team could do that. Maui is going to support for Native control as well as graphics rendering using Microsoft.Maui.Graphics and Microsoft.Maui.Graphics.Controls |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate that the maui team is not trying to copy the competition. :) |
Beta Was this translation helpful? Give feedback.
-
|
@brencode thanks for sharing your customer experiences and needs with us. Come November .NET MAUI will be what you see in our previews now: platform-native UI. This is what so very many production apps are using today and we believe continues to be valuable into the future. But it's only part of the story as we see lots of apps using SkiaSharp to augment UI for consistent design purposes. I agree the need for consistent UI design is important for quality of the end user app experience, and general developer productivity. From our customer research the goal of 1:1 pixel perfect UI is not universal. It's not even the majority. In most cases we hear from customers that consistent design + platform culture is the goal - which is actually at odds with drawing every pixel. And so, we are continuing our investment in the platform-native UI controls, while investing more into Microsoft.Maui.Graphics and GraphicsControls experiment. We'll see in the coming months what kind of progress can be made there, and we absolutely welcome any contributors or partners in that endeavor. Early indicators are this is going to be wildly successful. |
Beta Was this translation helpful? Give feedback.
-
|
I couldn't agree more @davidortinau. I might have been not reading/listening carefully enough, but I think it would be beneficial to make it more clear in the MAUI posts and documentation that MAUI supports truly native UI controls by default, and NOT something like Flutter. The concept of a Mac Button on macOS, an iOS button on iOS, and an Android button on Android is hugely appealing to a lot of people (as you mention). That capability kind of gets lost in the "write once, deploy on 4+ platforms." I did not realize this was a core feature of MAUI until reading the documentation on handlers yesterday. Anyways, keep up the great work! |
Beta Was this translation helpful? Give feedback.
-
|
I disagree with you at all @davidortinau . Either you are listening to the wrong customers or they are not really involved in app development. Native control designs are something from 2015. Just if you look at the 100 most popular apps, you will notice that they use none at all or rarely (individual cases with checkboxes etc.). All of these apps create their own designs for their app, and that's how it has to be. |
Beta Was this translation helpful? Give feedback.
-
|
But I don't understand these recurring themes. |
Beta Was this translation helpful? Give feedback.
-
That is not true. Do you used any official Apple app? Even new Apple apps are designed using Cocoa and Cocoa Touch components.
I use macOS instead of Windows because this kings of decisions lacks the user experience. In Windows exists Win32, UWP, WinUI... Microsoft uses Electron in some preinstalled apps like Skype, nothing is consistent and the user experience is bad. I love Windows power, but I can't stand the inconsistency and user experience. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. Why should use Apple and Google other designs for their own OS and Design rules? I'm talking about apps from third parties. And yes. Microsoft has never and maybe will never get a correct design rule for their products. Even every Microsoft product except for PC has a bad UX. Microsoft is using Electron and other technologies for their apps instead of Xamarin. And the question here is why? Why they're not investing more in their own team, so that not only 8-10 poor guys are working for a project without future, but they're creating a real tool as an alternative to Flutter, React Native, Java, Kotlin, Swift, Electron and the rest? Microsoft is doing here again a mistake and they will even see this when the community is already dead. |
Beta Was this translation helpful? Give feedback.
-
|
As a user perspective, I want all my apps feel identical, and more important, behave identical. If I change in my iPhone settings how a switch is rendered or font weight (very important accessibility settings), I want see this change apply in all my apps. To achieve this goal, is very important use native UI. I can accept an alternative implementation of controls rendered by a drawing library (useful for games and specified apps), but native UI implementation is mandatory. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't this how MAUI currently works? Otherwise it is just a poor man's Flutter. |
Beta Was this translation helpful? Give feedback.
-
I didn't tried MAUI yet because I'm not a mobile developer, but as I know, MAUI uses native UI. |
Beta Was this translation helpful? Give feedback.
-
|
When I wrote my first iOS app in 2012 I designed all the control layouts (Xamarin/Mono), I realised I was trying to emulate a windows type layout, my second version of the app uses the native controls, used Xamarin properly that time did the layouts and flow like an iOS app, users loved it, it was easier for them to learn because other apps used the same controls. Pixel perfect sounds good but Android and iOS users have gotten used to how things display on their device. Native controls for me. |
Beta Was this translation helpful? Give feedback.
-
|
I agree but Microsoft shouldn't be following Uno or Flutter. |
Beta Was this translation helpful? Give feedback.
-
|
Instead of being invested in Flutter by having to learn a whole new language, why not just try Avalonia? It's pretty amazing! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Let me begin with: I've been developing with Xamarin.Forms for nearly seven years. I want MAUI to be a tool that is better than competing UI frameworks on the market like Flutter for building mobile, desktop, and web apps.
Here's an overview of my development experience over the years with Xamarin that informs this imperative request: Every client I've worked for has wanted as close to an identical UI as possible on all target platforms. Clients do not want or need native controls/widgets/views to be rendered typically. It is a rare edge case. Rather, clients need platform independent non-native controls rendered by a vector graphics library. All clients I've worked for have adopted Xamarin because existing .NET developers could use C#/.NET to build mobile apps, while being able to consume existing libraries without reinventing the wheel. Clients and developers I've spoken to want Microsoft to ditch the native UI approach, and to emulate the Flutter and UNO approach of rendering controls independently of the constraints of the platform.
The majority of development time is spent trying to tweak the UI to make it look identical on both platforms for current Xamarin developers. With the release of Flutter 2.2, it is becoming increasingly difficult to rationalize further investment in MAUI until this becomes THE primary architecture for the platform. Mimicking the Flutter/UNO approach highly simplifies the development process on your end, and working prototypes are already alive and well that should be used to accelerate development. This is where developers want MS and the MAUI/Xamarin team to invest in. The holy grail for developers is for MS to emulate Flutter's architecture while giving we developers the massive advantage of being able to continue to use .NET and C# so we don't have to reinvent the wheel by rewriting libraries in an immature language like Dart.
Finally, Microsoft is investing in working with Google to allow Flutter to target Windows. MS should instead be investing in competing directly with Google by building MAUI the way its veteran developers need. By doing so, you will see the open-source community flood this project with support because .NET developers WANT to keep using C# and avoid having to invest in Flutter/Dart. Personally, I will spend hundreds of hours helping to make this a reality if the Xamarin/MAUI team changes its approach. People are currently holding out on investing because they are cautious with how they expend their valuable time. The market is strongly indicating that Flutter is the cross-platform UI framework to beat. If MAUI goes with native UI first at launch, it will be considered by every peer I know who have developed with Xamarin to be obsolete the day it is released. Half of the developers I know who have used Xamarin have ditched the framework for Flutter because of this. If this happens, after seven years of using Xamarin/.NET to develop mobile apps, I will be forced to move on and invest in Flutter instead, because it will end up being the best tool for the job.
Beta Was this translation helpful? Give feedback.
All reactions