Stella Delaney
Nov 24, 2018 · 8 min read

Having read your article on ‘Flutter’ Vs ‘Xamarin’ comparison — I felt compelled to respond and dispel many of the inaccuracies that you have raised in your comparison. It would be great to understand how much development experience you have had in both technologies as reading things like ‘Flutter code reuse — upto 70%’ is just not true (Its much much higher!).

To begin with and for the record — I have developed Xamarin apps since early 2013 (Xamarin.Android and Xamarin.iOS) and from 2014 I spent 100% of my time in Xamarin Forms.

Amongst other technologies & for what its worth, I have been a Xamarin Certified developer . I mention have because I haven’t maintained my certification status as I felt the requirements to maintain certification were a complete mockery of the exam and took away any status that this once had ; The criteria for continuing to be Xamarin certified is to pay your monthly subscription to Xamarin/Microsoft and watch ‘x’ number of videos or take part in watching an instructor talk about something new in the Xamarin stack space. You don’t have to take any further exams, you don’t even have to participate in the class room lectures (these are all via the web), you just need to be marked as attended!

Most of the apps that I developed were enterprise apps (investment banking apps that rendered trading data using lots of fancy graphs, generating dynamic PDF, EXCEL and Word documents on the fly allowing these to be pushed remotely to one or more traders.)

I have integrated Azure services completely within my apps including storage, functions, B2C, push notifications etc.

The size of my biggest app was around 65,000 lines of C# code. This comprised roughly 18 projects and was written purely in Xamarin forms. I used a mixture of effects, renderers and native embedding to accomplish fancy platform specific features targetting iOS, Android, UWP.

My build times on a MBP with 16GB of ram grew exponentially to over 18 mins. In the early days of Xamarin (2016), build times were pretty pathetic — sometimes reaching 30 mins for just a single line change. Obviously this was to do with the many bugs and broken components that make up the Xamarin build process.

I then upgraded to a iMAC pro with 10 cores, 128 GB ram — build times were around 2.5 mins on iOS but still around 6 mins on Android. Admittedly the issue on the Android side was because of a Xamarin regression issue on the build side for android whereby any single line change resulted in the entire app being rebuilt (18 projects, 65,000 lines you can imagined how painful this was).

I believe I became very proficient in crafting multi platform apps using XF, prism, syncfusion and a bunch of nugets. My design was pure MVVM with little or no code behind. All my views were crafted 100% in XAML averaging around 200 lines and more complex views around 2–3000 lines.

The only codebehind I had was when I was doing fancy animation.

Zero view logic was coded in my VM’s. Dialog’s were abstracted into services as well as navigation which made them easily testable and mockable.

Xamarin makes it really easy to tailor the bootstrap process for either Android or iOS. Much in the same way how there are separate folders in flutter for iOS/Android to fine tune platform specifics — Xamarin allows the same with platform specific projects allowing appDelegate or MainActivity to be customised with the major difference being you can write in standard C# code. In the case of iOS this makes showing a dummy controller (Could be a simple loading screen or splash screen) really easy when your bootstrapping process will take more then 18 seconds allowing the real work to be threading which on completion will link back into App.xaml.cs and show the real start up page.

DI was easy as I used Unity. My main App.xaml.cs class set up all of the relevant plumbing for all required services and constructor injection was seamless.

My views and associated view models were bound with a single line of xaml code ‘prism;ViewModelLocator.AutowireViewModel=true’ and because of the way I set up DI in my App.xaml.cs, all services that the VM bound to the view required were also brought in on its instantiation — nice and simple.

So , what am i doing now — one might ask ?

I have switched to Flutter. Even though I was a very talented and experienced C# developer with many years C# and Xamarin behind me — the pain of using Xamarin on a daily basis was just not worth it. I was close to releasing an app to the app stores which was almost 2 years development but have thrown in the towel because of the numerous bugs that come with the Xamarin platform every time one upgrades to the latest XF nugget (I stopped at XF 3.1).

Together with the ridiculous build times, inconsistent non-stable environment, very large APK/IPA file sizes and more importantly the lack of vision/future roadmap of Xamarin (they are constantly playing catchup hence their latest offering Xamarin ‘Shell’), I’ve decided enough is enough and moved over to a much better, fluid, consistent platform — Flutter.

My pain list :

  • Ridiculous build times. This is even more painful when you try and build to a physical device.
  • No consistent working equivalent of hot reload (Yes you may have 3rd party tools like Gorilla Player, LiveXAML etc — but these dont work properly especially on a project of my size — to get a view to refresh after a XAML change, you need to generally close the view or navigate away and then navigate back in to the view to see the changes). Furthermore — there is no true CODE HOT reload, i.e when you make changes to C# code in the same way one can make changes to DART code — your view is not reloaded.
  • To aid with XAML view construction — Xamarin has brought out multiple technologies Forms Previewer, Live Reload etc and for this to work on the most simplest of applications (no complex DI, no dynamic view rendering, no complex Prism or 3rd party components — if you use Syncfusion , just forget it!) — you need to parcel up all your nugets and component dependencies and deploy this onto a physical device or emulator. Every new component that you add, you need to go through the same painful deployment process (takes ages to deploy an app especially one of my size). Furthermore complicated apps that make use of many nugets simply do not work with Live Reload , the whole process is not seamless when compared with Flutter Hot Restart/Reload.
  • No proper intellisense for XAML. For many years from 2014 until early 2017 there was zero intellisense when crafting UI’s via XAML. Imagine trying to write complex XAML UI’s by hand without proper tooling support. Again one had to find 3rd party solutions, VS 2018 finally provided intellisense but it still wasn’t 100% working or fully supported the entire list of XAML tags, I ended up going with R#.
  • Very large APK or IPA size. This article states that the binary size for Xamarin is ‘relatively small and for Flutter ‘relatively big’ ? I find that completely the other way around. Even when you apply various linking settings that should help reduce the size of your APK, IPA file (Proguard/Android, Link ALL, Link SDK, AOT, No Debug etc) — flutter is always consistently much much lower when compared on a like for like basis, I.e assuming in the case of iOS you are not targeting multiple architectures — just a single architecture for sizing tests to be accurate. (iOS by default uses App Thinning which if you target multiple architectures your IPA will be much bigger but on deployment to the physical device, only the code relevant to the users device/architecture will be sent/downloaded).
  • To do anything reasonable you need a multitude of nugets. Additionally, if your app has been built around a 3rd party nuget that has not moved over to .NET standard then this prevents you from enjoying the many benefits that .NET standard brings.,
  • There are still Too many regression bugs even with the latest version of VS Enterprise.
  • Too many regression bugs with XF (I stopped at 3.1)
  • You have to reboot VS daily and sometimes you have to reboot 3–6 times a day)
  • VS takes vast memory and even much much more when you add extensions (R# etc) , mine was approx 2.5GIG
  • Components in Xamarin forms are pretty pathetic when compared to Flutter however Xamarin have now brought out Xamarin Shell in an attempt to stop the waves of Xamarin developers abandoning their product — too little too late I think.
  • No Xamarin direction — they believe its more important to add things like CSS rather then a) Concentrate on making a stable product, reduce size of APK/IPA , reduce build times, create the equivalent of true HOT RELOAD/HOT RESTART.
  • Sometimes an app you have been working on for days just stops working. You may get some cryptic xamarin binding error or some other XAML build error that is completely unrelated. You then need to either delete bin/obj folders, reboot, do a full rebuild, ensure all your projects reference the same XF version, purge your nuget cache, clean your xamarin cache or clean your iOS build cache !
  • Xamarin are playing catch up — they are no longer the innovators in cross platform mobile tools — Only now have Xamarin brought in back button support within the product and this is via their new product xamarin shell. i.,e you can do the same in Flutter whereby you can control if views pop from the navigation stack when you press the hardware button (on android) or do it via software to navigate back a page.

I have been using Flutter for about a year even though its still in Beta . I have picked up Dart quite easily and dont miss coding in two separate languages — XAML and C#. Writing all my code in one language and not having to use markup was quite awkward at first but after a few weeks I found I was very proficient in creating screens very quickly., I easily roll screens with business logic separated using streams/blocs/scoped_bloc coupled with RX and just love how BEAUTIFUL my apps look compared with Xamarin.

Admittedly, abandoning a 2-year project for general release to both app stores was a hard decision to make at first and there is functionality that is in my Xamarin solution that currently there isn’t a dart pub package available just yet, but I know that when I am coding my app — I have the certainty that it will work straight away on either platform and more importantly I am productive using Flutter and have a stable environment (I use VS Code).

Dont get me wrong, there are issues with Flutter — many issues , things which dont exist in the C#/Xamarin world and it has very limited pub support compared with nuget but you need to get one thing into perspective — Flutter is not even a v1 product yet but its toolset, stability, & UI feature list far exceeds that of Xamarin and you can expect things to only get better with time …