There is no denying that Xamarin.Forms, has gained incredible popularity over the last few years. You only need to look to at the Forums, blog posts or most newly started projects to see Xamarin.Forms is preferred. It’s had a rough start, and unfortunately, that rough start has left a stain on earlier developers’ perception of Xamarin.Forms, and it is taking a long time to rub clean.
Xamarin.Forms came out to a “stable” release in May 2014. (Stable is purposely air quoted there). After developing a small Objective-C app just after that time, while I was crying, huddled in a corner, I was searching for an alternative, and being a C# developer, having a XAML based UI, and C# back end seemed like a savior. Having access to all the native API’s, was even better, meaning I wasn’t going to be surprised with limitations on its functionality. But the fun was just about to start. This was a time when I had to use DotPeek to see what was happening under the hood, as it was not open source, it was not widely used and it’s allocated resources at Xamarin were small.
Too Buggy Myth
In the first year especially, over 30% of my working time, was tracking and working around bugs. There was no escape. Painfully obvious, easy to reproduce bugs in Xamarin.Forms, causing minor issues to complete crashes. I never did get around to filing all that I found, but I certainly filed a lot. Though I kept at it, because strangely enough I found it to be the most frustrating fun I have had in a long time. Oh, and the memory leaks, they were difficult to track and particularly painful. You really had to be committed to developing in this platform.
The bugs over time have reduced. There are still new ones introduced, and sometimes regressions appear. But this is generally around new features of Xamarin.Forms, and I rarely come across bugs these days, unless playing with nightly builds or pre-releases.
It started out as truth, but now it’s not. In the first few years, performance was a large issue. ListView’s were obviously jumpy under small loads, and boot times were also an issue. But that has changed considerably over the last year and even more so in the last few months. ListView’s with cell recycling are now smooth and boot times very much acceptable. Looking at a Xamarin.Forms app and Traditional Xamarin app, I don’t notice any performance issues.
What I do tend to see though, is developer’s put large amounts of initialization code on startup, or in the UI thread, which would make any app slow. Then Google to find the cause, see people previously complaining about Xamarin Form’s performance, then just assume it’s Xamarin’s fault. It’s why I dislike seeing performance touted as such an enormous issue. I released acceptable app’s years ago under Xamarin.Forms, and today’s Xamarin.Forms is far better, so why is it being treated that Xamarin.Forms is slow and clunky? Even Xamarin.Forms animation framework can churn out some buttery smooth animations on low end devices.
I understand it’s never going to be as fast as traditional, but the difference is unnoticeably small in all apps I create today? Is there some large performance issue I haven’t come across in 3 years?
Native Look And Feel Myth
Considering Xamarin.Forms uses the native controls for each platform, I do tend to wonder what people are thinking when they refer to this. I assume it means that navigation or other native gestures aren’t as well supported on a cross-platform application. And this is certainly true. But the majority of the app can look native on each platform, using the same UI code. The only recommendation I would make here, is to remove the native Toolbar and build your own. It’s far too hard to configure for cross-platform, in my opinion. Then add or disable gestures on each platform as appropriate.
I have seen developer’s complain it takes too long to write custom renderers to make tiny modifications to the UI. Yes, it is disproportionately a lot of time for the result, but didn’t you just save days or more of time only having to write the UI once?
Only for Line Of Business Apps Myth
This was actually started by Xamarin, though while I can not confirm this, I am pretty sure they only mentioned this after people started pushing the boundaries of Xamarin.Forms. In the early days, due to such a limited feature set and bad performance, I think it was easier for Xamarin to say, it’s only meant for Line of Business Apps, than to try and address the incredible amount of issues and insults being flung their way. It sometimes got a little nasty back then, and I always did think Xamarin got unfairly treated in a lot of exchanges. But I had issues, and I was only developing Line of Business applications, so the defense didn’t really hold up.
Thankfully, they now publicly state, it’s not just for Line of Business Apps anymore, coming directly from Miguel’s mouth. If you hear this myth around, don’t buy into it. Xamarin.Forms has expanded into almost everything, including HoloLens and games. It is no longer just for Line of Business Apps.
Should I Still Develop Traditional Xamarin Apps?
If you have a large investment in existing Native Xamarin Apps, there is no ROI, in converting them to Xamarin.Forms, unless you are about to do an extremely large UI upgrade. Hence existing Native Xamarin Apps, should still be developed as native. But, if you are starting a new Xamarin app, then Xamarin.Forms is the way to go. I have heard developers continue to go with Native, with reasons such as, I want a native UI look, specific to each platform and better performance. But honestly, I don’t see that as a deterrent to Xamarin.Forms anymore. It’s easy enough to convert any specific aspects to get a solid native UI/UX on each platform, and the performance is rarely an issue anymore.
Some developers are still going back to native, or not moving to Forms. It’s up to them, though to me it seems as though its personal preference. As much as I was just staying in ASP.NET WebForms, instead of moving to MVC, even though I knew it was the future, well now it’s not. AngularJS, or React, or flavor of the month JS framework. But my point is, because it was far quicker for me to develop in ASP.NET WebForms, because I knew it so well, I stuck with it. But I have never met someone who started in Xamarin.Forms, then chose to go to Native.
(Side note: I did eventually move on to MVC, then to AngularJS. Couldn’t live in denial forever.)
Xamarin.Forms is not perfect, never will be, but the benefits of Xamarin.Forms are now extensive. Most of the performance and bug’s are ghosts of the past, providing little relevance to today, but still haunting developer’s minds. Xamarin.Forms, will always have a slight performance lag over native, and when I mean slight, I’m mostly talking millisecond’s and indistinguishable to the human eye. However, milliseconds add up in items such as ListViews, and native gestures in platforms can cause issues. But with foresight, they can be easily accommodated.
With Xamarin.Forms, continuing to add greater platform support, I fail to see how developers will want to write a native UI in every platform and then just share the backend code. Xamarin.Forms is going to support a lot of platforms soon, including WPF, GTK#, macOS, Tizen just to name a few. At this point I honestly think Traditional Xamarin is going the way of WinForms. It will always be around in old projects that never seem to go away, but the future lies with Xamarin.Forms.
Xamarin.Forms has now moved into so many things. Its also gone full circle and is coming back to infiltrate Traditional Xamarin, with Embedding. As my final thought, I just want to thank the whole Xamarin team for getting this far. It’s been a long and sometimes painful journey, but I bizarrely look back over it fondly, and appreciate what all this effort and dedication has brought to the .NET community. I look forward to the next 3 years.