[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

https://github.com/xamarin/Xamarin.Forms/pull/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: https://github.com/xamarin/Xamarin.Forms/discussions/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.

[nbevans]

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.

The reasoning for renaming the MDP does seem vague. "Does not map to any modern mobile concepts" - really? I'm guessing the real reason is that it contains the 2020-banned word of "master" ;-)

Also, renaming the type itself won't be enough. There are members on it called Master and Detail, and numerous other traces of those terms all over the place. So those will renaming too which increases the level of "breaking" of the change potentially.

FWIW I think "flyout" is a very bad idea to use as its new name. This is an overloaded term and has different meaning in the 3 main platforms. I personally would go with something like SplitPage or DrawerPage.

[Saturn]

The name MasterDetailPage did initially confuse me although I am not sure if any of the alternative name suggestions make it less confusing?

[alexrainman]

Why we don't remove Xamarin.Forms once and for all?

[KSemenenko]

It's not clear to me why you need to make separate libraries. Most of all, I do not like to put 100500 NuGet packages. And why split everything into a large number of packages when you still have to install them all.

[AndreiMisiukevich]

It's not clear to me why you need to make separate libraries. Most of all, I do not like to put 100500 NuGet packages. And why split everything into a large number of packages when you still have to install them all.

Just three :)

Xamarin.Forms (Core things for the most simple apps) XamarinEssentials (Specific APIs like BT/Vibration/Connectivity etc.) XamarinCommunityToolkit (Specific Views / Helpers / Behaviors / Effects etc.)

Why do you think it's bad?

[KSemenenko]

@AndreiMisiukevich but these three libraries need to be installed. What's more, you need to know what they need to be installed. Okay, Essental, we can use it separately in Xamarin native. But XamarinCommunityToolkit is definitely dependent on Xamarin.Forms and we need to add it to the project to have everything we love to use.

You get the same as with npm, a bunch of small libraries and dependencies that are necessary to start a project. I don't like it. but this is my personal opinion :)

[jcmanke]

@KSemenenko It's entirely possible to write a Xamarin.Forms apps without installing Xamarin Community Toolkit. We've all been doing it for years. If you don't want a new dependency just don't install it and continue to use your own implementations of whatever common converters/effects/behaviors you need.

[DeerSteak]

Apple still uses the Master-Detail verbage in Xcode iOS templates. I see the value in changing it, but after giving it some thought, it does seem like MAUI is the right place to do that unless someone's going to build a migration assistant for XF 5. Unless you want to alias it, keep it around as deprecated in 5.0 as something that just returns its replacements and remove it from MAUI. I'd be all for that.

@KSemenenko before this thread I'd never heard of the Xamarin Community Toolkit. Apparently I'm missing out.

[KSemenenko]

if we use XF, and xaml and bindings, why do we need another library for basic functionality? And yes, I believe that all converters, extensions for XAML, behavior are basic functionality. WPF has everything at once.

And the other question is, what difference does it make how XF will do it if all of us switch to MAUI in a year?

[DeerSteak]

I am super not going to switch to MAUI in a year, or even when XF5 hits end of life. As long as we can build apps that will be accepted by the Apple and Google app stores, we'll let MAUI mature a bit.

[KSemenenko]

It's like you're renting a car, but you have to rent the pedals and the steering wheel too. You could say - but I'm a racing driver and I need a special steering wheel. And I don't want three wheels in my car.

But we do have a Linker that will cut out the unused code from the final assembly. So there won't be any extra steering wheels in our application.

[KSemenenko]

@DeerSteak would MAUI be so different from XF?

[DeerSteak]

@KSemenenko I don't know. We'll let the rest of you figure that out for us. LOL

[bmacombe]

XF won't be able to accept new features once 5.0 hits. So the toolkit is going to be where that happens between XF 5 and Maui. I believe the plan is for many things in the toolkit to be moved into Maui once it releases. @davidortinau also mentioned in a chat that with being moved into the .net namespace they can no longer ship experimental features, so the toolkit will be where those features exist until they mature and can be added to Maui. These are all signs of a maturing platform.

[filipoff2]

J> 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?

Have that something with witch hunt for word Master? Please remember that for most .net debs around the world English is not first language. Sure let's change it and be more confused. Ms is knows for keeping namespaces, and marketing names windows mobile, windows phone, universal platform, Metro ui modern ui.. I would be happy if could send someone from Ms bill for time for redactoring, subscription for proper tools to do refactoring, codereview, retest, asking and fighting for that time with customer, team, interested of delivering new features... Yupp Very needed change.

[dwightbennett]

I dont really feel a rename of MasterDetailPage is necessary, but if I get a vote, I vote for DrawerPage. I think it could be beneficial if we can get quicker releases and bug fixes with the experimental controls in the toolkit but I hope they are all being ported to MAUI so we don't lose them. Also does anyone know if is there documentation on what is in the toolkit somewhere with pictures or gifs so we can see what's available?

[quiest2000]

Rename MasterDetailPage

Plz let the name as it was in XF. Just do it in MAUI

[AlleSchonWeg]

My wish is, that more people from microsoft working on the project to fix issues. To many bugs and growing.

[acuntex]

I'd be happy if basic controls that are used in most projects like Editor and CollectionView would perform as intended.

E.g. the placeholder of Editor (Visual Default) is a joke, it's completely misplaced. or collectionviews ignore ItemSizingStrategy="MeasureAllItems" if they are resized.

These are BASIC things, bugs exist since forever and no one cares because you can't write fancy blog posts or create fancy youtube videos for own personal gain.

[KSemenenko]

I agree with you @acuntex, the itemtemplateselector for header and footer in listview works with bugs. CollectionView doesn't cache the datatemplate and works slowly. DataTemplateSelector for a specific type cannot be defined in XAML.

And these are all very basic things.

[DeerSteak]

@acuntex @KSemenenko The current Editor is also awful in Visual=Material, where it ignores line sizing and auto sizing, and bleeds into other controls when the text gets too long. I don't think it's too much to ask for controls that don't sabotage a data entry form.

[acuntex]

@KSemenenko @DeerSteak Indeed, but instead we get new feature in every version like Gradients who are used by a fragment of developers. And there are great libraries like https://github.com/mgierlasinski/MagicGradients where you can create much more gradient types, even with css expressions.

But again: You can't write fancy blog posts about "We made it work the way it was always intended and documented for years."

I don't know if Microsoft employees have to reach a quota of blog posts or if they just want to be noticed to get off this project. Anyway it is wrong.

Which Microsoft Executive is responsible for Xamarin anyways? Does he/she know that Xamarin.Forms is basically again at the POC-stage?

[KSemenenko]

I've been waiting a couple of years for gradients, shadows and shapes to draw. And I'm honestly glad it's finally realized. But the bugs that have been open for years, the pool of requests that have been open for years.

I like XF, but I expect features like in WPF or UWP. And of course the bugs, all very long and very slow.

It's a Microsoft product. I don't understand why it's like this when without a bunch of libraries from github enthusiasts it's impossible to build a normal project.

@acuntex @DeerSteak

[KPixel]

The issue with bugs has already been discussed at length here: https://github.com/dotnet/maui/issues/109 The Xamarin team's response was that they have started focusing on fixing bugs, and that will continue for the next year.

You can see their planning here: https://github.com/xamarin/Xamarin.Forms/projects

[acuntex]

@KPixel I'll believe it when the team finally starts to fix controls that should work in a stable cross platform library. There are bugs that have an incredible high impact on stability, yet these bugs are open for months or even years.

But this doesn't seem to be their priority, it seems much more important to rename the MasterDetailPage.

[alexrainman]

@acuntex thats the reason i stopped using XF and supporting my open source libraries.

[PureWeen]

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

The point of these breaking changes is to make maintenance of 5.0 easier so we can address and focus on more critical bugs.

For example, VS 2017 support has been a major drain on resources in a number of areas across a number of teams. We have to rewrite a bunch of IL so that dlls are backwards compatible and we have a bunch of extra build lanes setup for the specific purpose of testing VS 2017 support. This is also stopping us from adopting C# 8.0

Renaming MDP will probably just be done through inheritance magic and hiding the base type. The MDP concept is going to change across all of Microsoft. Also, the MDP in XF is fundamentally not an MDP it's a page with a Flyout.

Moving expander, MediaElement, markup, and DataPages out of forms gives us a lot more time to focus on CollectionView, Editor, and fundamental aspects of Forms

[mattleibow]

If the MDP is just going to be an inheritance tweak, then I think moving all the experimental feature out into the toolkit is a good idea.

Not only is this a good idea for the ones here now, but also allows the actual control to be iterated faster in the toolkit. Instead of having to wait for forms to release, the toolkit can release when a feature is going well. Also, this will reduce churn and change in parts that are new. We could have had a v1 of media element already if it wasn't in the main repo. In addition to this, once the media element is stable, the merge into forms will be simple and we know it is good to go from day one.

And, if we start moving the old things out now, then we can also keep the forms codebase cleaner. If there is minimal/no usage of data pages, then it probably wouldn't have reached the main repo at all if it wasn't a feature people wanted.

Finally, the VS2017 support is great and all, but that IDE is getting old and the general fixes have been low and no real updates to support the new things of the frameworks. Just looking at .NET Core 3.1, that is not even supported in VS2017. If we want to have better support for new things, then we have to drop off the older IDEs. VS2019 can still build for the same old devices and platforms. Using newer IDEs encourage better/modern code in the framework. And, we can better add things like nullable for all the consumers.

[acuntex]

@PureWeen Thanks for this explanation.

Your work bears a lot of responsibility. Individuals and companies and their whole existance rely on a working library. It's like .NET.

I know changes and fixes don't come overnight. But we're at the point of discussing on a sunday with the team whether we should drop 6 months of work and start over with react-native because we don't see the commitment of Microsoft. And it breaks my heart because Xamarin is doing so much things the right way compared to other cross platform libraries. (imho)

It's extremely risky to release an App where bugs in basic controls occur, where you can't even workaround the issues and no fix occurs in the library itself. What do you tell the customer/user?

Third party community libraries are sometimes abandoned for years, as @alexrainman stated. The community is dying.

Can we, the developers, get at least one official commitment by Microsoft that

1. Basic controls in Xamarin will be fixed with the highest priority so that they work as currently documented/intended.
2. No more internal classes, more exchangeability and all methods in some classes like Renderers protected virtual so we can override them, either because of a non existing feature or so we can react to issues and don't have to wait for official fixes. (Not just if it's needed by Xamarin.Forms.Material)

The latter would btw. also make it possible for developers to give you code snippets of fixes way faster, without knowing all the inner workings of Xamarin. I can only speak for myself: Just the thought of cloning the xamarin.forms repository, make it compile, create an App thats using this code base, fix it, test the fix etc. it's probably so time consuming that I wouldn't do it. Not everyone is working at a company so big that you can take a few days to fix bugs in a external library. But fixing it as workaround in a derived Renderer and submitting the code snippet, even if it is just a small hint for the Xamarin team, would probably help everyone.

Thanks!