Maui: About the 1675 open bugs in Xamarin.Forms

[Happypig375]

Please read this comment from @davidortinau

https://github.com/dotnet/maui/issues/109#issuecomment-635078640

Reading through here I'm wondering what I can learn here to improve the quality of Xamarin.Forms. I would love to return to @Happypig375's original question:

Any thoughts on how to improve?

One of our main goals between now and shipping .NET MAUI is improving the foundation, starting point. For this reason we are spending much of our current sprints on CollectionView issues, and we are proposing to pause feature developer in Xamarin.Forms 5 so we have from Sept 2020 to Nov 2021 to shift more focus to issue resolution.

This is all visible on our sprint project boards.

Original Description

Xamarin.Forms is known to be buggy. It currently has 1675 open bugs, which is on track to surpass mono's 1676 open issues. By comparing the numbers, it is easy to see that Xamarin.Forms is buggier than the "historically buggy" mono framework.

Now that MAUI's source code was copied from Xamarin.Forms, it means that MAUI starts out to be equally as buggy as Xamarin.Forms. Everyone seem to focus on making the MAUI architecture as bug-free as possible by following Flutter, but the fact that Xamarin.Forms bugs are fixed very slowly, even for bugs with high impact seems to be ignored. e.g.

• https://github.com/xamarin/Xamarin.Forms/issues/7049 took over 1 month to roll out even when the PR is merged 7 days after bug report
• https://github.com/xamarin/Xamarin.Forms/pull/7711 was marked "i/high" but took over 2 months to merge
• https://github.com/xamarin/Xamarin.Forms/issues/8262 received 13 likes but took over 2 months to fix
• And most of the highest-voted bugs are 1 to 2 years old already

And opening a pull request can still result in the request being stuck in limbo until an official from Xamarin spares the time to take a look at the files changed.

As time progresses, people will start to depend on the bug, resulting in the bugfix being perceived as introducing a new bug.

Xamarin.Forms was buggy in 2015, Xamarin.Forms was buggy in 2018 and Xamarin.Forms will still be buggy in 2021 when MAUI is released if bugs are fixed this slowly.

This is simply unacceptable for those working with a tight deadline and time need to be wasted on finding workarounds and applying them.

With MAUI, we should have a bugfixing process that is as fast as possible. Any thoughts on how to improve?

[dylanberry]

7049 took over 1 month to roll out even when the PR is merged 7 days after bug report

And opening a pull request can still result in the request being stuck in limbo until an official from Xamarin spares the time to take a look at the files changed.

Hopefully the team has a plan to remove some of the bottlenecks around the PR + release process.

[Happypig375]

And opening a pull request can still result in the request being stuck in limbo until an official from Xamarin spares the time to take a look at the files changed.

And look at that, after being mentioned in a high-visibility issue, someone on the Xamarin.Forms team finally responded to https://github.com/xamarin/Xamarin.Forms/pull/7728.

[dylanberry]

And opening a pull request can still result in the request being stuck in limbo until an official from Xamarin spares the time to take a look at the files changed.

And look at that, after being mentioned in a high-visibility issue, someone on the Xamarin.Forms team finally responded to xamarin/Xamarin.Forms#7728.

I empathize with the team. That many issues are not easy to triage/manage/fix. That being said, there definitely needs to be a focus on removing bottlenecks and wittling down the open issues and PRs.

[Reveon]

Agreed, quality has always been a problem for every aspect of Xamarin development. Many times I find myself frustrated because of incompatibilities between the components, not working build in VS or my app crashing after an update to the new version of Forms. Stuff should just work. I should not be forced to rebuild my layout for the 3rd time because some controls or layouts simply do not work well together.

I see a couple of related points

1) I don't know how many people work on Forms but to me it looks like the team is too small to keep up with the fast growing pace of new bugs or PRs. This is only going to get worse as they will have to split attention between Forms and Maui. I really hope that the team gets substantial boost soon.

2) It would really help if Microsoft started to actually use Forms on their own apps. And I don't mean simple demo or conference apps. I mean real apps like Teams or Outlook. I would be glad if I am wrong on this one but I did not manage to find any MS Forms app on the stores and according to some source like this tweet https://twitter.com/safaiyeh/status/1219294459298344961 they use mostly react native.

• this really does not send a good signal because if MS does not use their own technology (XF) then why should we?

• using Forms internally on complex apps could be and extra layer of testing and could reduce the number of issues that hit the public release. Plus they could see that working with Forms is not as easy as they are telling us

3) I see another problem in the fact that MS constatly tries to reinvent the wheel in a form of XF Xaml instead of using already proven and existing solutions like Win UI Xaml. They have to invest time in developing already existing features and in fixing bugs that are introduced because of that and then there is less time for other features and bugfixes.

[GiampaoloGabba]

I agree 100% with @Reveon
oh, and I have to say that using VisualStudio for Windows with Xamarin is a super-frustrating experience.

They keep to add outstanding, blocking, bugs... i dont even know how that is possible (things like breaking ALL the ios device builds, breaking provisioning profiles, breaking gesture recognizer... how can bugs like these go in production and then take weeks or months to be fixed in release build? dunno....)

I switched to Rider for that and now i'm using Jetbrains product everywhere :) At least i can use an IDE wich is exactly the same in iOS & Windows and continue to work productively.

I'm sure that with MAUI such things will change, and sooner or later Microsoft will start to use MAUI internally for serious projects

[Happypig375]

Another testimonial:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment-633730446
@EmilAlipiev:

i have been waiting for my PR to be merged 1.5 month for this issue. There is already existing issue for Ios and android was fixed in July 2019 and nobody touched for uwp. I fixed in april and requested several times for review and merge. It is really annoying how xamarin teams is working. You can see they review only 1-2 PRs per day.
#10316

[EmilAlipiev]

Although i am often frustrated, "Xamarin is buggy" is harsh statement. 2000+ open issues today, if you check flutter has 5000+ open issues. Numbers are not so important. Xamarin.forms offers more than other cross platforms like uwp (including xbox), wpf, mac, gtk, tizen. So there are many open issues for Wpf for example which is lower priority for the most of us.
Core of Xamarin.forms should be ios, android and uwp although Xamarin team often neglects uwp.

1. There should be core elements like layouts, listviews, carousel, collectionview, images, maps, label, editor etc. Those should be bug free. if you make a new release or update on those, you must ensure there is no showstopper bug. If there is a bug, you must resolve it within a week max. But Xamarin team is releasing that cool "4.5-4.6" with cool features (who needs this fancy tool 10% of the community?) and image contol is broken. Issue was reported at the beginning of march and still not resolved till today. Same "Bundle into native assemblies" is broken. For those crucial reasons i cannot upgrade to 4.5 and 4.6. They keep developing with 4.7 adding new features. I and most of us keep an eye on release notes whether our bugs are resolved, i dont even read anymore what feature was added.
2. Xamarin team has to understand this. Biggest reason many people choose Xamarin is "UWP". I am freelancer. I ask my customer why not flutter or react native? He says because Xamarin has UWP. I want UWP also. But Uwp is mostly buggy with Xamarin.forms. they introduced CollectionView, it is really great but since a year it has that bug not resolved. I fixed it, nobody is reviewing. I was discouraged doing any further contribution.
3. Hotreload is not working at all. I read on twitter all "kiss kiss" how great is hotreaload. I am thinking there should be something wrong with me or they use some other tool. Because often hotreload is not updating. I am still using 3rd party tools like livexaml etc. I even created a simple console application to do my own hotreload. it costs me 1 day. Works much better than Xamarin's and even works for uwp. How can they not deliver it? They had livereload was working.

4. Most important point; what @Reveon mentioned. they need a real enterprise application which works with xamarin.forms and they should update it with new releases to detect real issues. They complain that "it is not so hard to give repro". Yes it is very hard if this issue only occurs on your enterprise application, not on a todo app. You need to try to replicate same ui. it may costs your days till you figure out. Thats why it is very important that there should be someone having a large application. I am wondering really if any of those Xamarin devs we see on twitch, youtube, twitter etc have they ever developed a large application with xamarin.forms.

5. I have to admit something although i dont like to use non-open source tools, more than 50% of my apps are with syncfusion tools. Without Syncfusion, i think it is so hard to get an enterprise working application. They have everything what xamarin doesnt or what xamarin buggy is. For example, I looked for sfListView replacement for years having drag and drop, swipe view, linear and grid layout, better virtualization etc. Finally xamarin came out with CollectionView and they threw it on our face as "cool version" of Listview but then is it buggy. Not working for Uwp. many missing features. Just search for CollectionView within the issues, you will end up dozens of them.

I still believe in Xamarin is the best tool for cross platform and i hope that they will take this issue as a constructive feedback.

[bcaceiro]

Great and constructive comments so far. I was reading the list, and feeling the same as the other devs. The issues are common within those of us that use Xamarin.Forms to develop enterprise Apps. The bug tracking and fixing needs more attention, but specially, one point that is clear, and many times I have asked myself is why there is no enterprise MS applicatio built with Xamarin.Forms. MS Teams or any other. If the answer is: way to complicated or impossible to do with Xamarin.Forms, there is a great internal insight to improve the platform as a whole and try to fix those issues. Xamarin/MAUI will certainly gain with more developers testing, contributing and spreading the word, but this should be a two-way street. Again, I'm not complaining, but it would be huge to see, this year, next year, a great MS release of a Mobile Application built with MAUI or Xamarin. Also check the devs for their frustrations or possible improvements, and take cross platform development to a new level.

[neolithos]

Because, I was mentioned...

I lead a small project for a cross platform application between Android and Windows Desktop (WPF).

We found a lot of bugs, that we had to work a round or fix. Currently, I start a internal project for the fixes and performance improvments, because sharing our solutions is with this slow progress impossible. We have also dead lines.

Bringing bugs in the official pipeline is really expensive for our small team, so it would be nice to get more attention, may be you get more from the community.

In the wpf part of xamarin is a lot stuff to do. The performance is bad and it is hell of simple bugs. But the idea behind and the base is set. It is sad do see the current state, because it could be way better...

[SunnyMukherjee]

Agreed, quality has always been a problem for every aspect of Xamarin development. Many times I find myself frustrated because of incompatibilities between the components, not working build in VS or my app crashing after an update to the new version of Forms. Stuff should just work. I should not be forced to rebuild my layout for the 3rd time because some controls or layouts simply do not work well together.

I see a couple of related points

1. I don't know how many people work on Forms but to me it looks like the team is too small to keep up with the fast growing pace of new bugs or PRs. This is only going to get worse as they will have to split attention between Forms and Maui. I really hope that the team gets substantial boost soon.
2. It would really help if Microsoft started to actually use Forms on their own apps. And I don't mean simple demo or conference apps. I mean real apps like Teams or Outlook. I would be glad if I am wrong on this one but I did not manage to find any MS Forms app on the stores and according to some source like this tweet https://twitter.com/safaiyeh/status/1219294459298344961 they use mostly react native.

• this really does not send a good signal because if MS does not use their own technology (XF) then why should we?
• using Forms internally on complex apps could be and extra layer of testing and could reduce the number of issues that hit the public release. Plus they could see that working with Forms is not as easy as they are telling us

1. I see another problem in the fact that MS constatly tries to reinvent the wheel in a form of XF Xaml instead of using already proven and existing solutions like Win UI Xaml. They have to invest time in developing already existing features and in fixing bugs that are introduced because of that and then there is less time for other features and bugfixes.

I agree with many of the issues you mentioned. Microsoft definitely needs to make an enterprise app using Xamarin Forms or iOS or Android. Once they have a working enterprise app example, then we can't complain that making professional apps is frustrating.

Xamarin Forms is a great cross-platform framework for those who want to make an app once and work everywhere. It works great if you create simple apps. But once you start making a more professional app with more features like animations, segmented tabs, data virtualization, complex layouts, etc., you find yourself fighting the framework more and more to get a feature working. I find that simple things that should work either are not obvious or require hacks to make it work.

Features like Xamarin Hot Reload are still premature in their stage of development. For example, if I make a style change in the App.xaml or a resource dictionary referenced from App.xaml, which is where I store my styles and resources, Hot Reload will mess up the layout of the app in the simulator or cause the app to crash.

I find that Visual Studio is incredibly buggy when developing Xamarin apps. For example, if have my Android project selected as the startup project, test with it, and then switch to my iOS project as my startup project, it will show all kinds of false errors. Destroying the bin or obj folders does not help. It requires me to restart VS. In another example, VS will randomly lose its connection to my Mac while I am debugging my app. It will cause my VS to freeze. I will throw a temper tantrum, question my hobby and my life as a mobile developer, and force kill VS using Task Manager. Furthermore, I find that future versions of Visual Studio reintroduces bugs that were fixed in prior versions. I know of no way about how to install a prior version of VS after the latest version is released and I install it. I can uninstall it and try to reinstall using the installer, but it will always install the latest version. It's not like a NuGet package where you can install any version.

Lastly, why is a segmented tab control not part of the Xamarin toolkit already? Segmented tabs are used almost everywhere. I should not have to use the Syncfusion toolkit or another toolkit to use a control that is so common.

I am nervous to adopt using MAUI when it comes out in any professional app that I develop until many of these developer frustrations using Xamarin and Visual Studio are resolved. I will play and experiment with it when it comes out. But I will get more confidence if Microsoft comes out and makes an enterprise app using MAUI instead of making simple demo apps.

Can someone enlighten us about the Xamarin Forms and MAUI roadmaps? Will they be maintained in parallel? Is there a hard stop for Xamarin Forms support and will Microsoft shove MAUI down our throats in a future Visual Studio update?

Thank you

[Happypig375]

@SunnyMukherjee From the FAQ,

What is the future of Xamarin.Forms?

The next major version of Xamarin.Forms will around September 2020 and continue to be updated through the release of .NET MAUI with .NET 6. After that, Xamarin.Forms will continue to receive priority servicing for 12 months.

Basically, Xamarin.Forms will be killed after version 5.

[SunnyMukherjee]

@SunnyMukherjee From the FAQ,

What is the future of Xamarin.Forms?

The next major version of Xamarin.Forms will around September 2020 and continue to be updated through the release of .NET MAUI with .NET 6. After that, Xamarin.Forms will continue to receive priority servicing for 12 months.

Basically, Xamarin.Forms will be killed after version 5.

By Mid-2021 . . . if Covid doesn't kill me before then, either Maui or Xamarin Forms will do the job.

[mrwcjoughin]

@SunnyMukherjee I hear your pain. I have been using Xamarin.Forms since it first came out, and it has come along way since there. Remember that Microsoft did not create Xamarin.Forms, they only bought Xamarin in 2018. So MAUI is Microsoft's project to rewrite it to be better and make it work seamlessly with the entire .net. Working with Xamarin.Forms is not trivial because what it has to do is not trivial. A lot of people are saying they should just do what Uno or Flutter has done and make the controls themselves completely - but that is against what Xamarin.Forms is. It's a native development framework - exposing the native controls in a common way. This is no small task. I have also had lots of issues with Xamarin.Forms, but on the whole the time saved by using it instead of writing the same app in multiple languages far outweigh the troubles. Plus being able to share 90% of the code with the backend ASP.Net core projects makes it even more worthwhile.
While it's important to let Microsoft know what we want in MAUI - but we have to understand that it is no small task for them, and I have hope that MAUI will be a massive step in the right direction.
Watch this video from the recent build that demo's MAUI and explains how it fits into the roadmaps and also what they will do and support on Xamarin.Forms in the meantime:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

[davidortinau]

Reading through here I'm wondering what I can learn here to improve the quality of Xamarin.Forms. I would love to return to @Happypig375's original question:

Any thoughts on how to improve?

One of our main goals between now and shipping .NET MAUI is improving the foundation, starting point. For this reason we are spending much of our current sprints on CollectionView issues, and we are proposing to pause feature developer in Xamarin.Forms 5 so we have from Sept 2020 to Nov 2021 to shift more focus to issue resolution.

This is all visible on our sprint project boards.

[neolithos]

In short:

• Be more quicker on community pull request.

I rebased the pull request tree days ago. Why is the review taking so long?

[neolithos]

WPF-Renderer, points of potenial bugs:

• Measure/Arrange of the controls
• Logical/Visual-Childtree is broken
• Performance

[ncarandini]

Hi @davidortinau, I think a good way of tackling this is publicly devoting someone to be full involved in:

• bug issue triage
• manage, dispatch and push for PR review and merge.

He/she we'll be our point of contact if something goes too slow and he/she can explain what's going on.
Moreover, if there are non legal impediments, it will be fantastic if we can have a Twitch channel where in turn someone fix a bug or review a PR online. IHMO, this could have a tremendous impact on external developers interest and collaboration.
This is both valid for .NET MAUI and Xamarin Forms. But maybe I'm just a dreamer 😄

[MilKAOS]

I am not really surprised that Xamarin.Forms has a lot of bugs considering the number of platforms it is running on and the changes from the platforms or by it's own development.

What is surprising to me though is the number of regression bugs, things that worked before or were fixed before and then breaking with the next release.
For me this is a clear sign of not testing enough. Stricter test regime may lead to some changes not being in the next release but catching them early is really necessary to avoid the stigma of a product that is unreliable, to say it bluntly.

More testing is something I would like to see as lesson taken from Xamarin.Forms for MAUI. It could avoid a lot of issues reported and wasted resources because the buggy code took the long way around instead immediately being addressed with the created PR.

[EmilAlipiev]

When i said "core features" and "critical bugs". This is what i mean issue like this one. This is super annoying now. I have done a release a week go without actually knowing this issue. I was wondering why apps retention dramatically dropped. Imagine i have mostly non-English speakers and Spanish or German user opens the app and it is English because of this bug. He will uninstall it straightaway although my app is translated into those language. This bug can happen but it was reported a mount ago? why wasnt fixed. Even Appcenter and Azure Pipelines have that bug.

[neolithos]

To improve the framework. I would like to add:

Improve the possiblility to write your own renderer. Avoid the keyword internal.

[SunnyMukherjee]

Rather than just posting sample projects on GitHub, Microsoft can create a professional, enterprise app like OneDrive or the Xbox app with Xamarin Forms, iOS, or Android and publish it to the App Store so that people other than developers will use it. Microsoft has done it before by migrating Visual Studio from C++ to C# and WPF (granted the customer is the developer in that case). That will tell Microsoft about our pain points and if they succeed, it will give tremendous confidence to the developer community that anything is possible with Xamarin.

[simon10says]

I'm glad there is a posting on this and I would like to weigh in my frustration. I'm often passive in posting replies to existing issue, but what triggers me is this issue in relation to the BundleAssemblies; after more than 2 months of this high impact issue, I still have no clear indication of what is the solution, status or path-forward from Xamarin members.

I run Agile Scrum team, and very often the KPI is the Velocity (the amount of work done). At times, when we have issue escalated to a certain heated level, my ending statement will always be "... I'm wondering what I can learn here to improve the quality of " [our product]. No offense (really), but that is just to patronize my boss or our customer. When I say that during that kind of discussion context, it will only mean that me or my Product owner is not up to the job or we are in the state of denial or worst still, we really don't know what's going on. (Kudos to one of our stakeholder who slap the sense out of me)

What really bugs me is the regression bugs and the lack of any concise response/explanation to the issue. Every single XF releases are prone to break something; and it breaks something which is obvious - alignment wrong, image not showing, text truncation not working and etc . Half of our test cases are just to check on these XF regressions; it's ridiculous. Obviously there is something wrong with XF internal testing. Even when a show-stopper bug is acknowledged, there can still be several subsequent new releases; what is the point of those new releases when we can't use it? Shouldn't those new releases go into your Beta?

Having said all these, me and our stakeholders are very weary about the "toxic culture" with XF. It is like how Windows 10 can release update that delete user's files or brick user's system (but at least their response and hotfix is quick). I believe our frustration here is not about the lack of features in XF, but it's about the quality of the release. As for how XF can improve the quality? You can search online and get millions of result; and I'm not even sure where to start here without being arrogant to undermine Microsoft's understanding of "quality assurance". I'm sure Microsoft knows how to do quality assurance (hey, I read Microsoft's white-papers on this). It's boils down to the person in charge; he/she needs the responsibility, accountability, and commitment to improve (or implement) quality check.

[tranb3r]

I think the most frustrating thing regarding XF is when our contribution (whether it's a new PR, a new issue, or even a simple question or feedback) is just ignored by the team.
The team is probably too small. But having one person dedicated to provide answers within a reasonable time would definitely help.

One good example is this regression regarding BundleAssemblies (it has already been mentioned several times).
Another good example is this issue regarding CollectionView.

[tranb3r]

Another concern for me is that a XF app is impacted by changes in XF of course, but also Mono, Visual Studio, Xamarin Framework, DotNet, and even some Microsoft libraries.
I have the feeling that those teams do not communicate well internally.
In my opinion, having Microsoft use XF internally for their apps would definitely help.

Again, one good example is this regression, for which the root cause is actually in Mono and AndroidX.
But I can also mention this issue in dotnet extensions impacting iOS apps, or even this issue in msal.
And of course this issue in visual studio, regarding source link.

[Amine-Smahi]

The people here did a great job saying most of what i was gonna say in details, so im gonna make it quick

Technical Problems

• Visual studio crashes more then 3 times/minute when working with XF.
• A lot of basic controls are missing, Or require a heck to shape them as they supposed to be.
• When you say XF your just saying the worst performance cross platform framework, and let me be clear for the people saying XF tackles native android/ios ... and that hard. Just look! please look! for the love of god! at flutter, RN, NativeScript... They all have the same goal but XF is far behind
• The hot reload works good only when you create a new project and make the default text in left side and thats it, Then your on your own!
• Everyone in the flutter community for exemple in every release be like : Oh OMG its so cool what they did, In other hand the XF com be like : Lets see what they broke or what they added that only 10% of the com needs!
• A starting journey using XF is a series of hecks, an example would be : recently i had to make one of the common controls in all the apps on Playstore which is a simple bottom tab icon only, Using shell with icon only have a big margin at the bottom which look ugly and like everyone, i created an issue, only to notice that a similar issue was addressed more then 6 months ago... And no fix in the way
• Think of an app okey ? Any app ? Does it have an in app purchase or some sort of premium service ? Of course it does. So you start looking for a plugin for google pay and apple pay right ? Or even paypale right ? Let me tell you something, there isnt !!! When you ask the official team of XF, you know what they ll respond ? They send you a link to an outdated not official plugin created by one man ( that i respect ) 2 years ago with no update, WTF (sorry) !!

Not technical

• Oh comme ooon even the official documentation is very poor , they tackle a todo app level features and how-to tutorials
• I hated XF even before using it, know why ? Everybody says even MS doesn't use so why the F would you use it ?
• A very slow response for issues and PRs which the community make on their own time and own expenses to help the XF team !!!

Solutions

• The XF team is very very small, How can a company huge as Microsoft doesn't hire enough people to make their own product better ? There are talents everywhere around the globe who looove Microsoft as much as i do!
• The XF should tackle high level issues before releasing, it only shows how immature the team is, like just ship who cares ...
• Microsoft most and is obliged to use XF for their products! If not its just a way of saying XF is good but nah i dont like it yukh
• Make a very rich documentation ! A doc that is the first go-to in most of the situations, hire more people! its as easy as that, There is a lot of experienced devs who blogs you can work with them
• XF isnt known as much as Flutter, Make partnerships with the big coding influencers on youtube, even a simple mention helps XF
• Its okey too look at other products and see whats the dev like about them and make your own version. Flutter for exemple.
• Dont be afraid of asking the community what they want, dont live under a rock and make what no one will use!

Im very sorry for my agressive behavior and my bad English, i really really like XF !
Maui is a new starting point please make it the new revolution, everyone is expecting to be something great so please dont disappoint us, we have big hopes.

[pauldipietro]

@Amine-Smahi Please reach out over email with more information on the behavior which leads to crashes ([email protected]).

[melimion]

I completely agree that bug fixing and new feature testing process is awful.

For example:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - stops from using ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - stops from using CompressedLayout

When you add new features that improves performance - that's great! But when these features is unusable, that's very disappointing.

And some of issues that affects my apps and not fixed for a long time:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

The team should take responsibility for features they implement. For example, @StephaneDelcroix implemented https://github.com/xamarin/Xamarin.Forms/pull/1136. I think he is the person who should be assigned for https://github.com/xamarin/Xamarin.Forms/issues/4168 and fix CompressedLayout-related bugs.

[tranb3r]

About documentation: I personally think that it's mostly ok, except for the release notes, which are totally f*d up ;) (always late or incomplete)
Again, I'm not talking specifically about XF, but more generally the whole xamarin framework (xamarin.android, xamarin.ios, visual studio, mono, components...).

Here is an example: xamarin ios release notes

[TopSkillDeveloper]

@melimion

When you add new features that improves performance - that's great! But when these features is unusable, that's very disappointing.

This is absolutely true.
You've added a CollectionView. The result is a bunch of errors on Android, on iOS it is generally unusable (Disposed exception, NSinconsistency exception, and so on. And this is if you do everything according to official guides (!).
You added CarouselView-the errors are the same.
We have to use an outdated but more stable Listview.

Now, when I see the title "we added", I immediately scroll further.
And you also have other elements, for example
Swipeview,Expander, which also have a lot of errors.
And then there is, as the person wrote above, mono, visual studio with its own bugs.

Cancel the new features in 4.7-4.8, pay attention for bug fixes.
Development on Xamarin is like finding workarounds, temporary solutions.
I apologize for my poor English

[bcaceiro]

Yesterday I have checked. There are more than 200 issues marked with high impact. There is no point in releasing new features, when critical bugs are yet to be resolved. I agree with the previous suggestion. Stop new features. Take time to fix and decrease the number of issues. I’m stuck at 4.4 , for example, because of an issue. Imagine so much more people in this situation. Stability and performance comes first, if there is no man power to have innovation and maintenance IMHO.

[freever]

I wonder if there could be some kind of poll amongst XF developers to see whether we'd rather see engineering effort going into clearing the existing bugs or adding the features planned for 4.7 and beyond. I mean the new features will themselves add more new bugs causing more rework and more delay... sometimes a good old fashioned feature freeze is called for.

For me personally, I'd want to see the most effort going into MAUI, which sounds like a sensible reset of the XF architecture, with the second most effort going into clearing high impact bugs. Adding new features wouldn't even get on my list - I'd rather add them when we have a better platform to add them to.

[mrwcjoughin]

@freever I totally agree!
Not only will this make current Xamarin devs happier, but it will resolve those bugs for MAUI as well!

[dustincatap]

I don't know if these bugs will be carried out to be fixed here in MAUI, or will they be fixed in Xamarin.Forms.

[PureWeen]

I feel like @davidortinau covered the spirit of this issue here

https://github.com/dotnet/maui/issues/109#issuecomment-635078640

I've updated the description with his comment

I really want to highlight this part of what he said again for everyone

we are spending much of our current sprints on CollectionView issues, and we are proposing to pause feature developer in Xamarin.Forms 5 so we have from Sept 2020 to Nov 2021 to shift more focus to issue resolution.

[tranb3r]

PureWeen closed this 10 hours ago

Dozens of xamarin developers have expressed their opinion in this ticket, and I do not have the feeling that they've been heard.
Sadly, you just proved my point

[Happypig375]

@PureWeen This issue covers much more than just number of bugs. They are even listed in point form.

[PureWeen]

@tranb3r

I think the most frustrating thing regarding XF is when our contribution (whether it's a new PR, a new issue, or even a simple question or feedback) is just ignored by the team.

How does @davidortinau 's comment fall short for you? The main point I'm making is that we are slowing down development on new features so that we can focus more on open PRs and bugs and then eventually get to .net maui which will be our newer .net 6 based product

@Happypig375

@pauldipietro reached out to the individual that posted that issue so that he can start addressing those issues more directly with them.

The spirit of this issue is that XF has too many bugs and ignores the community. So, we're slowing down new development to focus more on existing bugs and open PRs

If there are other issues outside the open bugs let's open issues for those. But this issue is about their being too many open bugs and we have a plan to address that.

With MAUI, we should have a bugfixing process that is as fast as possible. Any thoughts on how to improve?

We're stripping out a bunch of legacy aspects from Form with .NET Maui and we're spending this year before it focusing heavily on bugs and open PRs so that we can be more productive with .NET Maui

[PureWeen]

This is our project board

https://github.com/xamarin/Xamarin.Forms/projects

You can see what we are adding to each sprint
https://github.com/xamarin/Xamarin.Forms/projects/70

Here's our roadmap
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
We try to be as transparent as possible with what we're working on

If issues on those repos get pinged or have high focus we try to bubble those to the top but sometimes those algorithms aren't perfect.

@Amine-Smahi here's the project board for shell and what we see as blockers
https://github.com/xamarin/Xamarin.Forms/projects/54

Can you point me to the issue you are referring to so I can take a look at it?

[tranb3r]

@PureWeen

How does @davidortinau 's comment fall short for you? The main point I'm making is that we are slowing down development on new features so that we can focus more on open PRs and bugs and then eventually get to .net maui which will be our newer .net 6 based product

As mentioned before, this issue covers much more than just the number of bugs in XF.

If there are other issues outside the open bugs let's open issues for those. But this issue is about their being too many open bugs and we have a plan to address that.

There are already too many open issues !!! What's the point in opening new ones if you just ignore them...

For example, one of the important points mentioned before is that Microsoft teams should use xamarin when developing apps.
Do you hear this feedback ? What should we do to convince you that this is a good idea ? Are we supposed to open an issue for that ???

[PureWeen]

As mentioned before, this issue covers much more than just the number of bugs in XF.

Let's create different issues for those. Addressing multiple things into one issue isn't going to be productive.

What other comments in here that don't have anything to do with open bugs/prs/fragility concerns around XF do you want clarity on?

For example, one of the important points mentioned before is that Microsoft teams should use xamarin when developing apps.
Do you hear this feedback ? What should we do to convince you that this is a good idea ? Are we supposed to open an issue for that ???

Yes, we try to convince literally everyone to use Xamarin

We talk a lot with internal teams about app choices and it's an ongoing discussion. A lot of these internal discussions also will guide the direction of .NET Maui.

I'm not sure what else I can comment on about this. There's not much actionable here that I can do to help you specifically as a user.

[charlesroddie]

@PureWeen The spirit of this issue is that XF has too many bugs and ignores the community. So, we're slowing down new development to focus more on existing bugs and open PRs

So we expect slightly faster rate of bug fixes for a while. That's good but does not fully address this issue. Taking XF from beta quality to stable is a very large task and no quick fix or single strategy will achieve this. It will take major organizational, philosophical, and architectural changes. I would suggest:

1. Simplify the repository to make it easier to contribute and to review contributions. The new renderer architecture might help if it displaces XAML from the core and gives a more type-safe approach to renderers.
2. Prioritize bug fixes and clean code over features. Given that the culture of Xamarin is to add new features while ignoring bugs, the best way is to have a complete ban on new features until a threshold of quality is met for existing features.
3. Allow breaking changes which fix bugs and clean up code.
4. Make full use of .Net to reduce bugs. Keep things inside the type system wherever possible, and adopt C# 8 NRTs.
5. Fix the most basic controls first, then remaining controls.
6. Jettison old target OSes and old editors to clean up the repo, streamline testing, and free up resources for bug fixes.
7. Report on a metric of bugs pubicly. This will help to focus the organization on bugs. Put progress on bugs as the first section in any blog about an update.
8. Remove features to reduce the size of the repository, to make it more maintainable.

Our experience: we only use basic XF views because we don't trust anything else to be usable. Label, Entry, Button, Picker, Switch, DatePicker, Slider, StackLayout, ScrollView, ContentView, Grid, ContentPage. But even then, bugs crop up and remain for months. It's so hard to get fixes into XF that we just copy and paste renderers into our code instead.

[PureWeen]

Simplify the repository to make it easier to contribute and to review contributions. The new renderer architecture might help if it displaces XAML from the core and gives a more type-safe approach to renderers.

That's our plan. I've created a place holder issue here that you can follow or offer your suggestions https://github.com/dotnet/maui/issues/147

Prioritize bug fixes and clean code over features. Given that the culture of Xamarin is to add new features while ignoring bugs, the best way is to have a complete ban on new features until a threshold of quality is met for existing features.

This is mostly our plan.

Allow breaking changes which fix bugs and clean up code.
Make full use of .Net to reduce bugs. Keep things inside the type system wherever possible, and adopt C# 8 NRTs.

This is slowly our plan. But it's important to understand the full scope of users that use our products. For example, once we broke vs2017 support this issue here popped up which received a ton of comments from users
https://github.com/xamarin/Xamarin.Forms/issues/7602

So we can't just take the jump. I would 100 percent love to take that leap but we can't just break people.

But we do consistently takes steps to be prepared for this leap. For example the PR here
https://github.com/xamarin/Xamarin.Forms/pull/10937

Will allow me to run internal CI process to test against C# 8 and other beta features so that once we can take the leap it'll be an easy leap to take.

Fix the most basic controls first, then remaining controls.
Jettison old target OSes and old editors to clean up the repo, streamline testing, and free up resources for bug fixes.

That's our plan as I've mentioned above

Report on a metric of bugs pubicly. This will help to focus the organization on bugs. Put progress on bugs as the first section in any blog about an update.

Looking into this. @samhouts runs a lot of these reports for us every sprint so we have perspective on everything but we'll look into surface this out better to the community.

Remove features to reduce the size of the repository, to make it more maintainable.

This is our plan with .net MAUI. Before we launched our .NET MAUI plan we prepared lists of areas that we can reduce so to be more effective. A huge part of this will be the renderer work.

[hamiddd1980]

Hi , in addition to mentioned Issues , there are many Bugs related to Right To Left languages.it seems these bugs are of less importance from viewpoint of Xamarin Forms Team (probably due to less usage of Right To Left languages than English or other Left To Right languages) , but lack of full support for right to left cultures ,is discouraging and disappointing and actually stops Developers to use XF in international / multilingual / Right To Left Apps.
Thanks.

[PawKanarek]

Next two months old issue: https://github.com/xamarin/Xamarin.Forms/issues/11166
Bug Created 22 Jun.
PR opened 25 Jun.
Bug Status 17 Aug: Still not merged. Why? ;(

[EmilAlipiev]

@PawKanarek welcome to Xamarin. usually they merge only fixes or Prs made by the team. that's why it is discouraging to contribute on Xamarin. I think that they reduced the team capacity. only 2-3 people actively working on the project. if you need a quick fix build your own xamarin nuget packages.

[kcrg]

@EmilAlipiev But this time the PR (for #11166) was opened by a member of the Xamarin team and still hasn't been merged xD

[samhouts]

If you take a look at our release notes and GitHub insights, we merge tons of PRs from the community. In fact, I see your name on the latest list, @EmilAlipiev :)

You can see that over the last month, 40 new pull requests have been opened by 18 different people. Pull requests have to be fully tested and reviewed, and with the quantity that we receive, we have to prioritize blocking issues and major regressions with no workarounds.

I know we're not always perfect, but we are working to improve every day. Thank you for your patience and for sticking with us. We can do this together!

[samhouts]

@hamiddd1980 You'll be happy to know that we've been working quite a bit on RTL over the last few months. I hope it improves your experience!

[PawKanarek]

@samhouts Just remember that you are not an end product of Xamarin. We need not only patience, but also a lot of human resources and money. Any open & verified bug in github should be fixed asap because it creates a snowball effect in the form of technical debt, anger and unnecessary tensions with our clients.

Please fix more bugs, don't add more features. Stability over functionality. You have still 1,590 verified bugs https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A%22

[EmilAlipiev]

@samhouts thanks for your reply. 1-2 merge per day is extremely less. I work on other cross platform tool and they have 15 merge per days 455 merges last month. I still love Xamarin as tool more though and i am willing to contribute always but my merge took more than 2 months and i had to create this merge 3 times with rebased from different branch.
Beside that there is prioritizing issue on your side. People are desperately looking for fixes for core tools like such bug as Device.Idiom.. or CollectionView bugs etc.
Today there was a great progress indeed 8 total merges so far. But to be honest below merges, less people are interested in with swipe view, gradient brushes or themes etc. when there are such critical PRs are in queue for months. This is the biggest frustration i believe

[knocte]

Any open & verified bug in github should be fixed asap

This is obviously unrealistic; even if Microsoft dramatically increased Xamarin.Forms team size.
Work smarter, not harder, they say (in this case, this should mean requiring PRs to include regression testing to make sure the bugs don't reappear; however, as with anything, this is also a trade-off, because reviews of contributed PRs will get longer and harder).

Please fix more bugs, don't add more features

This is an opinion I share too. However, strictly speaking, the MAUI<>Xamarin.Forms transition plan already covers this: Xamarin.Forms will transition into only bug-fixing mode, while new features will only land on Maui.

[samhouts]

(in this case, this should mean requiring PRs to include regression testing to make sure the bugs don't reappear; however, as with anything, this is also a trade-off, because reviews of contributed PRs will get longer and harder).

Absolutely. This is a tradeoff that we've been struggling with, too. We have thousands (!) of tests that are automated, and we run them on multiple devices. The problem is that it takes hours (currently about 4 hours per run per device) for them to complete, and they are sometimes, unfortunately, a bit flaky for any number of reasons. For example, I just pinged a contributor yesterday about a test that I thought was legitimately failing, only to realize that it was actually failing because Chrome was asking us to accept the new terms of service. 🤦

This leads to a lot of delays, and it means that PRs can sometimes take days just to pass tests. That's on us, and that's a problem we need to solve.

Fortunately, we _are_ working on this problem. We're developing a new method of testing platform renderers more like unit tests than actually automating the UI, which is far more reliable and faster.

As far as adding new features vs fixing bugs...as @knocte says, the transition plan is designed with this in mind. Our goal is for .NET MAUI is to be lean, fast, and reliable. As part of this, we're evaluating what features actually belong in the core project and what features are better suited for the new Community Toolkit--which still has Microsoft backing, but is largely supported by the community.

Please know that we always have you and your customers in mind as we make any changes, and we're listening to your feedback.