Flutter's Approach of Not Directly Binding to Native Controls

[thekeviv]

Summary

Flutter's approach to cross platform UI is not to directly bind to native controls and instead to paint controls in a canvas in the different platforms it targets. This allows them to provide a lot more control to the developers and to them. While this creates more work for them and has a downside for more work to do in future in case a platform vendor creates a new design system (I think it has happened once so far for iOS (Skeuomorphic to Cupertino) and Android (to Material)), this also means that they don't have to build something which tries to balance different things between the different platforms.

Now that Microsoft is going to support more platforms and is even looking into Web, I'm curious why a similar approach is not being taken. Particularly, instead of binding to native controls like Xamarin does currently, why not draw controls for each platform and make them available to the developers through a shared API? Also, provide a simple mechanism for developers to draw their own controls and add events to them?

[robloo]

This would certainly be the most robust architecture. Downsides include integration with native controls (in the edge cases where that's necessary) and accessibility support.

Have a look at AvaloniaUI as well which is conceptually similar -- though not for Android/iOS.

[J-Swift]

Another downside, which is partially the same as native integration and partially not, is you lose the ability to integrate existing 3rd party libraries

[Happypig375]

Dramatic increase in usability in majority of cases trumps edge cases.

Also, accessibility is available in Flutter.

[neptrio]

The biggest advantage for me of Xamarin/MAUI is that it does not work like Flutter. What I really like about Xamarin/MAUI is that it only abstracts the surface with a specific language and does not imitate it.

This way the documentation for the user interface framework of ios and android remains relevant and can give good hints, because under the hood the same mechanisms are used.

[jingliancui]

Lots of 3rd party libraries need native Controls , so It's necessary need binding native controls.
May be Flutter's approach as the addition tech to perfect MAUI .

[lylerolleman]

For many of the same reasons mentioned above, i would not be in favour of using Flutter's methodology.

I think there is room though for better integration with skiasharp for doing Flutter-style controls

[jingliancui]

maybe skiasharp and the new shape feature

[davidortinau]

provide a simple mechanism for developers to draw their own controls and add events to them?

What about Shapes + Paths + Brushes with Control Template support added to each control? RadioButton is an example of how this would look for all controls. xamarin/Xamarin.Forms#11628

And if you want to take on the weight of SkiaSharp rather than using the native drawing apis used in Shapes/Paths, then that's an option as well.

[thekeviv]

I like the Shapes API quite a lot and would love to use it so much more in my apps! I am afraid I don't fully understand a comment from @praeclarum but he mentioned that there were things not possible using Shapes in this tweet. Would you mind weighing in on that please?