Xamarin.Forms is a one of the most loved and simultaneously most dreaded frameworks to work with . Having being a full time Xamarin.Forms developer for over 4 years now (I still am), I feel as though I have a good grasp on the good and the bad.
In 2014, Xamarin.Forms, I personally think was the best cross platform framework on the market. Native controls were all the rage, and while it was extremely buggy, it allowed cross platform development in C# with a write once, use on each platform UI. But times are changing. Native Xamarin is holding up Xamarin.Forms now. The benefit of reusable business logic across platforms and native API access in C# are great benefits, and they are still strong. Xamarin.Forms leverages that, but isn’t providing the efficiency it used to.
Best described in a picture, at a very simple level, this is why Xamarin.Forms always seems so hard for beginners, and why Flutter seems so easy. I’ve chosen to compare with Flutter because I have the most experience with that framework outside of Xamarin.Forms. But it equally applies to other similar frameworks.
Not only do you have more parts to remember, you have two-way communication to deal with as well.
Binding / Renderers
How many crash reports do you get from renderers per week or day? It’s a problem that has never gone away. You can almost always put it down to a binding and renderer issue.
Binding causes issues because its a two way state flow, made from the stuff of nightmares.
Any one of those objects goes out of sync or receives competing events from either direction, things can go wrong. Object Disposed Errors, properties not updated correctly. You have to manage all of that. This is the main reason Xamarin.Forms has always been so buggy, in my opinion.
An immutable UI solves a majority of these issues, and after looking at how Flutter does it, Frank created a demo of how ImmutableUI would work in Xamarin.Forms. But this creates a shadow UI of a shadow UI and isn’t an ideal solution, because all the other layers still exist.
A true immutable UI, only gets created then sent down to a renderer to create. Only emulated controls, not native controls can really achieve this properly.
UI in C#
I understand this point will be something of contention. Doing a UI in XAML seems like a great way to separate the UI from your code and business logic. Its a language that is also built for describing a UI, hence it seems like a perfect fit.
If you have the scenario where a UI designer does XAML for you then you just wire it up, maybe this would be a great approach, but as a developer who normally has to write the UI and ViewModel, I’m slowly realizing the lack of any benefits.
If I was coding my UI in C#, I wouldn’t be mixing in business logic with UI logic, they would still be separated. It would allow be do write a NotConverter with an ! instead. When you think of the behaviors and converters you have to write to do basic things in XAML, why don’t we just use C#? I can still see the UI just as well in C# as I can in XAML.
You can use this great library CSharpForMarkup to help. Take a look at the examples, it shows you how similar they are when reading them. But without it being in the core framework, I doubt it will get much mainstream attraction. Hence due to binding alone, XAML seems preferable at this time.
Live Reload was Xamarin.Form’s Hot Reload functionality. Microsoft developed it, put it out there, then said they are not going to support or maintain it anymore. Their position could change in the future, but as of today, it is where it stands. Instead they are going to work on the previewer. For me, its an obviously wrong allocation of resources, simply put:
- Previewer = How we think your app might look
- Live Reload = How your app actually looks
Why do we want a previewer? I don’t know, and couldn’t find anyone else who wanted one either.
Uno to Flutter Spectrum
Xamarin.Forms sits in an interesting middle ground, between what UWP/WPF developers want and what people who would likely enjoy using Flutter would want.
Uno provides a lot of what WPF/UWP developers want. The original and powerful XAML with Edit and Continue functionality. The ability to use Blend to generate UIs to pass in.
Flutter provides a lean, simpler way to create cross platform apps with an exact UI between each platform. Just learn Dart (which is easy to pick up if you know C#, they are similar) and the SDK calls to make, and you are good to go, with things like Hot Reload built right in. It’s a very fast and tight developer feedback loop.
I think Xamarin.Forms will lose in the long run, if they try to cater to both sides, and in the end, serve none effectively.
Native Control vs Emulated Controls
Over the years, many frameworks have come and gone, where they emulated controls. They were normally met with numerous limitations and eventually died out as nothing compared to the Native Control experience.
Several people have mentioned that Flutter seems like a Flex and ActionScript and use that as a comparison to Flutter. But they are some differences this time. Flex was primarily drawing inside a browser. But a browser had HTML. While browsers would display things differently, it was manageable, if not frustrating. While web browsers are still far from perfect, they have reached an acceptable level of similarity. Hence Flex and Flash didn’t much of an advantage. They had to outrun the browsers, and it was an additional plugin to an app.
Xamarin.Forms, Flutter, React Native, Ionic, all run on multiple platforms, where defining things such as a button isn’t the same. You have to code that 2, 3 or more times for each platform. Cross platform frameworks help ease that burden, and developers are aware and accepting of their limitations, in exchange for the speed.
However, some frameworks like Xamarin.Forms went Native, others went Emulated. The last time my client cared for a native control was in 2015. After that I was mostly guided by UI designers who didn’t care, and now has gotten to the point where I have to spend time erasing the native look and feel from my apps. Its an industry trend though. Look at Facebook, Instagram etc. They all look almost identical on every platform.
With this in mind, and with what many other developers mention to me (realizing this is not everyone), emulated controls are preferred, to enable the same look cross-platform, with the option to bring in a native control if needed. Such as the option that Flutter takes, with its PlatformView.
Shell, while an interesting concept, seems to be a response to Flutter. It allows you to create a shell that styles elements identically on each platform. It doesn’t alleviate the Renderer problems, and is another set of Elements on top the existing ones that you have to learn.
It does help alleviate some issues, but it doesn’t solve underlying problems.
You can see that Xamarin.Forms is in a tough predicament. What would I do with infinite resources and complete control over the guidance of Xamarin.Forms?
- Strip Xamarin.Forms down to its core. This means removing binding, XAML and renderers, and just leave the Elements and Layout system as the core part of the framework.
- Create a package, that contains renderers, XAML and binding’s. This will allow people to continue on their current path.
- Create a package, that contains a single Skia based renderer, with an immutable UI type of development.
It still serves both markets, with different branches off the Core framework, with the possibility of additional packages that leverage native controls that could benefit both paths.
What do I think will likely happen in the long run with Xamarin.Forms? It will probably continue in a similar direction, make minor changes, while forever asking for feedback they can never action, and eventually be relegated to WinForms status. An old platform that’s not really updated anymore, and only those with large investments in it, keep using it, or developers who find it really hard to move on.
I honestly don’t think many (or any) of these changes will actually be made. I’ve said them multiple times before, and they continue to not be heard. I had great hopes for Xamarin.Forms, but unfortunately I no longer believe they are heading in the right direction, for where this platform needs to be in 5 years time.
If Xamarin.Forms continues in this direction, I see they will most likely still be around, just used mainly by companies that already adopted or invested in Xamarin.Forms, I can’t see it as a preferred platform for new projects for much longer.
So why I am saying this? Several reasons. I have always supported Xamarin.Forms, but it is becoming increasingly hard to, and I wanted to let people know why I have seemingly dropped off the Xamarin scene online. I also want to stop repeating myself, as I repeat various parts of this, in private messages or channels and maybe to say I told you so in 5 years time 🙂
I am currently working on Flutter for Xamarin, if you are interested in seeing where that is heading. Being able to run Flutter in Xamarin (.NET) and code your Flutter apps in C# and F#.
References Stack Overflow Developer Survey 2018