About the 1675 open bugs in Xamarin.Forms #109
Comments
Hopefully the team has a plan to remove some of the bottlenecks around the PR + release process. |
|
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. |
|
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
|
|
I agree 100% with @Reveon 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 |
|
Another testimonial:
|
|
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.
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. |
|
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. |
|
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... |
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 |
|
@SunnyMukherjee From the FAQ,
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. |
|
@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. |
|
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:
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. |
|
In short:
I rebased the pull request tree days ago. Why is the review taking so long? |
|
WPF-Renderer, points of potenial bugs:
|
|
Hi @davidortinau, I think a good way of tackling this is publicly devoting someone to be full involved in:
He/she we'll be our point of contact if something goes too slow and he/she can explain what's going on. |
|
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. 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. |
|
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. |
|
To improve the framework. I would like to add: Improve the possiblility to write your own renderer. Avoid the keyword |
|
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. |
|
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. |
|
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. One good example is this regression regarding BundleAssemblies (it has already been mentioned several times). |
|
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. Again, one good example is this regression, for which the root cause is actually in Mono and AndroidX. |
|
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
Not technical
Solutions
Im very sorry for my agressive behavior and my bad English, i really really like XF ! |
|
@Amine-Smahi Please reach out over email with more information on the behavior which leads to crashes (paul.dipietro@microsoft.com). |
|
I completely agree that bug fixing and new feature testing process is awful. For example: 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: The team should take responsibility for features they implement. For example, @StephaneDelcroix implemented xamarin/Xamarin.Forms#1136. I think he is the person who should be assigned for xamarin/Xamarin.Forms#4168 and fix CompressedLayout-related bugs. |
|
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) Here is an example: xamarin ios release notes |
This is absolutely true. Now, when I see the title "we added", I immediately scroll further. Cancel the new features in 4.7-4.8, pay attention for bug fixes. |
|
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. |
|
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. |
|
@freever I totally agree! |
|
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. |
|
I feel like @davidortinau covered the spirit of this issue here I've updated the description with his comment I really want to highlight this part of what he said again for everyone
|
Dozens of xamarin developers have expressed their opinion in this ticket, and I do not have the feeling that they've been heard. |
|
@PureWeen This issue covers much more than just number of bugs. They are even listed in point form. |
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 @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.
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 |
|
This is our project board https://github.com/xamarin/Xamarin.Forms/projects You can see what we are adding to each sprint Here's our roadmap 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 Can you point me to the issue you are referring to so I can take a look at it? |
As mentioned before, this issue covers much more than just the number of bugs in XF.
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. |
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?
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. |
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:
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. |
That's our plan. I've created a place holder issue here that you can follow or offer your suggestions #147
This is mostly our plan.
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 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 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.
That's our plan as I've mentioned above
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.
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. |
|
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. |
|
Next two months old issue: xamarin/Xamarin.Forms#11166 |
|
@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. |
|
@EmilAlipiev But this time the PR (for #11166) was opened by a member of the Xamarin team and still hasn't been merged xD |
|
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! |
|
@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! |
|
@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 |
|
@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.
|
This is obviously unrealistic; even if Microsoft dramatically increased Xamarin.Forms team size.
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. |
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. |
XF surpasses mono. For me it is very frustrating and sometimes i think we should develop our apps with java and xcode. Perhaps this cost us less money to develop an app for ios and android. |
|
you do realize both iOS and Android have bugs too? No software, beyond
hello world apps, are without bugs.
as has been said here before flutter, react, etc all also have tons of bugs.
…On Fri, Jan 8, 2021 at 1:03 PM AlleSchonWeg ***@***.***> wrote:
Xamarin.Forms is known to be buggy. It currently has 1675 open bugs,
<https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+label%3A%22t%2Fbug+%3Abug%3A%22+sort%3Aupdated-desc>
which is on track to surpass mono's 1676 open issues.
<https://github.com/mono/mono/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc>
By comparing the numbers, it is easy to see that Xamarin.Forms is buggier
than the "historically buggy" mono framework.
XF surpasses mono. For me it is very frustrating and sometimes i think we
should develop our apps with java and xcode. Perhaps this cost us less
money to develop an app for ios and android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOGERQGC2LAZI7ZY35U5CTSY3Q7ZANCNFSM4NJQSO2Q>
.
|
and others
Please read this comment from @davidortinau
#109 (comment)
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:
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.
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?
The text was updated successfully, but these errors were encountered: