Forum Xamarin Xamarin.Forms

Abandoning Xamarin.Forms :(

Hi there,

over the last months I wrote a quite big business application using forms.
The main target was UWP, but we needed the possibility to create IOS and Android versions along the road.

Overall my impressions were not too good. The goal was that just a few developers could maintain all targets.
In the end most of my time was spend working around bugs in forms and making it behave like I wanted it to.

The backend is a very portable assortment of PCL modules, around a forms host app that should provide the UI
for it, manage navigation and stuff like that. A bad design decision was that, because we had a unified design language,
that modules can provide designs for UI elements, pages and so on directly in Forms code or xaml.

It almost worked, as long as the app was simple, just a few modules providing elements for a dashboard, some process
pages. As it got more complex and flexible (updating, inserting and deleting Elements in real time, lots of more different
Elements from other modules for the dashboard) it began lacking.

What was once very smooth is now flickering and delaying.

But the real problems are, now that the app is almost finished:

  • Every Update somehow breaks something, most of the time the android build needs a day of reading and fixing and manually fixing
    the project files to maybe work again

  • Creating custom renderers for everything. I want a different Titlebar design for Master/Detail pages or a Frame that inexplicably
    doesn't show the rounded border non-transparent or lots of other tweaks I had to research and write one. I even had to write one
    that does a nasty hack for tabbed pages because for whatever reason the tab titles are non formatted or highlighted when using
    it like I should. Also lack of PDF and other very default formats is lacking and needs a custom implementation. I only did this for UWP...I don't even
    want to think about repeating it for Android or IOS

  • Image problems. Using URI Sources just doesn't work sometimes. Images don't show in one place but the same URI shows
    in another. I also had lots of problems when using buffered images and stream sources. For example, they don't show up when used
    in datatemplates in lists, if this datatemplate is defined in a different PCL for whatever reason

  • Random complete UI blocks. I made sure that there is nothing interesting running on the UI thread. And it works most
    of the time just fine. Just randomly blocking UI for about 5-10 seconds. I never found a source for that.

  • Random complete app crashes. The app works fine, concurrency should be good. But repeating the exact same process
    just sometimes results in a uncatched exception with just the text "Unspecified Error" an no further explanation or stack trace

Just the random untraceable crashes are enough to never being able to release it and I'm not confident in posting bug reports for
every little thing i encountered, seeing that bugs from 2 years ago are not yet fixed and the activity on forms is severely lacking in
the last months.

Well, in the end I guess it is my fault. Forms was not the correct target for this application and luckily 90% of the code is reusable.

Sorry for the rant :)



  • JohnHardmanJohnHardman GBUniversity admin
    edited September 2016


    Image problems. Using URI Sources just doesn't work sometimes. Images don't show in one place but the same URI shows in another. I also had lots of problems when using buffered images and stream sources. For example, they don't show up when used in datatemplates in lists, if this datatemplate is defined in a different PCL for whatever reason

    By coincidence, I received a notification from Bugzilla yesterday claiming that this (or something very similar) has been marked RESOLVED FIXED with the usual message sent out:

    "Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Forms as of 2.2.0. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction. 
    For your convenience, we have created some reproduction best practices viewable here:  
    Warm regards, 
    Xamarin Forms Team"

    Needless to say, I still see the problem when using XF :-(

  • JohnHardmanJohnHardman GBUniversity admin
    edited September 2016

    @MarcusSchebesta - You are not alone…

    Random complete UI blocks

    I see these too. I have been assuming this is the garbage collector kicking in, but haven’t investigated yet. Wondering if I should search the XF source for synchronisation code with timeouts...

    Random complete app crashes

    I’ve heard other people mention this, but have not seen it myself. I put try/catch blocks around any code of mine that is called from the framework etc (so, methods with names starting "On" etc). The trickiest things to find in my experience are when exceptions are thrown in custom renderers – if you don’t catch them, the stack traces can be of no use whatsoever. Again, I now have comprehensive exception handling in my custom renderers, as well as unhandled exception handlers (is that a contradiction? ;-) ).

    It appears that Xamarin people are now working on getting Xamarin.Forms released on Mac, rather than sorting out existing issues. When will product managers get to make decisions about strategy, rather than techies creating new stuff because it's more fun than working on stability? I was hoping Microsoft would have sorted this by now.

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    Did you try using FFImageLoading for images? Did you try Insights for exception handling? I'm not sure if it catches everything.

  • MiguelCervantesMiguelCervantes MXMember ✭✭✭

    Indeed I found bugs and stuff but the time I spend fixing them or living with them are still less (a lot less) than having to code for iOS and Android.

    I have been working with XF since 1.3, more thane a year ago and I have to say they have improved a lot and I'm sure this technology is the way to go (talking about Xamarin in general)

    Recently I reported a bug involving service stack and the mono core but it was succesfully corrected.

    I agree that its very hard (spending time) to make a custom renderer for everything that most of the times are just UI changes like rounding the corners of a Frame but at the end of the day you can live without those changes, your app will grow and is going to improve so in the meanwhile you can live with the contents inside of the box (talking about XF)

    I think that you need to have an architecture before you write the first line of code. So maybe its not XF at all.

    BTW I have a released app (bank app) for both platforms.

  • EmanueleSabettaEmanueleSabetta ITBeta ✭✭✭

    Three quotes that photograph the current Xamarin.Forms state:

    @BradChase.2654 said:

    Our app runs smooth as butter on iOS but Android now is bogged down so much
    so that it'll take up to 10 seconds for a button to perform its ui work.
    That same button on the other systems is instantaneous...

    @AndrianKnight said:

    the entire product is managed by 7-8 people.

    @JKay said:

    looking at the latest commits to github it shows 1 checkin in the last 8 days (25/08/16)

    I think that Xamarin should be honest and announce that they are phasing out the Xamarin.Forms platform. I don't think that the issue is about resources (they are Microsoft now, they have more resources than they can handle).

    I think that there is some deliberate choice to drop the XAML road. Maybe it is related to the fact that another markup format, SVG, is on the rise in the mobile world, I don't know.
    But we know that many popular industry standard UI design tools (Sketch, AdobeXD... even Photoshop now) are exporting layouts directly in SVG.
    XAML usage, on the other hand, continues to shrink, and it was never popular to begin with.

    So what is really happening? I suspect that Xamarin is going to announce a new SVG-based cross platform framework for UIs very soon. I see two element of evidence supporting this:

    1) The fact that they have silently shifted many human resources from Xamarin.Forms to a cross platform rendering library, a port/wrapper of the Skia google graphic library. ( ).

    2) The fact that Miguel recently announced that the above Skia-Sharp library is now being used to develop a new branch of the SVG library project, with the Skia-Sharp used as a new high performance rendering path ( ).

    While on one hand I think that this may be a good move for Xamarin, because all the industry is moving toward SVG as a common graphics device independent description format, I'm simply disappointed that considering the high price we pay for a Business (or higher) subscription, we are left in the cold with no warnings or clear explanations about the future of Xamarin.Forms. We all have Xamarin.Forms applications in development stuck somewhere along the road because of some many months (or even years) old bugs that probably will never be fixed, and with terrible performances that are degrading more and more at each release.

    Please, tell us what is going on. We love Xamarin, but this is gone too far.

  • GVxGVx USMember ✭✭✭

    Agreed. Am sick and tired of updates breaking already working code.

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    I already agreed to the first posting of @MarcusSchebesta

    Although I'm not sure, that SVG is the best/only way, there are interesting conclusions in your posting, that let hope, that something "bigger" is going on with .forms. I hope for a redesign of the XF-base, so that in the future, "stable" versions will be worth their name and we can start tor work productive on our app instead of testing every function on every platform in our app's, implement workarounds for new or evergreen bugs, create "minimal projects" and fill bugzilla bugs almost without any feedback for Xamarin after every update...


    It appears that Xamarin people are now working on getting Xamarin.Forms released on Mac, rather than sorting out existing issues. When will product managers get to make decisions about strategy, rather than techies creating new stuff because it's more fun than working on stability? I was hoping Microsoft would have sorted this by now.


    Agreed. Am sick and tired of updates breaking already working code.


  • NMackayNMackay GBInsider, University admin

    XAML usage, on the other hand, continues to shrink, and it was never popular to begin with.

    Ummm, that's not true.

  • rogiheerogihee NLMember ✭✭✭

    That said, I have been using Effects, DataTemplateSelector and Styles to great pleasure. They really are good additions to the ecosystem.

    I also see almost daily bug-fixes in the repo, although the pace is sometimes slow. I'm also a little surprised Jason Smith is not more active in the repo.

    @NMackay I might even consider using XAML again because of the live preview in Studio, I want to try that out again. That is potentially a huge time saver.

  • JohnHardmanJohnHardman GBUniversity admin

    I've not been using XAML so far, but am contemplating switching to using it. There are pros and cons - it's a finely balanced decision, but I think the pros will win out shortly.

  • MarcusSchebestaMarcusSchebesta USMember ✭✭
    edited September 2016

    Oh wow, I haven't checked this post after it left the first page and didn't expect so much resonance.
    Honestly, I may have approached it with the wrong expectation, my frustration with Forms stays however.

    I am quite happy to see that I am not the only one.

    I got some great opinions yesterday at a meetup here in germany.

    There even was a guy building quite complex Forms apps and was completely happy with it.
    Maybe I would have no problem at all, or at least less, if our main target wouldn't be UWP and kept with
    the better working Forms implementations on Android an IOS (which is what he did).

    But there were also quite a few that sold me on the idea of MvvmCross + Native UI, which I am actually currently porting our app too.

    I am not as convinced as some that Forms will be the goto with Xamarin in the future, but I will continue to watch closely.
    At the very least I still love the main idea behind Forms!

  • LGMaestrelliLGMaestrelli BRMember ✭✭✭

    We are spending more time looking for some workaround, trying to fix a XF bug, then coding our product...
    That is frustrating.

  • NMackayNMackay GBInsider, University admin

    I have to admit that UWP isn't great at the moment, we're only making progress with UWP as we're using Telerik custom controls for Listview etc, if we had to rely on the vanilla listview I'd be struggling. There are many issues in UWP, I'm hoping they will focus on UWP and Android performance issues (they need to).

    I think Forms has a strong long term future, I was at evolve 2014 where it was really just a concept and evolve 2016 where it had huge coverage, Xamarin university is moving to 60% focus on forms for certification. If they were going to let it fall into the background then I wouldn't expect to see it been pushed so much. There's also some cool features coming up for platform specifics that could really open up the potential of forms.

    I do share many of the frustrations mentioned above but I still believe Forms has a strong future, Microsoft just need to chuck more resource at it, money better spent rather than splurging 18 billion in linkedin imho :wink:

  • EmanueleSabettaEmanueleSabetta ITBeta ✭✭✭
    edited September 2016

    @void said:
    I'm being very productive with Forms. However, it took a while to get there. There was lessons to be learned. There was renderers to be built.

    This is important. Can you share some of your learned lessons? Posting some of your custom renderers code?
    I think that we, as users of Xamarin.Forms, are also partially responsible for the current dramatic situation. We are guilty of not sharing much of what we learn.

    For example a year ago two guys opened this wonderful site to share Xamarin.Forms snippets for custom renderers and workarounds:

    In a year only 7 snippets were posted. Just 7! Why? Why have we been so selfish?

    We should act more like a community and share the solutions that we found to our problems as we go. Especially because the problems we encounter developing a XF application are often the same ones, and if we had shared our findings, workarounds and lessons with each other since the beginning, we could have made XF issues, bugs and limitations much less of a problem.

    We need to help each other because Xamarin is not going to help us much. I'll start with posting some snippet with some tricks I found to use SVG in my apps. I'll post those on in the weekend. I hope that others like you will follow me in this mission.

  • voidvoid DKBeta ✭✭✭
    edited September 2016

    I don't do UWP. Yet. This opts for a smoother ride.

    I do XAML. I took the pill 5-6 months ago. I decided to convert a large Forms app in production to XAML. So much pain. So much frustration. The first month, I swear I could have lured Mr. Petzold into a dark alley and shown him an alternative purpose for his book.

    Now I'm a believer. Sorry Charles!

    The code is cleaner. MVVM manifests itself everywhere. So much that I've actually begun using Prism for Forms. And I'm enjoying the ride

  • ShantimohanElchuriShantimohanElchuri USMember ✭✭✭✭✭

    It all depends on if we can find solutions to our issues. But definitely the upgrades are not subjected to regression tests. There is something basically wrong with the upgrade methods.

    Even I am very much frustrated. I started a project after Evolve 2014, where the room overflowed for Jason's session on XF . I couldn't release it even after Evolve 2016, as I am engrossed in resolving the issues faced with each upgrade of XF.

    During Evolve 2014 I heard only 4 people were working on XF. Now I hear only 7 people are working on it. Adopting .NET, a mammoth, to 3 divergent environments is an Herculean task. How can this tiny team accomplish it? The idea of XF is like heavens on the earth as the Windows Mobile market is dwindling day by day.

    One more thing I noticed is that most of the complaints about XF are coming from VS users and very few from Mac users. Remember all developers in Xamarin use Macs. Is that a coincident?

    When XF Betas don't give so much trouble to install, then why the 'stable' version have these issues?

    All questions but no answers...

  • AdrianKnightAdrianKnight USMember ✭✭✭✭

    Even if you ditch XAML in favor of SVG, that still doesn't fix the vast majority of bugs on XF. Most issues are not related to XAML.

    I very much love XF, but like other people, bugs have been the worst part of the experience. I have 5 PRs sitting in the queue now. I'm hoping they will get merged to the master soon. Even this process can take as much as 2 months :( I wish things moved much faster. We just need to convince MS to dedicate more resources to XF otherwise there isn't much 7-8 people can do.

  • PhilipOGormanPhilipOGorman USMember ✭✭✭

    I came to forms with zero mobile experience nearly 2 years ago. I had many years of wpf and other software experience.
    Generally my experience has been very positive, we started out with two developers using forms and we had to put in a lot of effort in initially. We replied heavily on this forum and the generosity of the posters here - without this forum I don't think we could have made much progress.
    Now we have 6 devs/engineers putting out apps on all platforms. The sharing and reuse of code across the apps and platforms is huge. >Net is a great platform to write code on, I really feel that issues caused by Forms are balanced out by the productivity .Net gives us. We use the same libs and architecture on all apps and it means now that someone new can come on to the team and be productive very quickly.

    The frustrations have been:
    1) Very little documentation or examples on how to write custom renderers. Again this forum saved us many times. There needs to be a repos showing many examples of renderers on all the platforms
    2) UWP support is very bad.
    3) Updating to newer version of forms will normally cost you days. Once we have a app running we never update unless we absolutely have to.
    4) Performance on android is bad.

  • JohnHardmanJohnHardman GBUniversity admin


    One more thing I noticed is that most of the complaints about XF are coming from VS users and very few from Mac users. Remember all developers in Xamarin use Macs. Is that a coincident?

    I don't think that's a coincidence at all. More seriously, I think the strategy is being decided based on what those internal Xamarin developers enjoy rather than what the market wants, hence Xamarin.Forms for Mac being in the pipeline, whereas bug-fixing (particularly on Windows platforms) seems to barely be happening. I've raised yet another one today that appears on UWP and WinRT, the platforms that seem to get the least attention despite Windows being core to the vast majority of enterprises.

  • NMackayNMackay GBInsider, University admin


    Got support investing the UWP issue of modal pages and the soft bottom buttons on mobile devices, it seems to make a hash of calculating the page size whereas it handles normal navigation pages fine.

    UWP definitely needs more work, it still feels like it's a beta product.

  • TomSoderlingTomSoderling USUniversity ✭✭✭

    I agree. Technically, it's still in public preview, right? I haven't seen anything saying otherwise.

  • EmanueleSabettaEmanueleSabetta ITBeta ✭✭✭

    @PhilipOGorman said:
    Very little documentation or examples on how to write custom renderers. Again this forum saved us many times. There needs to be a repos showing many examples of renderers on all the platforms

    I agree. But we can as developers start sharing our custom renderers and create a knowledge base.
    I invite you to share your code on this web site:

  • MarcusSchebestaMarcusSchebesta USMember ✭✭

    I will post my renderers and a few other useful snippets there on Monday.

    In the mean time, I switched to MvvmCross and ported our app. It is beautiful :).
    What was a lot of backend mixed forms stuff and a UI tweaked with code behind and renderers to somewhat look nice on UWP is now a 100% portable and testable backend with a binding-only native UWP UI.
    Not a single line of platform specific code except for a few value converters and the same interface implementations as before (for stuff like file acess, serial port and so on).

    The UI is SO much more responsive, looks much nicer and this approach forced me to rework the backend into something truly portable. As much as I liked the idea of Forms, I believe this approach is much better - even if I have to redo the design for each platform.

  • ahmedkhanahmedkhan USUniversity ✭✭

    Having released a Xamarin.Forms app for iOS and Android for 2 months ago, I echo a lot of these frustrations - My biggest gripe these days with the latest release is the downgrade in Android performance. This is serious. I hope the Xamarin team can look at the performance issues occurring with the latest 2.3.2 release and work on them asap.

    I also really don't care much for getting Xamarin.Forms avaible for Mac OS, most of us use Xamarin for mobile development and iOS and Android Cross Platform app development is the bread and butter of Xamarin. If they don't address these issues, it risks making Xamarin Forms irrelevant.

  • RohitKadlagRohitKadlag USMember

    @DanielL: I am getting unhandled exception while calling imageservice.loadurl() in loop. Exception is not getting catch anywhere . App is getting crashed.I am using imageservice.loadurl().DownloadOnly() in loop.

  • NMackayNMackay GBInsider, University admin


    A quick observation but it has couple of drawbacks over Forms, it only supports iOS and Android and you have to define your UI layout in each platform specific project.

  • VictorMotchalineVictorMotchaline CAMember ✭✭

    Thank you for your feedback! Your observations are correct. Even though the code and layouts are almost identical for both platforms, I've never tried to build a unified abstraction there. The main idea of the framework was to build a tool that you can learn how to use once and then be able to apply everywhere (iOS and Android, for now) - "Learn once, code everywhere" principle, rather than "Code once, run everywhere". If you look deeper, you'll also find out that the framework doesn't strictly follow any standard architectural patterns (MVC, MVVM, etc.) but rather violate them in many places. The focus here is on simplifying the development of common tasks.

  • AnHundAnHund DKMember
    edited March 2017

    @NMackay said:
    XAML usage, on the other hand, continues to shrink, and it was never popular to begin with.

    Ummm, that's not true.

    I agree not true.

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    Your video looks really good - congrats... :sunglasses:
    I have downloaded the Android app to have a look in real life (unfortunately, I'm out of the "serving area" in Switzerland and therefore not able to search for data and see the app "working").
    Some notes to your framework...
    I don't know, what goal you have in mind with it...?
    If you want to "pick up" developers and sell it in the future, you have to do a lot more as simply paste a link to github and post a link to a video.
    As you know, it cost time to have a deeper look to new framework and it cost a lot of time to migrate an existing app to a new framework (no matter how easy the new framework is).
    So a lot of trust is needed, before a user will take this risk (at least in my case :wink: ).
    To reach this trust, you have to post, who you are, a documentation (how to work with the framework, short examples to the controls (button, listview, call of a webservice, access the camera and so on), how to migrate from .forms / iOS / Android to your framework. Especially you also have to show, that (and how) you are able to support the framework also in the future.
    Just a few tips from me...

  • VictorMotchalineVictorMotchaline CAMember ✭✭
    edited March 2017

    Thank you for playing with the app and with the framework. Please find below some of the answers to your questions:

    1. You can enter "500 Robson" or any other address in downtown Vancouver to see the actual restaurant results in the app.

    2. Fusion framework is open-sourced under Apache 2.0 license. Basically, it is free (so there is not much you can sell :) ) I built the framework to solve my own problems with efficient app development. I put it on github in hope that it may help other developers as well.

    3. There are a number of examples under the correspondent folders (iOS/Examples, Android/Examples) that show some basic principles of working with the framework.

    4. The framework is in mature state and I actively use it for my own app development projects. However, it really lacks the Documentation and currently I don't have much time to work on it. This is big a RED flag for the "trust issue" that you mentioned, but this is a reality and there is not much I can do about it at this time. On the bright side, everyone is welcome to help.

    Thank You,

  • FredyWengerFredyWenger CHInsider ✭✭✭✭✭

    Thanks for your feedback and the hint for the search...
    Now, I can see the app "at work" and... it work's... nice :blush:

  • @MarcusSchebesta

    I'm a junior dev and this was my first time using Xamarin, so I thought it was my fault, but it looks like there are tons of experienced developers with the same problems. I updated Xamarin.Forms today, and of course stuff broke. I'm going native for my next apps. Learning Swift would have taken less time than dealing with this stuff.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @EricGrahamMacEachern I'm sorry to inform you that coding in Swift isn't much easier than working with Xamarin - it's just difficult in different ways. This is in part due to the toolchain (Xcode has some, ahem, idiosyncrasies) and partly due to the continuous evolution of the Swift language itself. I know of many Swift developers who have just recently been forced to upgrade their apps from Swift 2 to Swift 3 and the conversion was not completely automatic. Some multi-thousand line apps had to be edited and fixed by hand. Now Swift 4 is on the horizon and it doesn't look like it will be convertible automatically either. At least with C# you have strong backward compatibility so your old code doesn't break just because you're recompiling it in a modern compiler. Plus (IMO the killer feature) you have strong async support. And events. There ain't nothin' like them in Swift.

    I share your frustrations at some of the things we have to put up with when using Xamarin. But you should be aware that the grass isn't all that much greener on the other side of the fence. :smile:

  • @DavidDancy

    Okay, but what about Objective C? That's more mature right?

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @EricGrahamMacEachern true, it is. It's also being actively deprecated in favour of Swift, although I doubt it will ever completely go away, just because of the millions of lines of code that are already written in it. So if your Obj-C-foo is strong, you'll enjoy it.

    I started out in ObjC though and now that I know C# I find I would be very reluctant to go back to ObjC. If you can get your head around the constant need for callbacks (and the massively indented block structures that you get as a result) you'll be doing much better than I did. I always had trouble with mentally matching up the call with the callback, especially where either the call or the callback (or heaven forfend, both) required lots of processing logic. Huge classes, fragmented flow of control, and general terror at the here-be-dragons whenever I entered the dungeon to do some editing.

    Contrast that with C# and async / await. The difference in readability, in my capacity to reason about the logic of a class and the flow of data through it, is quite dramatic. Perhaps you're better at the callback dance than I am (I wouldn't be surprised!) but for me async / await on their own outweigh all the other pain that might accrue from the, ahem, idiosyncrasis of the Xamarin ecosystem.

    Don't let me stop you if you're determined. :smile: I acknowledge that there are many problems - some of them quite serious - in the Xamarin offering, and Xamarin Forms in particular is far from perfect. But I think it would be naive to expect that all is sweetness and roses in the Swift/Xcode camp by contrast. Every time I get frustrated with Xamarin and think about a divorce I look at what's going on in the other families and find they have an equivalent-but-different set of issues to deal with.

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭
    Of course, there's an intermediate option of moving to Xamarin.iOS and Xamarin.Android.

    Keeps the Xamarin C# advantages without the Forms problems.
Sign In or Register to comment.