Is Xamarin Forms a Bug?

A few days ago, when trying to find a workaround for a bug in Xamarin Forms that causes the height of updated list rows to be wrong, I remembered this epic rant written by andre_ss6 in the official forums of Xamarin:

I’m really sorry for the language, but this software is simply and literally the worst mega f***ing shit I’ve ever used in my life. This halfass piece of garbage only serves to waste people time. And IKR, how could people pay for this, ffs?!

COULD you PLEASE go back to sanity and stop bringing more features to that horrible vomit-inducing frankenstein’s creature which is Xamarin.Forms and instead focus on stabilizing Xamarin.Android and Xamarin.iOS? PLEASE. PLEASE.

For christ sake, I can’t even build my projects properly. I have a project that I have to LITERALLY hit build several times in order for it to build, because sometimes Xamarin just decides it’s not in the mood to work. It just says “Build Failed” with no error message whatsoever. Just “Build Failed”. Why not “Build Failed, please try again later. Thank you.”? F*** you. Seriously.

Are all of you out of your right minds? You certainly do use this piece of **** you call a software so you do know what complete horror this spectacle of fecal waste you call software is. So either you’re a sadist f*** who like to watch developers waste their companies’ resources trying to use your ****** framework or you’re just the most incompetent people on the entirety of this f***ing universe.

I’ve already set Xamarin.Forms on fire because… well, because death seems a better option than using it.

I was expecting that I would have a decent experience with Xamarin.Android at least. It certainly is bearable. In fact, this is the closest thing to a real software I’ve seen so far in the Xamarin world. However, it is still ***. Projects build only when they want. Designers freezes all the time. **** support for AppCompat. WORST THAN **** support for ConstraintLayout. EVEN THE SAMPLES WON’T BUILD PROPERLY SOMETIMES. JESUS CHRIST, PLEASE DO YOU EVEN TEST YOUR SOFTWARE?????????? HELLO??

Xamarin is already the second most dreaded technology among developers according to the SO Developer Survey. Anywhere you go on the f***ing internet people will tell you to stay away from it.

This is especially sad for me because I just LOVE C#. I love it. I want so much to just use it for our mobile projects but it seems F***ING IMPOSSIBLE. I’D RATHER DEAL WITH JAVA AND ORACLE AND CALLBACK HELL AND ALL THAT **** A BILLION TIMES THAN LOOK AT XAMARIN EVER AGAIN.

SO TO ANYONE OUT THERE WHO, LIKE ME, THOUGHT “HEY, IT CAN’T BE THAT BAD, CAN IT? I’LL JUST SPEND A FEW HOURS, MAYBE A DAY SETTING THINGS UP BUT IT WILL PAY FOR ITSELF”. NO. GO BACK. IT WON’T PAY. IT’LL NEVER PAY. IN FACT, IF YOUR DREAM IS TO WORK AT MICROSOFT THEN MAYBE YOU SHOULD STICK TO XAMARIN. BECAUSE YOU’LL FEEL LIKE YOU’RE FIXING XAMARIN’S BUGS, NOT YOURS. IN FACT, SOMETIMES YOU’LL EVEN FORGET ABOUT YOUR PROJECT. YOU’LL BE JUST LIKE “WTF IS THIS PROJECT DOING HERE? OH, IT’S MINE”, BECAUSE YOU’LL BE SO INTO XAMARIN BUGS. YOU’LL START THINKING ABOUT GOING TO GITHUB AND FIX XAMARIN INSTEAD OF YOUR OWN CODE (SERIOUSLY). THIS IS A DISEASE. DO NOT GO ANY FURTHER. YOU’VE BEEN WARNED.

It definitely looks like our friend Andre went a little bit overboard on this, but how far is he actually from the truth? I have been using both Xamarin and Xamarin Forms for a while now, and I can confirm that when it comes to the latter one, the struggle is very real.

The theoretical concept behind Xamarin Forms is great: you only have to write the code of your application once, including the views, and the complicated system of pulleys and levers of the framework will use its magic to take care of rendering all the layouts and making the app work on each platform. Creating views is unbelievable easy and intuitive, and many other tasks, such as defining lists and making them work, are also a piece of cake. Besides, you have all the beauty and power of C# and MVVM. Then, what’s not to love?

Well, turns out that Xamarin Forms is one of those things that are just better in theory than in practice. When you actually attempt to use it for anything remotely more complex than the official examples, everything seems to fall apart and all kind of bugs come out from their hideouts to chase your app down.

Things that work on one platform but not on another

One of the very first problems I encountered when I was starting with Xamarin Forms was that the property CornerRadius of the Frame element, which I needed working on Android, iOS and UWP, would only work on Android. Why did they bother to include this property if it didn’t even work in most of the supported platforms? Why wasn’t there a remark about this lack of functionality in the official documentation?

I didn’t have the time to look for the answer to those questions; I just needed a solution for my problem. And it didn’t take me too long to find it, as apparently this was a very common problem that could be fixed by extending the Frame element with new properties and adding custom renderers for Android, iOS and UWP. All of this just to display a round corner!

Having to do all these magic tricks in order to get a very basic piece of functionality that should already be implemented inside Xamarin Forms is ridiculous, but with Xamarin Forms this happens so often that you eventually accept it as a the standard routine.

Renderers every-where

One of the main points of Xamarin Forms is that you can develop faster – after all, having to write your views only once for all your platforms should speed things up. Despite that, anyone that has tried it long enough knows that there is always something in the way between you and a fast development process: custom renderers.

As shown in the previous section, more often than not, the view or control that you have created won’t look or behave as expected, so you will have no other option than to write a custom renderer for one or several platforms. This will not only slow you down, but it also dismisses another strong point of the framework: Xamarin Forms is supposed to allow you to develop mobile applications without having to know how to develop for the platforms you are targeting.

Performance issues on Android

I understand that applications developed using Xamarin Forms cannot be as fast as native ones because of the nature of this framework, but I would at least hope to see a semi-decent performance. Unfortunately, Xamarin Forms seems to create Android applications that are extremely slow, specially if you are using multiple renderers and customised controls.

While is true that in Xamarin Forms they seem to be doing great efforts to improve app performance – they have created techniques for layout compression (which I tried to use until I eventually gave up on them, as they would break my layouts), techniques for layout compilation, fast renderers, etc – it still feels like their efforts are not improving the situation enough.

On this regard, I have recently managed to improve the performance of one of the apps I was working on greatly by replacing some of the renderers with Skia code, which is something I might talk about in another blog post. However, at some point after drawing everything manually against the canvas in some of the controls, I wondered whether I should just ditch Xamarin Forms altogether and switch to Flutter, which actually applies the idea of using Skia for absolutely everything. If only it were compatible with C#…

Bugs, bugs, bugs

Even though there are many things that should improve on this framework – I have already mentioned a few –, the main problem of Xamarin Forms is that it is absurdly full of bugs. Every day in which I have to work with Xamarin Forms, I always remember to warm up and put my boxing gloves on before I open Visual Studio, because developing with Xamarin Forms means getting into a fight with it, and it is an exhausting one. We all know that all platforms and frameworks have bugs, but Xamarin Forms is just on another level.

One would expect the most fundamental features to function well – after all, this framework has been around for a while and is currently about to get to the version 4.0. For example, one would think that the very important task of displaying items in a list would work perfectly and flawlessly, right? Wrong.

I have had countless issues when trying to use lists in very basic ways, and don’t even get me started on grouped lists. In fact, the very reason why I decided to write this post is because I found that all the lists in the app I am currently working on started misbehaving on iOS after upgrading Xamarin Forms.

The bug fixes are also bugs

The thing is that the kind of issue I faced the other day is not at all uncommon. In fact, if updating any kind of dependency is always a risk, when it comes to Xamarin Forms it usually leads to a major disaster. Honestly, it feels like each new release brings in more new bugs than bug fixes.

I don’t know how their development cycle works, but it looks like they keep on adding new stuff without fixing what is already broken. Or even worse, adding new stuff and then breaking was was previously working. In fact, it is very common to see blocking issues that remain unresolved for years, even though they were initially reported a long time ago and have been discussed by many frustrated users since. Besides, it is also very usual to see bugs that are reportedly fixed and yet still occur in one way or another.

In my opinion, in Xamarin Forms they should probably slow down for a second and focus very hard on fixing the existing bugs properly so we can finally start being productive with their framework.

“Code quality? Never heard of it”

In a way, I guess it all comes down to quality control; or a lack thereof. For example, just today, when looking at the source code to try to understand the reasons why the issue I was trying to solve was occurring, I could see that there were several recent commits trying to tackle the same thing, and the problem was that each one of those commits seemed to try to implement the solution in a completely different way, changing or removing most of the code from the previous implementations.

As you would expect, the final result was a messy file (with inconsistencies in the code style and indentation problems) in which you could even read comments referencing methods and properties that didn’t exist anymore.

That is, instead of implementing a well-tested, well-thought solution once, they seemed to be implementing quick, low quality fixes that would need to be replaced again later. The worst part is that somehow all of that messy code passed their quality control and made it into the repository, which sadly explains a lot.

The internal hell

By now, I think it is already clear that there are many problems enclosed inside the code of Xamarin Forms, but at least all that code is publicly available, and that’s great. However, it isn’t as great as it might seem, because you can look, but you cannot touch.

Of course, I am not saying that you cannot contribute to the repository. What I am saying is that even if you spot a problem inside it, in most cases it will be impossible for you to implement a fix for the bug in your project because almost all the methods, properties and classes used by this framework are declared as internal, which means that you cannot access them or extend them. In fact, in some cases I have had no other option but to copy four or five massive files from their repository to my project just to be able to add a tiny line of code with my fix.

I could keep going, but I think that at this point you already get my message.

And yes, I know that this all looks like a massive rant, and it is, but if I complain is because I care. Because I actually love Xamarin Forms as much as I hate the frustration of working with it. Because I enjoy it a lot when it actually works properly, even though that doesn’t happen too often.

Unfortunately, as of right now, I really think that many, many things have to change if in Microsoft they want to keep the Xamarin Forms boat afloat and going. Because after encountering so many problems and bugs on daily basis, one cannot but ask himself: Is Xamarin Forms just a huge bug?