Saving Xamarin.Forms

Xamarin.Forms is a one of the most loved and simultaneously most dreaded frameworks to work with [1]. 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.

Cognitive Load

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.

Immutable UI

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

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

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.

Saving Xamarin.Forms

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?

  1. 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.
  2. Create a package, that contains renderers, XAML and binding’s. This will allow people to continue on their current path.
  3. 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.

Final Thoughts

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#.

Image result for mic drop

References

[1] Stack Overflow Developer Survey 2018


XAMARIN WEEKLY NEWSLETTER

Subscribe to a hand-picked round up of the best Xamarin development links every week. Published every Friday. Free.

Signup to Weekly Xamarin

* I do not maintain or run this newsletter, but I do recommend it.

Related Posts

Microsoft MVP | Xamarin MVP | Xamarin Forms Developer | Build Flutter

6 Comments

  1. Aritra Das

    This is so apt, especially the live reload vs previewer portion. I don’t understand why won’t MS listen to the community, and with Flutter’s direct draw approach along with Google backing it up, there’s a chance that Xamarin might end up having the similar kind of story as Windows phone.

  2. Aleksandr Smyk

    I think this post is also good for Xamarin. Flutter will be a good competitor for Xamarin and I would like to see Microsoft investments into Xamarin development in future based on the increasing of Flutter popularity. So it seems we can see the beginning of clear competition between two good implementations of the same great idea!

  3. John Bell

    An interesting perspective and I agree the while Live Reload thing is a shambles. No available ‘solutions’ work particularly well and this slows down dev time so much.

    For me the biggest problem I have at the moment is the performance, both during the developers inner loop and the resulting apps runtime performance. The devs inner loop is so slow and unreliable (how many times have you cleaned your obj/bin folder this week?) and we’re always fighting boot and rendering performance, particularly on android.

    Microsoft have done a lot of work to try and improve this but we don’t see big gains. I like xamarin but I’m becoming more frustrated with it, and like you starting to wonder about the direction, there’s just too much pain, making it a frustrating framework to work with.

    I’ve not looked at Flutter in anger yet but you’ve inspired me to do so.

  4. Sabir

    Totally agree with this post.
    Xamarin will never address the main concerns about developers.
    You have to write a lot of code to do simple tasks.
    Even though I come from UWP/ Xamarin background, I’m experimenting with React and will soon consider Flutter too.
    React Native is also gaining momentum will have to see how it compares to Flutter in the long run.
    But yeah can say for sure that Xamarin is out of the race, it’ll always stay but become irrelevant soon. I would like to thank the Xamarin team for all their awesome efforts though, but its time to move on.

  5. Shimmy Weitzhandler

    Agree with much of what was said here.
    Anyway my issue with Flutter and why and I can’t get anywhere close to it, is its lack of Windows and web support.

    I do like XAML (I do agree converters and behaviors are not the best), but more than I like XAML, I like the way the UWP control set is structured, and it’s a shame Xamarin.Forms tried to ‘out-smart’ it.
    For now I left Xamarin.Forms for the sake of the Uno Platform, and I’m satisfied. Uno is a bit too fresh but the guys there are listening and constantly improving.
    An alternative solution to XAML (such that defines the UI by C#), wouldn’t be a world-war to create, on top of what we have. Again, I have no experience with Flutter.
    With Uno I have Android, iOS, Windows and Web support right from my clean UWP XAML.
    Maybe you can convince the guys at Google to have Flutter support Windows and WASM.

    Thanks for sharing Adam!