[Question] Xamarin.Forms end of life?

[Tommigun1980]

Hi.

I can't help but notice that there hasn't really been any commits to Xamarin.Forms for the last few months. I understand that .NET MAUI is being worked on but let's be honest, it won't release for a good while and once it releases it will take at least a year before existing applications can even think about migrating to it. So MAUI is at least two years away for us developers.

Will Xamarin.Forms be updated during these years, or should Xamarin.Forms be deemed end-of-life as of now?

https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap says Xamarin.Forms 5 will be supported until November 2022. Is this still the case, or has Xamarin.Forms been abandoned prematurely in favour of .NET MAUI? If so then a realistic scenario is that any live applications, or applications currently in development for Xamarin.Forms, will need to be rewritten with a completely different SDK as developers can't just close shop for a few years. These applications will almost certainly not return to MAUI.

If nothing else, could the existing pull requests be merged? There's a ton of fixes there that people have been waiting for for a long time. Just take a week off from developing MAUI to merge them, or please update the roadmap to reflect that development has fully shifted to MAUI, and that the 2 year support commitment no longer holds.

Thank you so much for informing us on the roadmap and Xamarin.Forms support commitment!

[giuseppenovielli]

13997

[Tommigun1980]

I am a bit disappointed in the fact that the 2-year support commitment doesn't seem to hold. It is not something that can just be glossed over as the support commitment is very much a deciding factor when selecting a technology. If developers are hung out to dry it is certain that they won't return for any other initiatives from Microsoft.

MAUI may be the future of Xamarin.Forms but it is very much a distant future for us developers. It will take years before the technology is mature enough to use, before all libraries we are dependent on have been ported (if ever), and it just doesn't make sense for a lot of us to completely revamp our applications. We don't pick a technology because it's cool, what we need is longevity, so we can keep on pursuing whatever our business goals are.

This is the reason that the support commitment must hold and it is unprecedented for a large corporation not to uphold it. I beg you guys to keep on supporting Xamarin.Forms as it will kill a lot of businesses if you don't.

Thank you again, and eagerly awaiting an update on this.

[davidaramantSEP]

I have to agree; I am very unhappy with the support situation. My team is stuck on Forms 4.8 because of multiple crashing issues with XF5 that we cannot work around. It's not like the version we are on is a panacea either; CollectionView in particular is a mess (a control which we used because Microsoft said it was The New Way). I am really scared we are going to run into something where we need something from a later package version because we would be totally hosed.

[davidortinau]

Will Xamarin.Forms be updated during these years, or should Xamarin.Forms be deemed end-of-life as of now?

Xamarin.Forms will receive critical updates through November 2022, a year after its successor .NET MAUI releases.

https://dotnet.microsoft.com/platform/support/policy/xamarin

If nothing else, could the existing pull requests be merged?

Which PRs are a priority for you? I'll discuss with the team and see what we can do to get another service release out soon.

It will take years before the technology is mature enough to use, before all libraries we are dependent on have been ported (if ever),

.NET MAUI is Xamarin.Forms vNext in this context. What time frame for transitioning would be comfortable for you? What would you expect to happen in Xamarin.Forms when iOS 15, 16, 17 ships?

[developer9969]

@davidortinau hi David is good that you reply ,XF at the moment is very unstable especially the collection view!!! We updated to xf5 but we had no end problems with the collection view with resizing,grouping etc... in quite few places we had to replace it with bindable layout. Every upgrade is a worry of what might be broken... you need a bigger team Microsoft has to invest more in mobile.please sort the collection view as after the grid is the most important control.

[Tommigun1980]

Thank you for the answer @davidortinau.

Which PRs are a priority for you? I'll discuss with the team and see what we can do to get another service release out soon.

If I compile a list, will it actually be worth my time, and where do you want the list to be sent? I don't want to clutter this ticket.

On a high level there's a lot of pull requests that haven't been merged that fix bugs with the SwipeView and fix memory leaks. The CollectionView requires a lot of fixes for which there are no pull requests yet. The component is not usable and we can not live two years without fixes to it.

.NET MAUI is Xamarin.Forms vNext in this context. What time frame for transitioning would be comfortable for you?

It will take over half a year before it's released, and then at least a year or two before it's stable enough to use in production. Libraries will also take a year or two before they are updated, so I don't think it's possible to transition to it at least for two years, one year at an absolute minimum.

What would you expect to happen in Xamarin.Forms when iOS 15, 16, 17 ships?

I would absolutely expect Xamarin.Forms be updated to support whatever OS releases are shipped during its support period. So until November 2022 Xamarin.Forms has to support any new iOS and Android versions. This is how any technology I have ever used has been supported, as supporting the most recent operating systems is the epitome or "critical fixes". If the developers can't release their app on the various app stores then the underlying technology is not supported.

Thank you.

[davidaramantSEP]

I too would expect that Xamarin Forms works with iOS 15. Obviously I would not expect any brand new cross-platform APIs, but Xamarin.iOS and Xamarin.Android better support new versions.

By saying that Xamarin Forms 5 was the last major release with no new significant functionality, you've set the expectation that this is supposed to be a really solid release. That has certainly not been my impression of XF5.

I really hope Maui will be a straight-forward upgrade but I'm not counting on that. The reality is that the upgrade will take money & time. Even if it's a perfect framework from day one, some companies will have to defer the upgrade for budgetary reasons.

[Depechie]

@davidortinau in ref to what PR's we are waiting for: https://github.com/xamarin/Xamarin.Forms/pull/13166 ( been ready for review since January )

( sorry @Tommigun1980 for cluttering the ticket... just wanted to state we are indeed waiting for some PR's )

[BlueRaja]

I mean, there's two hundred open PRs, most of which are from the past year but have not even been reviewed yet.

So a good start would be to have someone go through those and merge/close/request changes. There must be a ton of low-hanging fruit there.

[inimirpaz]

Not to mention the 28+ days worth of "unverified" issues opened lately. What kind of support can we expect for XF 5 till Nov 2022? Major crash issues only or minor (eg layout/rendering issues) as well?

[davidortinau]

@Tommigun1980 you can email me david.ortinau@microsoft.com. I will review them with the team and prioritize those that meet the bar for a service release (regressions, critical blockers, high impact, etc.).

Xamarin.Android, Xamarin.iOS, and Xamarin.Forms will bump to new versions of Android and iOS until vNext is released, which in this case is .NET 6 in November 2021. From that point, new OS bumps will be via .NET 6+. This is a continuation of the same policy we've had for years: https://dotnet.microsoft.com/platform/support/policy/xamarin

@inimirpaz critical issues is the bar for what we are addressing right now.

Issues below that bar will be prioritized for fixing in .NET MAUI.

Any PRs open that don't make it into Xamarin.Forms will be asked to move and retarget to .NET MAUI.

We are all in an important transition to being a unified part of .NET that will pay off in the near future. Please continue to raise specific issues to me and I'll do my best to prioritize them and guide resolution while we have a narrow focus on what we do in the Xamarin.Forms repository right now.

[davidaramantSEP]

What defines "critical? "

[developer9969]

There are 269 open Collection View issues and some of them are critical to us, Grouping- Resizing- Spacing- Empty view you would agree that the collection view is an extremely important component and I am sure many people would appreciate if you could go through those and fix some critical ones,

Also @Tommigun1980 did raise quite a few collectionView issues at the time , and that allowed us to avoid the control Shall we revert to ListView?

[AlleSchonWeg]

If the Xamarin/Maui Team fixes issues here, these issues will not appear in maui. So win win.

[AlleSchonWeg]

When can we expect a new Service Release? I see only team members putting/removing labels on issues...

[MagicAndre1981]

What defines "critical? "

this is the point. According to 80/20 rule, 80% of devs use only 20% of the XF framework, so all have different critical issues which hurt them. Microsoft doesn't use XF for their inbox Windows and cross platform apps like outlook, mobile office, so they don't know what developers need.

[Huaba93]

@MagicAndre1981 I agree with you 100%. Microsoft needs to use Xamarin/MAUI for their own products. That's what Google is doing with Flutter. That's the only way to build a great Framework.

[MagicAndre1981]

@MagicAndre1981 I agree with you 100%. Microsoft needs to use Xamarin/MAUI for their own products.

yes, this is the point. Here Microsoft would detect the same issues like we during coding and would fix them much faster

[davidaramantSEP]

When can we expect a new Service Release? I see only team members putting/removing labels on issues...

I think this is the most pressing question. Saying that XF5 is supported until November 2022 doesn't mean much if there's never any new service releases. Right now it appears to be completely abandoned.

[jsuarezruiz]

We are reviewing and merging PRs preparing the next Service Release. Will share detailed info (date, etc) as soon as possible.

[AndreasReitberger]

We are reviewing and merging PRs preparing the next Service Release. Will share detailed info (date, etc) as soon as possible.

Hi @jsuarezruiz @PureWeen @davidortinau, thanks for continuing working on Xamarin.Forms. I know it's a lot of work, however can you estimate a date when the SR4 is ready? According to the project here (https://github.com/xamarin/Xamarin.Forms/projects/86) it's about 43 issues still to be fixed. As I can see, @PureWeen already fixed the AndroidX dependency and iOS TitleView issue. Those issues are vital to be fixed. Maybe you can consider to split the project and release SR4 sooner, which is fixing the vital issues, and put the rest into SR5?

Thanks for your great work and contribution!

[KazysNoobiys]

It is very sad to see the current state of the XF. Our team switched to XF 5 and encountered performance issues with CollectionView. At this point, CollectionView is absolutely not ready for real-world use. This has forced us to go back to ListView. But the bad news didn't end there! When switching to ListView, we ran into regression. In some scenarios, in debug mode, ListView absolutely nightmarishly slowed down. The corresponding issue is already open. https://github.com/xamarin/Xamarin.Forms/issues/14218 .

[Tommigun1980]

Pinging about this again. Microsoft has promised to support Xamarin.Forms but unfortunately I am not seeing it at the moment.

There’s a lot of developers in a really bad position right now.

Please open a dialogue with us.

[MagicAndre1981]

they released a broken SR4 , I don't expect any new SR

[AlleSchonWeg]

For many issues there are existing PR's, but nobody reviewing these PR's. Perhaps MS should give repository control to some community members.

[developer9969]

Sadly I dont think there will be any new SR in fact SR5 does not exists.. Sadly people are logging issues but clearly there are not going to get fixed in xamarin forms at all . They are busy with MAUI. We are in a really bad place at the minute...

Let alone those PR's, What a nightmare at the moment.

[Huaba93]

it is so frustrating... how can we develop trust for MAUI? Companies with hundreds of employees rely on Xamarin.Forms, but this kind of support can ruin companies. I think for my company we need to get rid of Xamarin.Forms. The last 12 months have been a disaster.

[thisisthekap]

TL;DR: I am looking forward to MAUI, but please give some love to Xamarin.Forms, and give us a working SR 5 which solves the regressions introduced in SR 4.

Long story:

I appreciate the effort which is taken to make sure that MAUI is going to be the awesome product we all are looking for.

But please: Give some love to Xamarin.Forms! This framework which is considered to be production ready is suffering from severe issues with a high number of PRs which do not get any attention. Furthermore, the current service release consists of regressions, which makes it unusable to many companies out there.

I understand that there won't be new features for Xamarin.Forms, and that issues with working workarounds do not receive priority.

But please give us a SR5 which consists of many fixes which are already lying around in the code base, and which fixes the regressions introduced in SR4.

[Tommigun1980]

@davidortinau You did reiterate that the support commitment for Xamarin.Forms holds, so please communicate with us regarding what is going on?

I think that most of us are not hobbyists but actual employees and owners of actual companies. We have to be able to trust the support commitments. And to us any future releases and whatever else that’s possibly fun to work on doesn’t really matter, we need the tools to function properly and being able to trust the support commitment. Support commitment isn’t just a phrase on paper but an actual commitment to ensuring that the technology works. You also have to understand that you are losing customers at a rapid rate here. We developers really don’t care or have much insight into your internal deadlines at Microsoft and whatever new features you have promised marketing to whatever new release — we should be shielded from that, and you should have a roadmap that ensures that we can work normally while you work on whatever you do in the background.

Thank you.

[davidortinau]

But please give us a SR5 which consists of many fixes which are already lying around in the code base, and which fixes the regressions introduced in SR4.

Please link me to the issues that are blocking you, and PRs you need. We are behind on triage and working to catch up. At present queries don't show me regressions with SR4.

We developers really don’t care or have much insight into your internal deadlines at Microsoft and whatever new features you have promised marketing to whatever new release

We don't have such deadlines or promises. Our features are driven by your feedback and research, weighed by the typical constraints we all work with. Our roadmap is public. Our marketing event dates are public as soon as plans are solid. Our shipping schedule is predictable, though we don't post dates for every single release.

We are making every effort to be transparent so you can make solid plans for your projects and businesses. We will continue to service Xamarin.Forms as we have committed.

[MagicAndre1981]

Please link me to the issues that are blocking you, and PRs you need. We are behind on triage and working to catch up. At present queries don't show me regressions with SR4.

this is a regression, but looks like UWP is ignored at all if future is WinUI

[Huaba93]

This is also regression and blocking for us

[Tommigun1980]

But please give us a SR5 which consists of many fixes which are already lying around in the code base, and which fixes the regressions introduced in SR4.

Please link me to the issues that are blocking you, and PRs you need. We are behind on triage and working to catch up. At present queries don't show me regressions with SR4.

We developers really don’t care or have much insight into your internal deadlines at Microsoft and whatever new features you have promised marketing to whatever new release

We don't have such deadlines or promises. Our features are driven by your feedback and research, weighed by the typical constraints we all work with. Our roadmap is public. Our marketing event dates are public as soon as plans are solid. Our shipping schedule is predictable, though we don't post dates for every single release.

We are making every effort to be transparent so you can make solid plans for your projects and businesses. We will continue to service Xamarin.Forms as we have committed.

You were asking for regressions. I have mailed the team several times pleading for a fix to the https://github.com/xamarin/Xamarin.Forms/issues/14429 regression which completely blocks demonstrating my app. SR4 broke NuGet packages for a lot of people (https://github.com/xamarin/Xamarin.Forms/issues/14425, https://github.com/xamarin/Xamarin.Forms/issues/14417 etc. etc.) but there's a workaround for that.

I also sent a list of must-have fixes months ago when you were asking for must-have fixes, and you are a CC on those. I'll reiterate again: The CollectionView is not usable right now as it has problems with scrolling, selecting items, virtualisation and auto scrolling. I linked to the reports for these, and I have provided repro projects for every issue. There's no correspondence in the bug reports or any movement after mailing about them as you asked me to do (other than some we'll look into it). In addition to that I provided a long list of must-have fixes mostly to the SwipeView, most of which already have fixes in the form of pull requests but have not been approved yet. They have just been sitting there for months.

Thank you.

[Tommigun1980]

This process isn't really working. You said MAUI is based on customer feedback and that you don't really have external pressure from marketing etc, so who exactly asked for such a clean break that the current version is essentially abandoned? The thing I see people complaining about, to the degree of dropping Xamarin.Forms, is its bugs, not lack of features. If despite this, what people really complain about, your roadmap is based on a clean break and not fixing issues for a long time I honestly don't think you have a good pulse on what is going on in the community. Just search for CollectionView in the issues section and you'll find 465 issues, and that's just one control!

And I concur with the posts in this thread saying that Microsoft has to start using Xamarin internally. Nobody can develop technology in a vacuum which is clearly happening here. Issues are not found and the pain is not evident in test apps with just one button. The question also arises that if Microsoft teams internally don't trust Xamarin, how can you convince developers to jump on board?

Bugs happen when a lot of things are going on and are often not reproducible in a very monolithic repro project, so actually using your own tools would go a long way. But then again, I have made tens of repro projects for issues that are completely breaking my app and they have been sitting there for months (especially with the CollectionView, please refer to the email I sent a long time ago when you were soliciting for must-have fixes) without any action on them, so I don't know if it would help in the end. I don't really know what would help at this stage other than the team taking half a year off from developing new features and just fixing bugs. There has to be some will behind it even if it may not be that exciting to work on.

[developer9969]

@Tommigun1980 Thank you for producing and submitting so many repos that highlights all the issues we have encountered. @davidortinau we have done all the workarounds in the world to make sure that we can have something that we can deploy but the collectionview took it to another level..
Below is just a sample of the issues we face with collection view,

• Does not resize properly
• Scrolling issues
• Empty view not working as it should
• Grouping issues

All things that you are aware of, even one of your team lead referred as the collection view as Frustrating in one of the chats...

SR4 was not at all the kind of release we were expecting as it didnt contain any of the relevant fixes.

You know the collection view has issues can you prioritize and start cleaning the issues in the that section?

https://github.com/xamarin/Xamarin.Forms/issues/14429 https://github.com/xamarin/Xamarin.Forms/issues/14239 https://github.com/xamarin/Xamarin.Forms/issues/14224 https://github.com/xamarin/Xamarin.Forms/issues/14213

There is a lot of frustration here as many of us put the neck on the line to go for Xamarin instead of flutter etc.. and MAUI will be great but in the meantime we are stuck with a below par product. Sorry for the harsh words but its a reality

Microsoft will never use Xamarin for their own product -- hopefully MAUI will change things....

Can you give us a SR5 with fixes that matters?

Many thanks

[Tommigun1980]

Thank you. If we go down to detail level for posterity here's my must-have fixes:

CollectionView: https://github.com/xamarin/Xamarin.Forms/issues/14429 - Regression where CollectionView starts randomly jittering around (this essentially breaks the entire app) https://github.com/xamarin/Xamarin.Forms/issues/13592 - CollectionView initial selection is broken (ie you can't highlight items in a CollectionView) https://github.com/xamarin/Xamarin.Forms/issues/13547 - CollectionView can't be scrolled to bottom when data is loaded (so can't really make a chat application etc. with it)

SwipeView: https://github.com/xamarin/Xamarin.Forms/issues/12518 - SwipeView is so sensitive it opens while scrolling (makes it hard to scroll a CollectionView as SwipeViews constantly accidentally open on drag gestures)

SwipeView and other misc. fixes with pull requests I've been waiting for (not all of which are essential)... All of these have had pull requests open for ages but they just haven't been merged in: https://github.com/xamarin/Xamarin.Forms/issues/13496 https://github.com/xamarin/Xamarin.Forms/issues/13495 https://github.com/xamarin/Xamarin.Forms/issues/13232 https://github.com/xamarin/Xamarin.Forms/issues/13491 https://github.com/xamarin/Xamarin.Forms/issues/12614 https://github.com/xamarin/Xamarin.Forms/issues/11795 https://github.com/xamarin/Xamarin.Forms/issues/11720 (Shouldn't this be considered low-hanging fruit as the fixes are already done? Why not merge them in?)

Nice-to-have fixes: https://github.com/xamarin/Xamarin.Forms/issues/12590 - LineBreakMode="TailTruncation" doesn't work with Label.FormattedText https://github.com/xamarin/Xamarin.Forms/issues/12704 - Editor with AutoSize="TextChanges" - text overflows control without it scrolling, forcing one to type blind

---

This is just scratching the surface, but just fixing those and merging the pull requests would go a long way in making my app work properly. This is core functionality mind you, like being able to scroll and select items in a CollectionView! It is almost impossible to make apps with these kinds of bugs, so it scares me that all focus is on the shiny new thing with these kinds of issues open (not to mention the 3.2K other open issues).

I also apologise for being so blunt about this, but some change has to happen soon and we are reliant on Xamarin.Forms working.

But I am also not kidding when I say that nowadays 80% of my time goes to workarounds and making bug repro projects for Xamarin.Forms bugs, and 20% goes to actual development when working on the client side. My app is fairly mature so it is all about workarounds now. This is untenable.

Thank you again!

[AndyDentFree]

@davidortinau wrote back in April

.NET MAUI is Xamarin.Forms vNext in this context. What time frame for transitioning would be comfortable for you? What would you expect to happen in Xamarin.Forms when iOS 15, 16, 17 ships?

Seriously?

1. A five year commitment to maintenance
2. A team status page so we can see how many engineers you have assigned
3. A core set of good samples showing a range of dev styles, not just Shell, that is actively maintained so it always works with new releases of Forms
4. Preferred - blog posts about significant internal tools used in MS either in Forms or Maui so we know people who decide how big engineering teams should be are dogfooding this. If they dont' feel pain, it won't be a priority for them. I don't think it reasonable to expect these all to start in Forms but it would be very reassuring to hear of at least one tool in regular management use that is in Forms and then to hear of its migration to Maui.

I'm a developer with 40 years experience, much of which is the MS ecosystem. So, yeah, I've seen every single generation of next best thing come and go.

I was a developer for nearly two years on the Realm C# SDK (now part of MongoDB) so I saw Forms support from the library vendor perspective. I've worked in enterprises shipping to tens of thousands of end users on Windows. I have a good idea of technology migration horizons.

I have a legacy project in forms which I'm diving back into and a new family side-project. In my main startup, I have to pick a tech within months for a cross-platform app.

Right now I'm very seriously contemplating using Flutter for the family project, so I can decide if I will recommend it unilaterally as a replacement for Forms/Maui for mobile development.

Note my emphasis on reassuring in this response. In some degree of shock from this thread, I'm not feeling anything like that. I deeply respect much of the work done at MS and that it's not decisions made at your level that affect the resources.

The responses in this thread should show that people have lost trust and that loss of trust extends to not trusting much in the Maui migration either.

[DeerSteak]

At a minimum getting these fixes as mentioned by @Tommigun1980 and supporting the current shipping versions of the AndroidX libraries should happen. As it stands, it appears Xamarin.Forms 5 is abandonware and there's no replacement. It's extremely frustrating to have the latest fixes and then get compiler warnings like these:

Warning NU1608 Detected package version outside of dependency constraint: Xamarin.Forms 5.0.0.2083 requires Xamarin.AndroidX.Lifecycle.LiveData (>= 2.2.0.4 && < 2.3.0) but version Xamarin.AndroidX.Lifecycle.LiveData 2.3.1.1 was resolved.

Warning NU1608 Detected package version outside of dependency constraint: Xamarin.Forms 5.0.0.2083 requires Xamarin.AndroidX.RecyclerView (>= 1.1.0.8 && < 1.2.0) but version Xamarin.AndroidX.RecyclerView 1.2.1.1 was resolved.

Warning NU1608 Detected package version outside of dependency constraint: Xamarin.Forms 5.0.0.2083 requires Xamarin.AndroidX.Core (>= 1.3.2.3 && < 1.4.0) but version Xamarin.AndroidX.Core 1.6.0.1 was resolved.

And then on top of it to have bugs like Shell on Android disposing custom renderers with no workaround is extremely frustrating.

https://github.com/xamarin/Xamarin.Forms/issues/9073

That's been around for almost two years.

https://github.com/xamarin/Xamarin.Forms/issues/14328

Another that's just a deal-breaker. We had to parse the HTML ourselves using an effect and wrote a native renderer on both Android and iOS for an ExtendedLabel control. This should have been very simple, but the need for a workaround makes it darn near impossible.

You make all these new technologies like HTML labels, CollectionViews, and Shell and beg us to use them, and then don't support them if they don't in anything but a simple example app. As @AndyDentFree says, that kills trust in the Maui migration.

[AlleSchonWeg]

@davidortinau As a good starting point you should merge the existing PR with many fixes.

[wowpravin]

@davidortinau imho asking your customers 'now' what PRs are critical is not a good state of affairs. Honestly if Microsoft was using XF internally then you would already know what to fix!

[Tommigun1980]

I also think that you need integration tests; preferably some kind of complex test app that touches upon most areas used in an actual app, which you also always run manually before committing changes as a smoke check. Having a billion unit tests is nice but they are not reflective of real world usage at all. A button almost always works in isolation, but combine that with other components and things start breaking down. There is no way you could create so many unit tests that they could catch all possible real-world usage scenarios, without any manual testing/smoke checking and integration testing. Also, when new features are released the developers have to test them in the toughest possible setting, on ALL supported platforms. TRY to break it! Don't settle for a test app which houses only that one new fancy control. So yeah, very often the components work pretty well in isolation but not when used in an actual app.

But then there's components like the CollectionView where unfortunately even core concepts like selection and 'scroll to bottom' don’t work. I think you have to start catching those kinds of issues before releasing them to start gaining trust back. I honestly have a hard time figuring how for example the CollectionView was tested... When features were added to it (like selection capability and firing of events for various actions), was the code that was written thoroughly tested manually? I don't mean artificial tests, but some kind of test app that houses the component in question, where every new feature is tested while being developed? So many of its core features are broken in the simplest possible repro case, that I would like to be assured that the quality will increase.

Once again, apologies for the bluntness, but we need major changes to the process in order to continue investing in Xamarin.Forms/MAUI. Thank you.

[timahrentlov]

Why aren't MS dogfooding like Google is with Flutter?

And think of all the "We want your feedback and input" avoidance speak we could get rid of :)

Really. Start using your own product. And if no internal teams want too, ask them why!

[Huaba93]

It has often been said that MAUI becomes Xamarin.Forms Next, so the wheel is not being reinvented. Some things are made new (e.g. renderer-->handler) but many things are simply taken over. Or have I understood this wrong?

This also means that many problems known in Xamarin.Forms we will find in MAUI as well!

@davidortinau What has changed that it should become so much better with MAUI?

[lee-m]

@davidortinau On the topic of regressions, #14479 is a regression from SR4 with an open PR to fix it. There's been several duplicates reported of the same underlying bug and it took me a while to narrow down why my app suddenly started crashing.

I've also just been hit by #14544 where the RadioButton (new in XF5) control on iOS is unusable if it's initially disabled and later re-enabled.

[jfversluis]

Hey everyone! A lot has been said here already, I am not here with all the answers overnight. But I can say that I will be looking at the issues that are mentioned in here (to begin with) to see if we can get that in for the next service release or ones after that. I hope you're willing to work with me to set us on a path forward. I have added all of the mentioned issues on the service release 5 project board so that should give you some indication of the status. To temper expectations: of course, I and we would love to fix every one of those issues for the next release, and we're doing everything we can but I can't make any solid promises or guarantees apart from that I will be working this list and do my best. They're on this board now and on our radar, but we still need to go through them to see what we can do with each one of them.

I will start with the quick-wins, the issues that already have open PRs. For each PR CI build I have now configured that a NuGet will be pushed to a private feed. From there, you can install the package with the change of that PR and see if that fixes the issue that you are after.

At the time of writing, these PRs are already on there: #14527 (not on this list/issue), #13385, #13003, #11812, #13503, #13166

The NuGet feed URL and some more details can be found here: https://github.com/xamarin/Xamarin.Forms/wiki/Preview-Packages

If you decide to try any of these fixes, please leave a comment on the issue itself so we can hopefully keep things organized. Especially let me know when if works so we can move it forward and hopefully add it to the upcoming release!

Also, if you have more info about any issue, maybe even an exact point in code or even a fix(!) please let me know as well. Additional information on reproductions or actual reproductions can also help tremendously to fix it or at least estimate how much effort it might be.

I'd love to work together with you to resolve these issues ASAP and unblock your development. Thanks!

[AlleSchonWeg]

@jfversluis It looks like you are back in the team. ;) So my wish is this PR: https://github.com/xamarin/Xamarin.Forms/pull/8231

[jfversluis]

@jfversluis It looks like you are back in the team. ;) So my wish is this PR: #8231

I am! 🎉

I foresee a lot of people with wishes, about 3000 of them 😄 Again, I'd love to fix them all and make everyone happy, realistically we know that's not possible. More issues can be added, for now I will focus on everything that is mentioned above my comment which is already a good list, we'll see from there 🙂

[giuseppenovielli]

@jfversluis i thinks that this issue is very important:

Issue- > https://github.com/xamarin/Xamarin.Forms/issues/8282 PullRequest -> https://github.com/xamarin/Xamarin.Forms/pull/13773

Thanks you so much!

[jfversluis]

I don't understand @giuseppenovielli these seem already merged? If so, they will be in the next release so that was an easy one 😉

[giuseppenovielli]

@jfversluis exactly! 😉