Question: XAML Flavor, Architecture & Roadmap

[robloo]

Summary

Is this project going to stick exclusively with the Xamarin Forms flavor of XAML? Is there any chance of adopting the "real" XAML from WPF/UWP? (TextBlock instead of Label, StackPanel instead of StackLayout, etc.) XAML Standard really should have been implemented by now.

If this is built on Xamarin Forms, what are the commitments in terms of bug fixes? Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them. The architecture is non-ideal for custom controls as well.

Honestly, I would like to use a Microsoft-backed cross-platform UI framework but Xamarin Forms is a poor choice for stability and the XAML differences from WPF/UWP. Other options, like the Uno Platform, are more attractive for these and other reasons.

Can you provide a detailed summary of this new framework architecture (is it just re-branded Xamarin Forms?) and a roadmap of where you are taking this in the future? I don't think this framework is what developers have been asking for but want to be sure before making decisions about current and future applications.

[dhindrik]

It is a rebranding of Xamarin.Forms, or if you want, the next version of Xamarin.Forms.

I think it is a little bit strange to talk about XAML flavor, it is not the XAML flavor that is different, it is the object model. XAML is just a markup language to instantiate objects.

And for example, the name StackLayour is logic, because it is a Layout and has Layout as it's base class. We also have FlexLayout. Maybe Grid should have been called GridLayout as well because it is also a Layout.

[nikolalukovic]

@dhindrik Strange in which way? A considerable amount of people in community find the XAML implementation in Xamarin severely lacking and impotent compared to WPF/UWP. If this project is a real push towards cross-platform support than I honestly believe the community needs proper and rich tools(like aforementioned XAML implementation from WPF/UWP) to broadly use this project in the future.

[Panda-Sharp]

+1 for UWP/WPF XAML dialect

[MartinZikmund]

If it at least gets rid of WidthRequest and HeightRequest, it would be amazing

[michael-hawker]

It seems like a good time to try and align more with the rest of the XAML ecosystem. Would make it a lot easier for folks learning and working with different projects/technologies to apply their skills.

[dpaulino]

One of my biggest confusions when starting to use xamarin forms was why does Microsoft have WinUI/WPF xaml dialect and another dialect in xamarin. It was confusing for me. If Maui could move towards WinUI xaml dialect, it would make the user experience of developers switching between the platforms much smoother.

[billhenn]

I second that... coming from a WPF/UWP background, it seems silly to have another dialect of control and property names when there is so much similar functionality between those and XF. This could be corrected and aligned per the XAML Standard idea with Maui.

[weitzhandler]

I'd only consider MAUI if it's fully UWP/WinUI compliant, that also means full WCT support. Sorry but it's a deal breaker to me.

And it's not just because of the XAML unportability, it's because of the XF UI object model that was initially architected as mobile-centric, and lacks a lot of desktop I/O features and desktop-related APIs. I totally second what @dhindrik said, XF's XAML is diverged in a much deeper level than XAML aliases.

UWP and WinUI in the other hand, were designed to accommodate for any type of device or screen size from day one. Plus it's Fluent compatible. This is the one good memory to keep of Windows Phone, where MS engineered it properly taking desktops, tablets, phones and all kinds of devices into account.

[tomasfabian]

There was an attempt to create a XAML Standard: https://github.com/Microsoft/xaml-standard

even a (currently unlisted) nuget package Xamarin.Forms.Alias used to exist for WPF like Xamarin.Forms Xaml

[bmacombe]

Maybe it would be possible to leave the the XF XAML in MAUI initially, but hidden from the editor, etc. So MAUI xaml could align with WinUI better, but not break existing XF apps that are ported.

[weitzhandler]

@bmacombe please don't. 2 XAMLs are already too much (it's kinda 3 cuz WPF is not completely UWP XAML).

[bmacombe]

@weitzhandler My thought was to deprecate all the old XF XAML and leave them for a period of time to allow easier porting of existing XF apps. I have a rather large one that I'd like to not have to edit every single XAML file to port. But maybe that could be done with conversion tooling instead of leaving the old syntax, which would be fine with me.

But I suspect the current XF xaml will remain, MAUI already seems like a ambitious project to complete while working on another major XF version and supporting XF with current resource levels available.

With XF being retired and only actively supported for a year after MAUI release, they will need to make the XF -> MAUI process manageable.

[bmacombe]

@weitzhandler Thanks, but I understand the difference. I'm fine with leaving XF xaml alone, but it seems to be a big issue to a lot of folks. I just wonder if some small changes could be made to make it seem more normal to people used to UWP/WPF. Without making it code compatible with UWP XAML. But I would suggest that any XAML changes be low priority, so much bigger and high impact things to improve that I'm excited about.

[LanceMcCarthy]

This is an unprecedented opportunity to finally break away from Xamarin.Forms XAML and use the XAML that everyone knows well.

I understand the original rationale that you wanted it to be familiar to Android and iOS devs to get them to use Forms, but we're past that now. If you're going to ask them to learn XAML might as well learn the standard names for elements at the same time.

For starters:

• StackLayout => StackPanel
• Entry => TextBox
• Label => TextBlock

However, we can't stop there, the functional properties need to be re-named as well:

• WidthRequest => Width
• HeightRequest => Height
• HorizontalOptions => HorizontalAlignment (and remove the extra confusing options.e.g. Fill is supposed to always fill and expand)
• VerticalOptions => VerticalAlignment

etc.

Here's a repo to try and align some of the suggestions (fix and suggestion PRs welcome). https://github.com/LanceMcCarthy/MauiSuggestions

[Update 1 - Replaced a promise for examples with link to a repo]

[mossyblog]

Enough with the Xamarin experiment ... regress back to the way XAML worked, throw in WASM into the mix and lets get back to where we left off in 2010 - productive - but now with iOS/Android and new desktop moments ahead.

We can do this.. its the perfect time for it.

[mhmd-azeez]

This thread basically asks for Uno, this is still Xamarin Forms. I don't think they can make such a great breaking change. This is more of a re-branding.

[michaeldera]

XAML is great and would much rather have that as well and I agree with, I agree with the idea of breaking away with Xamarin. Project MAUI is a an exciting opportunity to further develop it..... It was designed with different size devices in mind so it would be great to use that.

It would have been great for the FluentUI on Web controls to actually match those in XAML as well.

[martinsuchan]

I really, really hope that the MAUI XAML Flavor gets Compiled Bindings (x:Bind) from the UWP XAML framework. It's such a major step forward comparing to classic, run-time Bindings in WPF/WP/Silverlight.

[kipters]

I'm on the sentiment of everyone else: not supporting the same dialect as UWP/WinUI is a dealbreaker for me (including x:Bind)

[MartinZikmund]

I really, really hope that the MAUI XAML Flavor gets Compiled Bindings (x:Bind) from the UWP XAML framework. It's such a major step forward comparing to classic, run-time Bindings in WPF/WP/Silverlight.

Compiled bindings are supported already by specifying x:DataType (https://devblogs.microsoft.com/xamarin/compiled-bindings-xamarin-forms/), but having this based on Binding vs. x:Bind would be preferable.

[dhindrik]

I think Xamarin.Forms way of doing compiled bindings is much better than the UWP way. I don't like that I have to specify a "ViewModel property" in the code behind when using x:bind. To set x:DataType is a great way and I think it is much easier to understand for new developers.

MAUI will not be XAML only, and also Xamairn.Forms started with C# only. So I don't think we should talk about XAML, let's talk about how we can create a good object model. Because XAML is just about instating object. So I think it is pretty weird that the namespace for UI elements in UWP is Windows.UI.Xaml. It should be just Windows.UI

[jonathanperis]

Please use this opportunity to unify these markups. If project MAUI is an "phase out" for xamarin, there's no better moment to do this. Wpf's XAML is far mature and well known by the community. If your intention is attract both windows and mobile developers, give them both good reasons to go full head into MAUI

[tomasfabian]

MAUI will not be XAML only, and also Xamairn.Forms started with C# only. So I don't think we should talk about XAML, let's talk about how we can create a good object model. Because XAML is just about instating object. So I think it is pretty weird that the namespace for UI elements in UWP is Windows.UI.Xaml. It should be just Windows.UI

@dhindrik as @emiliano84 already pointed out - we are basicly discussing about XAML dialects. Instantiantion of objects mainly of UI Controls etc., common to all targets. Basically we would like to have a standardized XAML dialect based on WPF or WinUI if it is possible.

---

Based on my experience lot of (not all) iOS and Android developers consider Xamarin.Forms as evil. In practice probably WPF/UWP developers are taking advantage of Xamarin.Forms even more then newcomers from iOS/Android. I consider this as an argument why MS should prefer WPF/UWP dialects over Xamarin, even if MAUI is evolution of Xamarin.Forms as stated in readme. WPF XAML dialect is a good mature candidate.

[legistek]

I've said in other issues but will repeat here -

I'd like to see a totally new set of classes under a System.Maui.Presentation namespace - maybe even its own Nuget package - mapped to http://schemas.microsoft.com/winfx/2006/xaml/presentation with the same names and hierarchical structure as WPF or UWP (doesn't really matter which but just pick one and be consistent; we don't need yet another variant that doesn't deviate in substance). Everything from FrameworkElement down to DataGrid. These would all be lookless / templated controls rather than use native renderers. Obviously things would be implemented over time, many by the community potentially.

For compatibility they can keep everything currently in Xamarin.Core mapped to http://xamarin.com/schemas/2014/forms and keep them using the native rendering system.

Then people can choose which they want to use and potentially mix and match using XML NS prefixes.

I don't even think this has to be an official part of the Maui project as long as certain barriers are taken down, like the hard-coded reliance on http://xamarin.com/schemas/2014/forms as the default NS and many classes that are impossible to subclass.

[dotMorten]

Personally I think it's fine that there are some differences between the object models. Building cross plat creates some interesting problems, like not all buttons can contain whatever content, so a Text property makes sense instead, as all platforms can handle that.

However I do not think that things that are literally the same should be different like TextBlock vs Label, BindingContext vs DataContext, Click vs Clicked event etc etc.

It is also frustrating to see that Forms has continually been adding stuff that diverges even more from other platforms instead of trying to align on at least all new things.

Look I get it... They want to evolve, but they should do so together with the other xaml teams and through common designs. There really should be a xaml/.NET UI API design board covering all flavors.

[legistek]

Completely agree.

I used to be apoplectic how UWP XAML diverged from WPF. And on the most irrelevant things, like WPF requiring "clr-namespace" and UWP using "using". That one little stupid thing made it impossible to share XAML between them. So what did I do? I stopped caring about UWP and dropped it,

[thomasclaudiushuber]

I think the problem is that XAML is just a serialization format with some magic on top, like Markup Extensions and Type Converters. The elements as such are not part of XAML, they are part of the UI framework mapped to the default xmlns.

So, it's more about aligning UI frameworks than aligning XAML (of course, there are XAML-specific features like x:Bind etc.).

This means that the XAML Standard was actually not really a XAML Standard, it was more a UI Framework Standard that tried to align the underlying UI frameworks and their class names / object models.

I agree that it would be much simpler (for WPF/UWP devs) if we would have at least the same names for the same things, like BindingContext vs DataContext, BindingProperty vs DependencyProperty.

And yes, I dream that I create a .NET 5 UI library that is not UI framework specific. In that library I build controls with XAML, and I reference the library in Xamarin.Forms, WPF, UWP, WinUI, and it just works.

But on the other side I know that this is hard. And there are many features in Xamarin.Forms that are different, and some are also more powerful compared to UWP/WPF. Let's take Styles as an example. In Xamarin.Forms, you have things with XAML Styles that don't exist in WPF/UWP: ApplyToDerivedTypes, CanCascade, BaseResourceKey, Style Classes, to name a few.

All these special things make it very hard to align the underlying object model with the one from WPF/UWP. And aligning dialects and especially keep them aligned means also that there are many meetings with other persons, and this might slow down the development of MAUI.

What you should also not forget: There are also many non-WPF/UWP developers who switched to Xamarin.Forms. Introducing the WPF/UWP object model to MAUI would make it really hard for them, as they know just XF, but not WPF/UWP. So, while it's good for win devs, it might be not so good for devs who know only XF.

I think the best thing to do is to continue with the object model of XF as it is, evolve it to MAUI, and improve it in the future. This allows the fastest way to adopt to the market. Let Maui sit on top of iOS, Android, WPF/WinUI. We often try to see Xamarin.Forms as a side-by-side product to WPF/UWP, but actually, it sits on top of it. WPF/UWP is for Xamarin.Forms just a single target like iOS and Android. From that perspective, Android developers could also say: Hey, we should adopt AXML to create Xamarin.Forms UIs.

To be honest, I understand if it's not aligned. My wish is that Maui becomes really great for desktop apps. Then I might just chose Maui for my new WPF/WinUI project instead of native WPF/WinUI XAML, even if WinUI is my only target. Then there's no need to learn 2 XAML dialects for most applications.

[tomasfabian]

@thomasclaudiushuber as I stated before Xamarin.Forms users are probably mostly WPF/UWP developers not Android/iOS devs. They do not like Xamarin at all. In "The jorney to One .NET" Scott Hunter says that the most newcomers to .NET are students. Does MS have statistics about the devs using their products (Xamarin in this case)?

[thomasclaudiushuber]

probably mostly WPF/UWP developers

@tomasfabian Ok, you downvote because of data you don't know? How do you come to this assumption, just because XF is using XAML too?

I know quite some .NET web developers who use Xamarin Forms. They are .NET developers who don't have a WPF/UWP background, but are familiar with the ASP.NET stack.

Why did the Xamarin team introduce things like CSS styling if there are mostly WPF/UWP devs? That wouldn't have made any sense.

Sorry, if we don't have numbers about the background of developers, it's not really good to discuss on this level.

They do not like Xamarin at all.

That's also not true in my experience. I am a WPF/UWP developer, so I must be an exception. While UWP XAML is my favorite XAML dialect, I see there are some pros in Xamarin.Forms XAML too.

My point is: Keep XF XAML for Maui, and evolve it to the best of both worlds in the future!

[legistek]

@tomasfabian we're all just speculating of course but I tend to suspect you're right. MS certainly should have statistics though! I believe they know every project type that gets created in Visual Studio. And I think the whole "Blazor syntax on Xamarin" thing is directly to your point insofar as they know a lot of devs hate XAML (irrationally IMO) and don't understand or see the benefits of MVVM and the strict separation between declarative markup and control logic.

Having grown up with WPF I like Xamarin Forms for what it has the potential to be but I haven't used it for any production projects yet. The different naming conventions are annoying but I can live with them. But the native look thing really turned me off as our application is HIGHLY designed and customized to look identical on web and WPF desktop. Most of all though I generally feel that the XF framework still isn't really robust enough yet to completely replace our WPF desktop app which is used for public presenting and so has to be super reliable and high performance. As I already have to maintain two codebases - web (Angular) and desktop - I don't want to have to have a third just for native mobile; I'd sooner adapt the web app to be mobile friendly and publish it as a PWA.

BUT if I could easily use the WPF codebase to build native mobile versions I would definitely do that. The desktop app would still compile as native WPF, but if I could reuse most if not all of the XAML for mobile then I would run separate builds to those platforms. So that's my (very much biased) motivation for a lot of what I've been pushing for.

[tomasfabian]

@thomasclaudiushuber I down voted your message because I didn't like this statement, not because the data I don't know: I think the best thing to do is to continue with the object model of XF as it is, evolve it to MAUI, and improve it in the future. This allows the fastest way to adopt to the market.

I agree with the first statement, but not the rest. I apologize, I didn't want to make you upset. For me later is much better than sooner. .NET 7 sounds good, too. I had to switch the platform during my career for several times, so this time it could be better with MAUI. I'm very excited about it.

Yes I probably know different iOS/Android devs then you. They have their Flutter, GREAT Kotlin, SwiftUI etc. They don't need Xamarin. This market is (again) probably lost. Thx for your understanding.

[andrewleader]

There should just be one platform/tech, where it's used for both Windows apps AND cross-platform. You don't have to choose between "Do I build a native Windows app, or do I build a cross-platform app?" What if building a native Windows app WAS building a cross-plat MAUI app?

That means insanely reduced documentation (don't have to document two different things), reduced development cost, more developers all using one single tech, and by default everyone gets great cross-plat apps AND great Windows apps!

Edit: Apparently people don't like Xamarin Forms, but I'm indifferent on what platform becomes the platform, if it's UWP XAML, that's fine with me, as long as there's only ONE type of app, regardless of cross plat or native Windows!

[robloo]

Lots of good comments! A few more ideas so far:

• It's good we are hearing valid points from both sides. I respect all viewpoints although I strongly favor keeping the same XAML/object model standard with Microsoft tech (more on that below). The fact that MAUI is now getting merged into .net itself -- with a XAML flavor different from WPF which is already in .net -- gives me a sinking feeling Microsoft isn't doing the right thing.
• Both viewpoints have the same, valid, reason not to change XF XAML one way or the other. What is best for developers is to build off of the old tech and evolve into new territory. Not completely reinvent the wheel. Now we are stuck in a very tricky position where some developers are already used to Xamarin Forms XAML and don't want to change it. Then the rest of us are wondering who in their right mind signed off on different XAML in the first place and why it's changed from the existing WPF/UWP code we have. Everybody has a point and all points are the same -- don't change what already works. Bottom line though, the ORIGINAL mistake was creating a different version of XAML. Always fix the original mistake if you want to make progress in the future. A compatibility layer to convert existing Xamarin Forms XAML would be possible.
• Speaking of evolving into new territory, I'm fine with evolving XAML (something like this: https://github.com/microsoft/microsoft-ui-xaml/issues/2499). However, we can't keep creating new frameworks with less-and-less features and doing things in a slightly different way. Microsoft is needlessly fragmenting the ecosystem. Xamarin Forms was out of touch with what most developers were looking for when it was first released. Sure, people have some uses for it but the apps tend to be very basic. I'm wonder if Microsoft realizes this now and has a roadmap to make MAUI really powerful -- like Uno Platform, like what UWP should have been all those years ago.
• When I created the issue I was hoping for an official response from Microsoft. I don't think they've commented yet. That is probably a good thing as it means they are still having these discussions internally and haven't made up their mind yet.

There should just be one platform/tech, where it's used for both Windows apps AND cross-platform... Regardless of whether the convergence happens into MAUI or into WinUI doesn't really matter... however converging onto MAUI seems like the easiest and most simple approach (and then WinUI would go away).

This is what developers have been asking for from day one. For various reasons a lot of the other frameworks are not desirable for developers coming over from the desktop. For the most part the existing frameworks just aren't powerful enough -- in feature set, in control rendering capability, in performance, etc. Microsoft still has a chance here (although Uno is really close). MAUI (Xamarin.Forms right now) isn't powerful enough to be a general purpose cross-platform development platform. Simply put, the problem is the original architecture taking a least common denominator approach. This is useless for anything more than basic 'showy' apps. Therefore, I disagree with your recommendation to converge around MAUI in it's present form.

[legistek]

Bottom line though, the ORIGINAL mistake was creating a different version of XAML. Always fix the original mistake if you want to make progress in the future. A compatibility layer to convert existing Xamarin Forms XAML would be possible.

Just in case anyone isn't aware, XF started out independent of Microsoft. It evolved from Mono which was basically open sourced .NET for Linux. Windows wasn't even a platform option for Xamarin Forms before UWP and Xamarin was never marketed as a way to port WPF apps to mobile but rather just a way to write mobile apps with C#.

So there wasn't a huge incentive to use the WPF naming conventions and it's possible - and I'm only speculating - they didn't want to get in potential trouble by doing so.

That said, now that it's all part of Microsoft, it indeed makes no sense for there to be two (arguably 3 if you include WPF v. UWP) products with different XAML flavors.

[ederbond]

Yes, people can't blame MSFT for XF not having the same XAML syntax of WPF or UWP. It was born inside another company. But now that MSFT owns Xamarin, it makes totally sense to merge everything and come up with a single XAML flavor. And Maui seems to be the perfect opportunity for it. @PureWeen @StephaneDelcroix @davidortinau

[nikolalukovic]

It would be an incredible blunder and a real shame if MSFT didn't take this chance to revitalize XAML and unify it under one flavor(UWP one would be the best imo).

[weitzhandler]

@andrewleader agree there needs to be a one and only solution, but for it to become the one and only it has to be the one with the best architecture, which to me XF is not.

[PureWeen]

I feel like there are a few things to unpack on the original post that don't really relate to XAML but the large focus of the comments have been about XAML so I'd like to touch on the non XAML things a bit first (sorry everyone :-p)

The readme definitely needs a bit more content https://github.com/dotnet/maui/blob/build/README.md

But it has a general roadmap of what we are a planning and scenarios we are aiming to simplify. A lot of the direction will be influenced by these conversations!! So, it's really exciting reading everyones comments.

A few questions about your original post

If this is built on Xamarin Forms, what are the commitments in terms of bug fixes? Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them.

dotnet MAUI isn't just a rebranding. It's restructuring of the whole native layer and modernizing around net6 features and multi targeting. It's shedding as much legacy as we possibly can so that we can simplify and focus better. There's a huge focus on making switching to a native context much simpler. No more custom renderer attributes. Ideally you'd never have to create a custom renderer ever again.

Here's an issue talking about the new renderer structures and some linked videos https://github.com/dotnet/maui/issues/28#issuecomment-632390588

The architecture is non-ideal for custom controls as well. Xamarin Forms is notoriously difficult to work with in an advanced way because of bugs and the complexity to fix them.

Can you expand on these statements with some examples? These are the scenarios we really want to simplify so I'm really curious to talk about the difficulties here

Honestly, I would like to use a Microsoft-backed cross-platform UI framework but Xamarin Forms is a poor choice for stability and the XAML differences from WPF/UWP.

Does this all have to be boxed together? If you felt really confident about the stability and if the feature set is there would you still not use dotnet MAUI because differences in naming?

@weitzhandler

lacks a lot of desktop I/O features and desktop-related APIs

What are some of the main APIs that are missing for you?

UWP and WinUI in the other hand, were designed to accommodate for any type of device or screen size from day one. Plus it's Fluent compatible.

Same question but now about Fluent :-)

[weitzhandler]

@PureWeen thanks for your kind response, might be worth adding MS officials as members.

What are some of the main APIs that are missing for you?

I admit I haven't used XF in a while since switching to Uno, but here are few, probably some of which have already been addressed: ItemsControl, CheckBox, RadioButton, Expander. I also remember having a hard time seeing keyboard and mouse for proper UX.

UWP and WinUI in the other hand, were designed to accommodate for any type of device or screen size from day one. Plus it's Fluent compatible. Same question but now about Fluent :-)

WinUI is Fluent ready by design. XF is "native look and feel" and takes an extra step. Plus as mention earlier by other members, it's not just about fluent, it's about the overall design that should apply equally on all platforms by default. Native look and feel should be achieved with a theme, if desired.

[tomasfabian]

hello @PureWeen, I explained why is the naming important before (new/existing users adaptation). If you would ask me:

If you felt really confident about the stability and if the feature set is there would you still not use dotnet MAUI because differences in naming?

I would use it. More important enhancement for me is the direction/purpose of MAUI regarding to web targeting. Please add your comments to this thread created by @legistek. For lot of us a more relevant question is: Should I use rather Uno platform, Flutter, something else instead of MAUI due to missing XAML support etc for web? See my post in the other thread.

Thank you, howgh.

[bkaankose]

Imagine a world where my responsive XAML for my WP8.1 (RIP) app I developed a few years ago just works when I copy-paste it into MAUI project, and it just works on all platforms MAUI supports.

This is really the best time to unify XAML's (preferably based on UWP) and make major underlying platform changes. Bring back XAML Standard and continue supporting it with the community. There are thousands of contributers out there to help MS build this potentially game changer approach.

[PureWeen]

I admit I haven't used XF in a while since switching to Uno, but here are few, probably some of which have already been addressed: ItemsControl, CheckBox, RadioButton, Expander. I also remember having a hard time seeing keyboard and mouse for proper UX.

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/checkbox https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/radiobutton https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/expander

A couple are still in preview but they will be out of preview before Dotnet Maui

WinUI is Fluent ready by design.

Can you give me examples? I Just want to make sure we're on the same "fluent page" with this one

it's about the overall design that should apply equally on all platforms by default. Native look and feel should be achieved with a theme, if desired.

We're also focused on this with upcoming XF releases and material releases. For example https://github.com/xamarin/Xamarin.Forms/issues/10773 https://github.com/xamarin/Xamarin.Forms/issues/10774

And a lot of the roadmap for 4.7 => 5.0 https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap

Is based around achieving these goals. Increasing the level of pixel perfect customizations

[weitzhandler]

Impressive work indeed. The final bummer that had me leave XF was when they announced Shell I was so anxiously waiting for, then it came without UWP support.

Anyway, sorry but to be honest, with Uno on board, I'm not considering to switch back to XF. I never liked its object model. Always felt to me like a bunch of patches and fixes, where the UWP/WinUI object model is pre-thought and engineered right from the beginning.

And let's not forget, Uno IS Xamarin. It's Xamarin.iOS and Xamarin.Android, just not Xamarin.Forms. Uno is what XF should have been in the first place. Xamarin.Forms came in and reinvented the XAML wheel, to me, in a bad way.

My favorite is UWP/WinUI XAML, but as mentioned around, all missing WPF features should be brought over, like binding types, markup extension services etc.

[PureWeen]

@bkaankose

Imagine a world where my responsive XAML for my WP8.1

Is this purely a comment on naming symmetry or missing features? What responsive XAML features are you missing in XF?

[XamDR]

I'm just an undergraduate student, but I'd like to share some thoughts about this discussion. As many have said, having different XAML dialects makes things like porting apps more complicated. I understand that in some cases the differences are necessary, but there are things that are literally the same but with different names, e.g., StackPanel vs StackLayout. So if there is a chance to change and 'fix' these little things, it would be great.

Now, about which flavor of XAML should be chosen, in my somehow biased opinion, I think that the WPF XAML should be the one chosen. It has the more complete XAML dialect, there is even an issue on Microsoft UI XAML repo about this. From what I've have learned so far, it seems that Xamarin Forms XAML already has many of the features missing in that repo, like binding to relative source with find ancestor mode so I think that choosing WPF would make things easier. Lastly, since WPF is more popular than UWP, this should be another reason to choose WPF XAML dialect.

[Panda-Sharp]

There were even some xamarin xaml standard controls in preview https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/standard now they disappeared

[thomasclaudiushuber]

I got a lot of downvotes on my comment above (which is great for the discussion), and as @tomasfabian pointed out, it might be mainly because of this:

I think the best thing to do is to continue with the object model of XF as it is, evolve it to MAUI, and improve it in the future.

I thought I should add some details why I wrote that, because some of you know that I love WPF and UWP/WinUI.

The quote above is a small sentence that collides with many opinions here. And when I wrote it, I knew I won't make friends here. So, let me explain a bit more why I wrote it.

I'm a WPF/UWP/WinUI dev, and I love WPF and UWP XAML. Currently I'm also working on a Xamarin.Forms project, and yes, it's much better than what it was when I have used it the last time. I like it. But as many of you, I would love to see WPF/UWP XAML used for MAUI.

The naming differences between the Xamarin and WPF/UWP stacks are weird. There are many things I would change, like these, to name just a few (and many were already mentioned by others here):

Type	Xamarin Forms	MAUI
Class	AbsoluteLayout	AbsolutePanel
Class	BindableObject	DependencyObject
Property	BindableObject.BindingContext	DependencyObject.DataContext
Event	BindableObject.BindingContextChanged	DependencyObject.DataContextChanged
Class	BindableProperty	DependencyProperty
Event	Button.Clicked	Button.Click
Class	Entry	TextBox
Class	Layout	Panel
Class	Label	TextBlock
Class	RelativeLayout	RelativePanel
Class	StackLayout	StackPanel
Class	VisualElement	FrameworkElement
Property	VisualElement.Height	FrameworkElement.ActualHeight
Property	VisualElement.Width	FrameworkElement.ActualWidth
Property	VisualElement.HeightRequest	FrameworkElement.Height
Property	VisualElement.WidthRequest	FrameworkElement.Width

But then, on the other side, I see so many other things that are different, and that can't be resolved with renamings. For example HorizontalOptionsvs HorizontalAlignment. It's not the same, as the HorizontalOptions have the things like EndAndExpand, while HorizontalAlignment has just Left, Center, Right, Stretch. So, this is the first thing that needs a changed API to align it. It's not too hard in this case, but then when you go through the Xamarin.Forms class hierarchy, you see many another APIs that need to be changed to align it, for example, where is the Control class? (Don't answer it, it's a rhetorical question :)). And then you go deeper and deeper into the class hierarchy and you notice, it's kind of impossible to make it really clean without rewriting the whole Object Model including all the base classes. Take a look at it here .

My UWP/WPF developer heart says: Yes, this is what I want to have, so rewrite that thing. I want to build cross-platform .NET applications with UWP XAML and UWP Object Model (Hi Uno, I know you're there.).

But I see that it means actually a rewrite of the whole Xamarin.Forms stack. And at the same time I see all the improvements the team plans for MAUI, and I love them.

I think rewriting the whole stack for .NET 6 is quite hard (is it even possible?) with all the other planned and also very important features. And this is how you should understand this statement:

I think the best thing to do is to continue with the object model of XF as it is, evolve it to MAUI, and improve it in the future.

This statement means not that I believe that XF XAML is the best option. I think due to the reasons mentioned above it might be the best plan to continue with XF XAML. And then, evolve it to the best of all XAML worlds in the future!

In an ideal world, it would evolve to the best of all XAML worlds with the MAUI release.

And yes, I agree, if we don't change things like StackLayout=> StackPanelnow, it might be much harder to change it after the MAUI release. And if a try-convert tool is planned anyway, it could do that string replace for code like StackLayout => StackPanel.

And, for the final word I quote @dotMorten

There really should be a xaml/.NET UI API design board covering all flavors.

PS: I love the passion and discussion I see here. Keep it up!

PSS: @tomasfabian I was not upset, I wanted to understand your opinion. But I see that my written words were maybe a bit too direct. Sorry for that, there was no reason for you to apologize! Thank you for your great response!

[Happypig375]

For example, where is the Control class? (Don't answer it, it's a rhethorical question :)).

Xamarin.Forms.View

[legistek]

Xamarin.Forms.View is not remotely the same as WPF's Control. It doesn't support templating. It doesn't allow you to override input event handling behavior.

[Happypig375]

Xamarin.Forms.View is not remotely the same as WPF's Control. It doesn't support templating. It doesn't allow you to override input event handling behavior.

The hierarchy is the same, and the features missing is exactly the point of this discussion around MAUI.