xamarin / Xamarin.Forms

Xamarin.Forms is no longer supported. Migrate your apps to .NET MAUI.
https://aka.ms/xamarin-upgrade
Other
5.63k stars 1.88k forks source link

[Question] Xamarin.Forms end of life? #14205

Closed Tommigun1980 closed 2 years ago

Tommigun1980 commented 3 years ago

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!

Tommigun1980 commented 3 years ago

@jfversluis This is EXACTLY what we hoped for, so thank you so much for supporting us and your product!

Also a huge thank you for the openness and for soliciting feedback on the service releases — this is something that has been missing, as some betas in the past have had absolute blocker regressions that still made it into the “stable” releases despite flagging the issues in bug reports. We must have a channel to escalate that something got terribly broken and shouldn’t be released, so you working more directly with us on this is a tremendous win for us developers and for your product.

Thank you again!

AndreasReitberger commented 3 years ago

@jfversluis This is also a bug which would be very important to be fixed.

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

It's open for several years now... Thanks for your efforts!

Sergtek commented 3 years ago

@jfversluis This problem is very blocking for our application, it prevents updating the source of the SfListView in macOS at runtime, it is very frustrating that something so basic is failing which forces us to look for laborious temporary patches with the loss of time that it causes. N.º 14155

jsuarezruiz commented 3 years ago

As Gerald mentioned, we are here, we read your feedback and we want to have regular releases improving. It is impossible to attend to everything at once, I hope it was possible!, but we will try to create boards with the issues, status, explain the priorities established etc. We will also update with progress status.

We keep moving forward, but I want to share 3 PRs of 3 issues mentioned here: https://github.com/xamarin/Xamarin.Forms/pull/14565, https://github.com/xamarin/Xamarin.Forms/pull/14567 and https://github.com/xamarin/Xamarin.Forms/pull/14565 There will be a NuGet package associated with each PR so if you can test and give feedback it would be great!

Again, thank you all for your feedback and help to improve Xamarin.Forms!.

jfversluis commented 3 years ago

Just to reiterate and add to what Javier is saying: we'd love to fix all the issues, but we can't. We'll do our best to get out as many as possible. I'm working on a more structured plan with regular, predictable releases and I will be the one dedicated to only pushing those out and keeping you updated. As soon as I can share more concrete things about this I will.

Having that said; keep adding things to this issue, I will definitely keep an eye on it, at least until we work through the initial list of issues that we gathered here. Just know that it's not a guarantee that they will be picked up with priority or will be fixed at all.

Also, I'd really appreciate it if you could go over the issues that are important to you and try out the NuGets on the PRs, that will help speed up getting them merged for sure!

For people wanting to reach out and maybe discuss something more direct instead of going back and forth over an issue I am on the Discord server we have. Consider joining that and reach out to me directly or preferably on the #xamarin-forms channel. If you have any other preferred way of communicating let me know and I can see what we can do.

Thanks all!

MagicAndre1981 commented 3 years ago

It would be also nice to add #13150 to next SR 🤞

developer9969 commented 3 years ago

@jfversluis @jsuarezruiz Having some feedback is a massive improvements. Thank you!! It's understandable that you cannot fix everything as there have been years of neglect, but I would like to point out that one of the major component "CollectionView" is causing lots of problem in delivering quality apps . This is in my view is one of the most used and important component after the grid, we dont expect to be perfect but usable, "Scrolling-grouping-selection-footers-resizing -emptyview etc.." those are basic functionalities that make or break an app!!.

Everyone will have a set of bugs that is important to them but I guess that if a priority has to be set than the CollectionView should be at the very top, and if not fixed it will be just the same with MAUI.

I hope this release will include fixes to the collectionview.

Thank you again for the feedback

jfversluis commented 3 years ago

Thanks @developer9969 I wouldn't call it neglect, but let's not go into discussions about what has happened in the past. We can't change that :)

I hear you about the CollectionView and that definitely has our attention. We would love for you to use it instead of the ListView and everything we fix for the CollectionView today will also benefit .NET MAUI. I think a lot of the issues in this issue (issue-ception...) are also about the CollectionView that will be a area of focus, but thanks for underlining the importance!

jsuarezruiz commented 3 years ago

More PRs from issues mentioned in this thread: https://github.com/xamarin/Xamarin.Forms/pull/14572, https://github.com/xamarin/Xamarin.Forms/pull/14573

jsuarezruiz commented 3 years ago

The message from this issue https://github.com/xamarin/Xamarin.Forms/issues/14409 is similar, and I want to associate them and share the same message everywhere: we are here, we want to improve as much as possible and we will openly inform everything.

AndreasReitberger commented 3 years ago

@jsuarezruiz @jfversluis Thank you for getting this repo back to life :)

Maybe you also can look into this issue. It came up with SR4, as far as I can remember. https://github.com/xamarin/Xamarin.Forms/issues/14510 And those: https://github.com/xamarin/Xamarin.Forms/issues/13510

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

Thank you, Andreas

MagicAndre1981 commented 3 years ago

RP #14506 should be also added as this will fix compile issues with latest Xamarin google material nugets.

And I've seen a bot here on github that does nuget updates, I see that XF has a lot of pending nuget updates so maybe adding the bot here would help detecting such major issues like with Xamarin google material nuget

jfversluis commented 3 years ago

RP #14506 should be also added as this will fix compile issues with latest Xamarin google material nugets.

And I've seen a bot here on github that does nuget updates, I see that XF has a lot of pending nuget updates so maybe adding the bot here would help detecting such major issues like with Xamarin google material nuget

I was going to check on that one and make sure to see if it needs to go in. Thanks for the bot suggestion, we're aware but I don't think it's something we would want to do automated :)

@jsuarezruiz @jfversluis Thank you for getting this repo back to life :)

Maybe you also can look into this issue. It came up with SR4, as far as I can remember.

14510

And those:

13510

12141

Thank you, Andreas

The first one is already fixed and should be in the next release, I've added the other two to the next service release version board

jfversluis commented 3 years ago

These issues were mentioned in #14409

11993, #5265, #14363

Adding them here and closing the afore mentioned issue so we can keep things a bit centralized

YiannisBourkelis commented 3 years ago

Nice to see that MS devs are focusing again on solving Xamarin.Forms bugs. We need this to keep working on this framework. I have also run into several issues with keyboard handling, but I was able to find workarounds expect this one I had posted here, about keyboard dismiss on key press: https://github.com/xamarin/Xamarin.Forms/issues/12945

Keyboard issues are also reported every now and then from other developers here.

melimion commented 3 years ago

It would be great to fix dynamic sizing issues in CollectionView:

https://github.com/xamarin/Xamarin.Forms/issues/9520 https://github.com/xamarin/Xamarin.Forms/issues/11011 https://github.com/xamarin/Xamarin.Forms/issues/13781

And some CollectionView initialization issues: https://github.com/xamarin/Xamarin.Forms/issues/9079 https://github.com/xamarin/Xamarin.Forms/issues/13675

MagicAndre1981 commented 3 years ago

RP #14506 should be also added as this will fix compile issues with latest Xamarin google material nugets. And I've seen a bot here on github that does nuget updates, I see that XF has a lot of pending nuget updates so maybe adding the bot here would help detecting such major issues like with Xamarin google material nuget

I was going to check on that one and make sure to see if it needs to go in. Thanks for the bot suggestion, we're aware but I don't think it's something we would want to do automated :)

from what I see the bot generates PRs that have to be reviewed and merged, so you still have the control

angelru commented 3 years ago

I think this is also important: 10085 13459 7166 13121

cc @jfversluis @jsuarezruiz

Thank you so much for everything!

DDFLotz commented 3 years ago

Great to see that SR5/6 is happening :) Down below is a list of important issues for our team

TitleView related:

12382 (links to a working PR)

CollectionView related:

11299

6554 (open since 2019)

TabbedPage related:

11301

it would be awesome if some of them could be addressed and updated, thanks!

ondrejsv commented 3 years ago

6554: I second that.

eramrit78 commented 3 years ago

13229 this one also

workgroupengineering commented 3 years ago

I have a suggestion. You can create a section in the "Priority Issue" discussions and replicate or transfer issues that are considered important. The advantage of this solution is that it is possible to vote the discussion in order to avoid duplicates and get the situation quickly.

jfversluis commented 3 years ago

Thanks for the suggestion @workgroupengineering I'm not quite sure if I understand what you mean though :)

jfversluis commented 3 years ago

Hey everyone! We're about to release a new service release version. From here on out our aim will be to release one every month until the end of life of Xamarin.Forms :) I will keep creating new projects and set a target date on it, it might not be perfect each month, but should be around that date. First focus is still low-hanging fruits and issues mentioned here. They already seem concentrated on CollectionView but CollectionView will definitely be a big focus for us as well.

A lot of you have already been cooperating by testing out the fixes in PRs and such. A big thanks for all of you, let's keep up the great work together! <3

DeerSteak commented 3 years ago

Glad it's not going to be another five month wait like it was between SR3 and SR4. We get that MAUI is the future, but we live in the present and have to ship apps in the present.

edit: @jfversluis do you know if the dependencies for Xamarin.Forms on Android will be updated to the latest Xamarin.AndroidX and Xamarin.Google.Material libraries? A bug introduced in Xamarin.Google.Material 1.2.0.0 prevents me from using the latest Xamarin Forms. The bug was fixed in a later Xamarin.Google.Material release, but the Forms dependencies on Android prevent upgrading. As a result I'm still stuck on 5.0.0.1931 because SR4 is affected by this bug.

AndreasReitberger commented 3 years ago

@jfversluis @jsuarezruiz Thank you for your great effort the last weeks. Looking forward to the next releases.

I'm just curious, is there a reason why the updates get released while not all bugs are fixed linked in the projects?

SR4: https://github.com/xamarin/Xamarin.Forms/projects/86 SR5: https://github.com/xamarin/Xamarin.Forms/projects/87

Are this bugs still on your list?

Thank you 🙏

tschramme86 commented 3 years ago

Thank you for your continuous effort here! Really appreciate

Since I just saw that there are several Shell Navigation Bugs on the list to fix in SR6, maybe you can also check if this one is possible in SR6? https://github.com/xamarin/Xamarin.Forms/issues/12958

jsuarezruiz commented 3 years ago

@AndreasReitberger They continue to be taken into account in upcoming releases.

jfversluis commented 3 years ago

@DeerSteak SR5 should have all the Google dependencies updated to the latest bits at this time.

@AndreasReitberger I'm a bit behind on the administration but the idea is to move unfinished issues to newer boards. However, be aware that we still are in charge of the priorities which might not align with yours.

Thanks everyone for the positive notes!

Crotalus commented 3 years ago

Here's another issue that cause problems for people still using ListView:

Regression with ListView when CachingStrategy RecycleElement is used. It causes massive lag in debug mode with hot reload: (5.0.0.2012 broke it, works in XF 5.0.0.1905)

Issues: #14069, #14218, #14190 (and maybe #11344)

davidaramantSEP commented 3 years ago

With the announcement that Maui is being pushed back to Q2 2022, is the Xamarin support period extended as well?

jfversluis commented 3 years ago

@davidaramantSEP yes it is :) the support will be 12 months from the .NET MAUI GA date

tranb3r commented 3 years ago

When is SR5 (5.0.0.2117) nuget going to be released ?

AndyDentFree commented 3 years ago

the support will be 12 months from the .NET MAUI GA date

That's good but not confidence-inspiring news.

Bare minimum which would restore my confidence would be 12 months from .Net MAUI STABLE state with a clear and detailed explanation agreed on by the community on what we consider stable including a commitment to which demo applications MS will commit to keeping working as a smoke test of MAUI.

Much less than that leaves us floating in a sea of doubt as to what's a safe recommendation for new projects.

davidaramantSEP commented 3 years ago

I agree that I think Microsoft needs to do something extra to inspire some more confidence in the platform. The experience with Xamarin for the last year has really called into question if we should be recommending Xamarin/Maui to clients for new projects. At a minimum, we need to have a hard discussion with the client about what we've seen and let them make the call on whether it is too risky to rely on. Support going AWOL for months on end is simply unacceptable.

You are saying the right things, which is great, but that only goes so far. Being more transparent on what efforts Microsoft is taking to improve the quality of Xamarin & Maui would be very appreciated. Relying entirely on the community to report bugs isn't good enough - some of the issues with CollectionView (for example) were so dire it should have never have left the "experimental" state and certainly shouldn't have been the recommended go-to solution in the documentation.

jfversluis commented 3 years ago

When is SR5 (5.0.0.2117) nuget going to be released ?

It should have been released already but during our quality check we found a regression that we wanted to fix. I'm creating a new build as I am typing this release should be ASAP. Following releases should be more smooth.

@AndyDentFree Sorry you feel that way, nothing much I can do about it though. I think a consensus with the community will be quite hard to achieve. I'd love to see demo apps that serve as a smoke test. We have some out there, whether it be official or not and there tests and QA going over that as well. Also that is an area in which we have learned a great deal that will feed back into .NET MAUI.

@davidaramantSEP I'm doing everything I can to bring back at least some of that confidence. I am being transparent and very frequently updating you. And you're right: I'm saying the right things, now I have to do them, so instead of having discussions here that's what I will redirect my efforts to. I hope that will be enough.

AndyDentFree commented 3 years ago

I'd love to see demo apps that serve as a smoke test.

This is a topic dear to my heart. I worked for nearly two years at Realm, on the C# SDK for their mobile database. So, I've been where you are now (without the amount of technical debt). Part of my job included tech support and also doing releases.

We had some trivial smoke test apps and building them from scratch with each release was our way to validate that the latest Xamarin Forms toolchain hadn't broken something.

By from scratch I mean we had the source code ready to copy-and-paste but created a brand new app each time. Painful experience proved that just recompiling an app with the latest build is not the same as validating people's experience of building new apps.

This may sound onerous but, when things work, it's about 10 minutes per platform, per release.

jfversluis commented 3 years ago

Thanks for sharing from your experiences!

varyamereon commented 3 years ago

My ten cents, #14505 is a blocking issue for me as I've been unable to find a workaround and it means the app basically doesn't work on iOS 15. Would think this affects a large number of people. Same as https://github.com/dotnet/maui/issues/1654.

tranb3r commented 3 years ago

This one also deserves to be fixed : #8383

Amenti commented 3 years ago

We get a lot of bad customer feedback due to the broken scrolling of Editors beginning with iOS 14, see #13040, #2233, #4695, #12695. :(

dan5602 commented 2 years ago

My ten cents, #14505 is a blocking issue for me as I've been unable to find a workaround and it means the app basically doesn't work on iOS 15. Would think this affects a large number of people. Same as dotnet/maui#1654.

This is also a huge issue for us. iOS 15 is unusable. All 'Back' navigation buttons can not be seen in the nav bar, This means our customers can not navigate the app. Our app uses Shell. Customers who have upgraded to iOS 15 are already complaining - This issue surely needs some priority? How was this not found during all of the betas? Please help.

jfversluis commented 2 years ago

Just a quick update here: we have released our first service release yay! 🤗 The actual release took a little longer than expected. We came across a regression while it was running through QA and some other minor things surrounding procedures and pipeline. I will make sure that we have those issues cleared for the next release so that one will be a bit smoother and faster on NuGet.

From here we are going to release one every month until end-of-life, no matter how big or small the release will be. I will keep creating project boards and keep moving the list along and hopefully it should get shorter as more fixes go in. Each board will have a target date on it. That date is not set in stone, it could be a few days early/late, but at least you know when to expect something.

We still could use your help! You can do so by testing out the fixes from PRs as we publish those. Also, if you have a solution in a custom renderer right now, or you have pinpointed a cause of a bug, be sure to let us know, that will help get your bug fixed as well.

Priority at the moment will be CollectionView, Shell and any quick fixes we can do easily or might already be in a PR.

Thanks for your patience and on to the next release!

AlleSchonWeg commented 2 years ago

Hi @jfversluis , i have a question. ;) What happens with the open issues in the XF github repository, if XF support comes to an end? Will the repository deleted and the issues transfered to maui? Or all issues will be fixed before the repository is closed? 😎 At the moment i have 10 issues open and around 50 issues/pr which i'm watching and hoping for a fix.

Thx

jfversluis commented 2 years ago

Good question! Thank you for that.

I think it's clear we're not just going to blindly move over what we have here to the .NET MAUI repo. Then we will already be under water even before we started, that's not going to be fun for anyone. And although I would love to fix them all before we leave Forms behind, I think that is not realistic as well.

Together with pushing out Service Releases I'm also trying to go through the list and see what is still relevant. That is a hard thing to do because it's impossible to test everything that is in there. There is a good chance that there are issues that are outdated. Either because too much time has passed or the bug is fixed, either in .NET MAUI or Xamarin.Forms. For the issues that we are fixing in Forms during the remaining lifetime will go on a list so that we can verify against .NET MAUI and we don't have regressions there.

However, there definitely will be bugs that are still relevant on the Xamarin.Forms repo. To be very honest I don't have an actionable plan for it right now. If you are willing and able to help out and verify Forms vs .NET MAUI I can only ask to test things on .NET MAUI and let me know the results on the issues here so I can give them a label or, even better, close them if they are already fixed.

For all the rest; if you have any (realistic, achievable) suggestions to handle this, I am definitely open to ideas!

Additionally, thinking about this, let me break up the issues: bugs and features.

Bugs should be fixed, but see al of the above. Features are definitely not going to be added anymore. So as a rule of thumb: any issue or PR that will add new functionality or APIs to Xamarin.Forms are definitely not going to be added anymore. If you have those on your list and they are important to you I would like to suggest you open a new issue on the .NET MAUI repo with all the (updated) details on what you would like to add and add a link to the Forms issue.

I am curious about your list though. Could you post it here or send it to my email? To be clear: me asking means absolutely nothing in terms of things going to be solved. Just curious what the things are that are important to you. Thanks!

Does this help at all?

AlleSchonWeg commented 2 years ago

Hi, email sent! Thank you.

AndyDentFree commented 2 years ago

A modest economic proposal responding to @jfversluis's comment on bug fixes.

Quick version:

  1. Build one or more big sample apps that show the most important bugs, to also become smoke test for MAUI.
  2. Use interns/cheap outsourced labor for initial review, building a simpler central list linking issues to 1.

Context:

  1. Strategically, MAUI needs to be robust - this & other issue threads demonstrate community concerns
  2. The legacy of Forms bugs & age of many reports means awkward verification - need a more central status tracker
  3. A single or very small set of demo apps as smoke tests means it's easy for MAUI builds to be verified and also ongoing detection of Forms regressions.
  4. Expensive, relatively senior people shouldn't be getting bogged down in issue review.

Related idea - make it a new interview question for anyone recruiting Xamarin Forms developers - they have to verify an issue. Shows ability to build, communicate & diagnose.

Demo App size philosophies

There are two reasons to have demo/test apps. One is to explore or prove a technology & these are best kept as small as possible so maintenance is lightweight. Someone needing to explore that tech in future wants the least possible effort in updating a sample, especially if they are trying out preview/alpha versions of frameworks.

Smoke test validators to build confidence that a complex, realistic scenario is both buildable and works need to be bigger.

Frameworks like Forms need both.

(I'm trying to be more helpful than my previous disappointed rants.)

jfversluis commented 2 years ago

Thanks for your input!

MitchBomcanhao commented 2 years ago

@AndyDentFree an issue with interns reviewing issues is that they don't know the product at all, and so will create more churn for people trying to report the problems (and the interns not understanding the problem) and then the more experienced/competent people will still have to review whatever stuff the interns did/didn't do because they can't understand the problems enough to effectively review them, or miss out on important issues being excluded/ignored by the interns.

what you're describing makes me think of the microsoft answers forum where the microsoft "experts" have no knowledge of the products and just regurgitate the same answers over and over, even when they clearly do not apply to the problem being discussed.

what you're proposing will effectively just make things more difficult as we will have to convince some middleman who has no idea about the technical stuff that our problem is indeed a problem and needs to be looked at by someone higher up.

tranb3r commented 2 years ago

It does not matter how many open issues there are. The important thing is to make sure it's easy to identify high priority issues. But I'm not sure it's the case right now.

A few numbers:

Maybe the most impactful thing to do would be to review (and fix) those 24 'high priority' issues. label:"t/bug :bug:" is:issue is:open label:"m/high impact :black_large_square:" reactions:>10

What do you think ?