[Spec] Major Breaking Changes Proposed for Xamarin.Forms 5.0

[samhouts]

WHAT??

Xamarin.Forms 5.0 is the last major version of Xamarin.Forms. New major features and development will now be in .NET MAUI and the Xamarin Community Toolkit. We will continue to fix critical and high impact bugs in Xamarin.Forms in regular patch releases.

To ensure that Xamarin.Forms is in a maintainable and stable state, we propose to make the following breaking changes.

Move MediaElement to Xamarin Community Toolkit

This is currently experimental. As it was a fantastic contribution by the community (thank you, @peterfoot!), we hope that it can continue to be maintained and improved during this transition period in the Xamarin Community Toolkit.

Move C# Markup Extensions to Xamarin Community Toolkit

This is another amazing community contribution (thanks @VincentH-Net). As I mentioned here, we want this to continue to be worked on and innovated--and right now, the best place for that is in the toolkit!

Move Expander to Xamarin Community Toolkit

Thank you, @AndreiMisiukevich, for contributing this awesome control! We love it, and we want to see it improved. As such, we'd like to see it in the Xamarin Community Toolkit, too.

Remove support for Visual Studio 2017

We've kept support for Visual Studio 2017 for as long as possible to allow our loyal customers to continue to work in their favorite version of the IDE. However, the world moves on, and sooner or later, it will be necessary to update Visual Studio to take advantage of modern mobile bits, including critical security fixes in the native platforms. Rather than introduce a breaking change later in the maintenance cycle when that point occurs, we'd like to make this change now.

Cease publishing DataPages, remove from solution

DataPages was released in preview quite some time ago, and we've continued to publish updated packages since. However, it is no longer on our roadmap, so to make the solution leaner, we'll remove it and all associated projects.

Rename MasterDetailPage

The name MasterDetailPage is not descriptive and does not map to any modern mobile concepts.

We're open to ideas on what to call this. Current working list:

• SplitPage
• SplitView
• ListDetailPage
• CollectionDetailPage
• ParentDetailPage
• OverviewDetailPage
• HierarchicalView

Remove UIWebView

iOS apps cannot be published if they reference UIWebView

Remove XFCorePostProcessor.Tasks

This projects injects IL to maintain XF 2.5 compatibility. We're far enough away from XF 2.5 now that this weaving should no longer be necessary

#2880

[mackayn]

Never used data pages, few have so makes sense to remove, seems like a pragmatic list. SplitPage or ParentDetailPage gets my votes. Moving the other great contributions into the toolkit means they can evolve faster as 5.0 is the last major release before MAUI hopefully appears sometime.

[AndreiMisiukevich]

MasterDetailPage -> DrawerPage (?)

[grimorde]

My vote for ParentDetailPage.. although I do like @AndreiMisiukevich 's suggestion of DrawerPage too

[VincentH-Net]

Push C# Markup back out of Forms!?

To all 250+ community members who voted to integrate the community CSharpForMarkup in Forms, making it the most wanted PR in the history of Xamarin Forms by far:

If you are surprised, worried and/or confused by what seems to be a plan to undo all this (what!? indeed) - so am I.

Encouraged by @davidortinau, I hustled to get the C# Markup Part 2 PR in before the deadline for new functionality in Forms, and made sure it is solid with documentation, 100% code coverage, low impact and minimal team effort to merge. All this so Forms devs would not have to wait to use the new C# Markup goodness until after MAUI stabilizes, and don't need to migrate existing projects to MAUI to benefit from these improvements. Needless to say this is not the reaction I expected.

As @davidortinau mentioned on Twitter, the intention was that @Clancey and I work together during the MAUI design phase to shape an optimal, unified C# Markup for MVVM and MVU - see the MAUI Spec.

I do see serious technical and commitment problems with this move, esp for MAUI.

But before I get into that, as per the invite by @samhouts I am first discussing this with the team on discord, to understand why they would even want this, and what their intention/commitment is for the future of C# Markup in Forms and MAUI - for MVU and MVVM.

I will work to address any concerns in the team that may have lead to this idea, or possibly propose a less damaging alternative.

After that discussion I intend to update here and involve the community.
In the mean time do chime in. Let the team know how you feel about this. Thanks!

PS Let's keep this constructive - if you don't like/intend to use C# Markup anyway, please don't react. The idea is to get feedback from the developers who will be affected by this

(I 👎ed at the top of this spec and 👍ed this comment below)

[mattleibow]

What does the MasterDetailPage actually do on all the platforms? Is it basically a Flyout container?

Maybe Flyout is better as we have been using that word instead of master or split?

[almirvuk]

I would also use Flyout term for MasterDetailPage

[jcmanke]

I'm not entirely against renaming MasterDetailPage, but it's something I would just do for MAUI and not in the last release of Xamarin.Forms.

On a different note, may I propose the breaking change of removing the UIWebView renderer for iOS?

[MagicAndre1981]

Remove support for Visual Studio 2017

NO, VS2017 is rock stable, VS2019 only has bugs in each new update. DON'T DO THIS!

[DeerSteak]

Since the current MasterDetailPage is really just the flyout and the menu, I'd prefer to call it FlyoutPage, or maybe MenuParentPage.

DrawerPage is also a good description for Android, but the iOS implementation slides everything to the right. Maybe if it was also changed to an overlay on iPhones, I could get behind DrawerPage. Shell does it as an overlay already, not sure why MDP was left behind.

The timing doesn't bother me. We use a few here and there and changing the inherited class wouldn't be time consuming.

[johnshardman]

Overall, seems like a pragmatic approach. However, whilst I understand the plan to rename MasterDetailPage in XF 5, I would be tempted to leave it as is in XF and only do the rename in MAUI.

[nbevans]

Is it just me that thinks none of these seem particularly "major breaking"? Probably the rename of MasterDetailPage is the only one and that's a trivial fixup for any codebase. Easier than some "minor breaking changes" in XF history for sure.

[hartez]

While we're here, I might as well add some visibility to another breaking change proposal: #11823

[dotMorten]

Why on earth would you introduce major breaking changes in the last major release of XF? Isn't breaking everyone with MAUI enough?

[balbarak]

MasterDetail -> HierarchyPage

Also, SplitPage looks good

[MelbourneDeveloper]

Rule of thumb for any framework: if the feature can be moved up a level and doesn't need to be in the core to work, it shouldn't be there.

Everything that isn't core XF should be in the community toolkit. We're mostly talking about phones. The less bloat, the better.

[dotMorten]

@MelbourneDeveloper Second rule of thumb: If the feature is already there, moving it somewhere else is incredibly disruptive and keeps people from moving to newer versions. Also 3rd party libraries that rely on these would suddenly be broken, so you risk breaking the entire ecosystem. Breaking an ecosystem while XF is drawing closer to it's ultimate demise (as in being replaced by .NET MAUI) makes it a tougher sell for 3rd parties to continue supporting it.

[samhouts]

@dotMorten Which of those features, if moved, would be disruptive to you? They're all experimental, with the exception of MasterDetailPage.

[dotMorten]

I think that's fine for experimental features - when you chose to use those, you took on that risk.
Also I assume VS2017 isn't an "experimental feature" ?

Wrt MasterDetailPage: You're discussing a rename. That's a thing that doesn't buy anyone anything. It's just a minor mob-up because the name turned out not to be perfect. IMHO it in no way justifies introducing a breaking change over. I don't see how this change supports the goal of this issue to "keep Xamarin.Forms in a maintainable and stable state".

I'm mostly just against the entire notion of even considering introducing breaking changes at this point. As a 3rd party Xamarin.Forms library developer, stuff like this really worries me. When you break stuff, you risk breaking us, and all the customers that use our stuff. I'd risk being stuck with supporting customers on both 4.x and 5.x at the same time. That's not a situation I want to be in - from a resource point of view I might just decide to drop XF 5.0 support completely and move to .NET MAUI. I'm not sure that's the intent you had, but there's only so many platforms I can support at the same time, and XF has its foot in the door already.

[knocte]

I’m going to be playing a bit of devil’s advocate here.

What’s worse? An unexpected regression or an announced breaking-change? The latter is not only warned in the release notes, it's also brought up to you by your compiler before you try to deploy your application! And what causes the former? Too much churn, too much functionality to maintain, new features that break existing features when landing on new versions.

Granted, moving from Xamarin.Forms to Maui may require a bit of overhead by the community already, but that’s an step that you should already take as a necessary evil. If you think this is too much work, then just do a migration to XF5 first, and then postpone the migration to Maui to 2 years later (or more) when/if Xamarin.Forms stops receiving updates. It’s a small price to pay to get a bit more stability.

I, for one, prefer breaking changes that increase stability of newer versions down the line, than no breaking changes and discovering unexpected regressions (or having my users, and not my developers, discover those regressions) when upgrading.

[VincentH-Net]

Push C# Markup back out of Forms!? - Update

I do see serious technical and commitment problems with this move, esp for MAUI.

But before I get into that, as per the invite by @samhouts I am first discussing this with the team on discord, to understand why they would even want this, and what their intention/commitment is for the future of C# Markup in Forms and MAUI - for MVU and MVVM.

I will work to address any concerns in the team that may have lead to this idea, or possibly propose a less damaging alternative.

After that discussion I intend to update here and involve the community.

As promised, I discussed with the team on Discord to find out their reasons and constraints. I did a thorough analysis and just shared a complete proposal there that to the best of my knowledge would be:

• less work for the team than moving C# Markup out (both in the coming 2 months and the coming 2 years)
• leave C# Markup in Forms 5 without experimental
• result in a better migration and better unified C# Markup api for MVU and MVVM in MAUI

I am now waiting for the team response on discord, to see if we can come to a commitment (also for me).
I will update here with the proposal and substantiation why this will work, once we agree and details are OK to publish.

Thanks to all who supported keeping C# Markup in Forms 5 (atm 32 👍, which is more than the 👍 for the entire spec)
Keep it coming!

[mattleibow]

To be honest here, the rename of master detail page does seem a bit weird.

The thing I would first see if it were possible to insert the new type between the layers so master detail now inherits from Flyout page. This will tell people that mdp is old, use the fp. This is what I would do. The obsolete warnings could help with the migration process as opposed to suddenly nuking a type.

If this can't be done, then I think the reason for we picked a bad name seems weak. Especially since this is a well used library. Rather wait until you make a new library.

[prashant-gupta-dev]

I am now waiting for the team response on discord, to see if we can come to a commitment (also for me).
I will update here with the proposal and substantiation why this will work, once we agree and details are OK to publish

Hi @VincentH-Net - are there any updates here or when do you expect to hear back?

Thanks!
Prashant

[VincentH-Net]

Hi @prashant-gupta-dev, thx for asking. I will be talking to key people next week; some were are on holiday this week. Will update after that!

[softlion]

@VincentH-Net I hope this markup style will be the exception, not the default. Creating markup in code is not maintainable
and not a good practice. It's good for school projects and small custom controls.
I had a developer 4 years ago who created all its views in code. 2 months after he left, changing anything in his code means rewriting everything in xaml as it was much faster in addition to have a working preview.
And i don't write about the spaghetti code mixing logic with UI ...

[ionoy]

@softlion Can you provide any reasons why markup in code is less maintainable than XAML? It's my understanding that the opposite is true. C# provides a better separation of concerns, expressivity, refactoring tools. Everything you need to write clean and maintainable code.

I guess XAML can save you from accidentally mixing logic and the UI. But this restrictiveness can also be harmful if you need to create a complex UI interaction.

[softlion]

@ionoy Open a poll and see the results :)

[Feroks]

@softlion Have you seen the syntax for C# markup? It is not what WinForms used to be. It has great separation between View and logic stored in ViewModel.

[VincentH-Net]

@Feroks wrote:

@softlion Have you seen the syntax for C# markup? It is not what WinForms used to be. It has great separation between View and logic stored in ViewModel.

FYI I currently have framework quality code and patterns to implement C# Markup like below across Forms / MAUI, even within the limitations of C# 8, with close to zero allocation (no GC pressure) and a fully focused Intellisense experience in each location of the Fluent call chain:

more info

This breaking change move triggered me to implement MAUI features now instead of waiting for .NET 5 + C# 9 ga.
Btw this is also applicable to other .NET UI frameworks.

[VincentH-Net]

I am now waiting for the team response on discord, to see if we can come to a commitment (also for me).
I will update here with the proposal and substantiation why this will work, once we agree and details are OK to publish

Hi @VincentH-Net - are there any updates here or when do you expect to hear back?

Thanks!

As promised, here I am with a summary and the outcome, which is positive.

Last Tuesday I had a call with the Forms team. I am quite honored by who attended (most of the Forms team but also e.g. @jamesmontemagno); key in this meeting for me were @davidortinau and @Clancey :-)

I demoed my approach for the final MAUI C# Markup pattern and how a stable subset could be taken from that to include in Forms 5 (since that demo improved even further, now with practically zero extra allocations).

My two concerns were addressed by feedback from @davidortinau and @Clancey:

1. Concern: By moving C# Markup out of Forms to the Xamarin Community Toolkit, adoption of C# Markup in enterprises would not progress until after MAUI is released, because it would not be "blessed" by Microsoft.
   .
   This was addressed by the explanation that the Toolkit is just another Microsoft .NET library like many other Xamarin libraries. This was a misunderstanding by me based on the communication here and the GitHub repo name XamarinCommunityToolkit.
   .
   The library is published on NuGet as owned by Microsoft Xamarin
   .
   To my question how we could prevent companies making the same wrong assumption I did, David offered to talk internally about updating the Xamarin Support Policy to make clear what libraries are included for paid support. Tbc.

2. Concern: how are we going to ensure that MAUI C# Markup for MVU and MVVM is well aligned if we move the MVVM code out of MAUI first? Won't we run the risk that they diverge and MVVM C# Markup would have to be bolted on after the fact in MAUI, creating unnecessary differences between the two models for devs?
   .
   This was addressed by James, who after my demo said both are already almost completely aligned, with the exception of two elements I use to simulate C# language support for markup: eliminating the new keyword with static factory methods and eliminating repeated enum type names in property values with a fluent subchain. Those two language changes are under discussion with the C# language team, although outcome tbd and eta unknown at this time (do we have a language proposal link yet @Clancey?). But this makes it understandable to me that the team prefers not to include those workarounds under the strict new .NET system namespace guidelines, since deprecating them later on if and when C# language support for markup arrives would be frowned upon inside Microsoft.
   .
   James and I also agreed to keeping each other in the loop should anything change.

Since my concerns were addressed, I agreed to C# Markup being moved to the Microsoft ;-) Toolkit.

I expect this to evolve rapidly , free from red tape, and benefit MAUI even before V1. Will update as needed,
Thanks for your support all!

[mattleibow]

@VincentH-Net Thanks for your work and sticking around to make sure all the points were addressed. I know I am more a XAML guy, but I do know lots of people like just C# and all the benefits of that. Looking forward to even more rapid progress in the new toolkit!

[spouliot]

Please consider removing all references to UIKit.UIWebView inside 5.0 - so that even a un-linked XF app can't trigger Apple's warnings (or errors).

c.c. @PureWeen

[PureWeen]

@spouliot

#12095

[lassana]

Rename MasterDetailPage

Wouldn't this break other frameworks like MvvmCross? If so, the change is not acceptable.

[Dmbandit]

By the way, about HotReload - I did not use this option at once.
So for me and my company this is the most useless feature.
But the slow CollectionView is a problem and shadows, and shapes. And other basic controls.

Found Hotreload really useful, obviously for code 1st approach it's not. Regarding other issues, the comments from the team above suggest they want to address these stability issues, that includes reducing the core footprint of Forms...but for C# markup, I can totally understand the concern and they must have known the noise this decision would generate and I think the people who pushed for this deserve an official response from the team.

Same, HotReload is amazing and saves a ton of time for me and my team!