Why Flutter instead of Xamarin or React Native?

Programmer looking at lines of codes

This is part one of a two part series about Flutter. If you’re looking for the developer tutorial and a first app to try, feel free to skip ahead to Part Two.

After working with Flutter on multiple projects, we are solidly convinced that it is the best cross-platform mobile app development framework. We picked up Flutter pretty soon after Google first started talking about it in 2016 and have loved it ever since. If it’s new on your radar, don’t feel bad. Google tends to label things as alpha and beta for a really long time. (Gmail was in “beta” for three years.) Flutter got a windfall of attention in spring 2018 when Google moved it officially to beta.

Flutter is an open-source native cross-platform mobile app development platform using the Dart programming language that Google has been developing for some time. It started out as an experiment to see what they could do if they started from scratch and has become a fast-to-develop, high-performing, and beautiful platform that Google even uses for a lot of their own apps (check out some apps written with Flutter here).

One of the most common questions that gets asked when we bring up Flutter is “Why Flutter and not Xamarin or React Native?” It’s a reasonable question, as both Xamarin and React Native are more widely known than Flutter, and Google’s liberal use of “alpha” and “beta” sometimes scares people off. Read on for the reasoning behind our recommendations.

Xamarin vs Flutter

Broadly speaking, if you are committed to .NET and don’t mind deprecations resulting from Apple or Google breaking your apps for months at a time, you should use Xamarin. Otherwise, we would not suggest Xamarin.

What Xamarin doesn’t tell you

One thing that a lot of people don’t realize about Xamarin is that unless you want to use their Xamarin.Forms library, you are going to have to create all of the Android and iOS interfaces separately. That’s a LOT of duplicate work. Which may lead you to wonder about Xamarin.Forms. Last time we used it, it was an almost unusable mess that created even more work for us. The kicker was with all that work, we got a product that wasn’t even close to our strict standards. We spent nearly as much time building cross-platform as we would have spent building natively, and ended up with apps of massively degraded quality.

Flutter, on the other hand, created an interface engine which allows you to write your interface once and run anywhere, but still makes it “feel native” on both platforms. It also allows you to customize based on the platform the app is on, and if you really need one view that is 100 percent platform specific, it is built on top of the normal native platforms and integrates easily.

Xamarin’s coupling problem

The other big reason we stopped using or offering Xamarin apps (besides the fact that it wasn’t saving any time or cost) was because at the time it was a black-box proprietary solution. This means that when we found bugs in their code, be it an existing bug or one introduced by Apple or Google changing something in their platforms, we had no way to fix it. The app was just broken publicly on the app stores until Xamarin could release a fix and we could rebuild/resubmit it.

Obviously, that is a huge deal for any app owner, and it only had to happen once for us to deem Xamarin not production ready and go back to writing for the two platforms separately again. In late 2016, Microsoft open-sourced the platform onto github and they have done their best to improve and move the platform forward. However, since it is still tightly coupled to both platforms, any changes made by Apple or Google can still cripple it on that platform. Flutter is also open-source with a wonderful community that is always happy to help, but, since Google wrote the interface engine from scratch, it seems highly unlikely any OS changes Google (or Apple) would make would ever break a Flutter app without breaking everything else on the stores.

React Native vs Flutter

Comparing Flutter to React Native (RN) is a little more complicated, and they both share some positive qualities.

Great structure

If you are familiar with React for Web development or using the component pattern of programming you will have no problem picking up either platform. RN and Flutter have you create your entire interface in pure code.  Both interfaces are constructed by putting self-contained widgets together. This method makes it much easier to make an interface that is super responsive to any device screen, because instead of moving pixels around in a layout editor, you are defining the rules that the engine will use to lay the components out on the screen. One big difference between these two is that RN maps these components directly to native UI components (so UIKit views in iOS and Android widgets there). In Flutter you are directly using material components which their engine has implemented to Materia guidelines.  They have also recreated iOS’s older-themed components if you would prefer that.

One downside to RN’s approach is that if Apple or Google break/change a component it will break/change the component for RN as well, but Flutter, since it has its own complete rendering system, would be completely unaffected. Luckily RN is also open-source, so at least you could submit a fix yourself. Keep in mind some RN components are iOS or Android specific, meaning that if you are going to have your code work the same on both platforms, you will have to duplicate those parts of the code. Flutter will handle all platform-specific visual changes or behaviors automatically without you having to add any additional code.

Highly extensible

Both React Native and Flutter allow for integration of external code. RN calls these APIs and Extensions, while Flutter calls them all plugins and packages. Both are highly extensible in this way.  Take special note of the Firebase and Google Cloud Services plugins for Flutter, because they are amazing. They make creating a real-time application dramatically easier than in the past.

Very different under the hood

Flutter uses a language called Dart that is very similar to Javascript, while React Native uses Javascript. This starts to get into the biggest difference between the two. To have native applications in a language not supported by Apple or Google you have two options:

  1. Interrupt the code at run-time
  2. Compile it down to a native arm64 binary and load that

The engineers over at Facebook have done an amazing job of taking the Webkit Javascript run-time and creating what they call “the Bridge” to interrupt the Javascript they have installed (or are streaming from a server). This makes it so that they have one of the fastest interrupters on any platform that does a fantastic job at what it does. So, credit where credit is due!

Flutter, however, will use a Dart interrupter as its development run-time, which gives it a super fast development turn around with its hot-reload system (save, and about as soon as you can switch to the simulator/emulator your change is already there on the screen).  When you are ready to compile for production, all of your code and Flutter’s code is compiled down to a native arm64 binary and that is run on the device. That, along with Flutter’s blazing fast engine, which is more akin to a highly optimized and specialized 2D game engine, means that our Flutter mobile apps have actually not only been more performant than their RN counterpart, but even their “native” platform counterparts.

The downside of Flutter

So while we love Flutter, its community, and its tooling, there are a couple of “gotchas” that we have to address in order to stay honest. Most of the issues we’ve had in the past have been resolved over the past 18 months, all prior to the platform reaching beta.

The following remain:

  1. Support for integrating native widgets isn’t quite there yet, but they are working on it, specifically focusing on mapview and webview.  This seems to be a important goal for them before releasing 1.0 officially, and they have made great strides.
  2. Realm, our favorite on device database solution, doesn’t have Flutter support yet.

Why do we use Flutter?

Because it’s fast. It’s fast to develop, it’s fast to tweak, play, and prototype with, and it’s fast on the device. In less time than it used to take us to write one app for one platform, we can now write apps for both platforms that look and feel even better than if we had written them independently.

Ready to dive deeper into the technical side of Flutter? Head on to Part Two.

Even though we love Flutter more than any other cross-platform option, we still approach every project with an open mind. If you are interested in finding out if Flutter is right for your app, let’s chat.


  1. Great Content!
    Yeah, you are right and with React Native the situation becomes difficult as it comes to the selection of navigator because of no navigator in React.
    Keep up the good work!

    1. Matt Clark :

      Thanks for taking the time to read it! Cheers!

  2. Alexander :

    Why do you say it’s a black box solution?

    Hasn’t Xamarin been open sourced by Microsoft years ago?

    1. Matt Clark :

      Thank you for the questions! I have clarified the article a bit to better reflect what I was trying to get at. Namely that the coupling of the framework to the native SDKs was the issue and when we tried it the fact that it was a black box mixed with that killed it for us.

  3. Dani :

    I want to complete your article as a Xamarin developer :
    – I have to say that Xamarin forms have improved and now is very useful to create UI.
    – You use C# to write shared code, and also for specific platform code! you don’t need to learn java, kotlin or even worst, swift.
    – You can share libraries with Back-end or other .Net projects thanks to .NetStandard 2.0 so you have on you back a lot of cool and useful libraries.
    – Visual studio is powerful
    – Azure DevOps and testing tools are cool.
    – No hot reload. Currently there is a pre version of a hot reload, not very intuitive and limitated to only XAML, C# code is not included on hot reload so is useless compared to competitors hot reload.
    – Is not considered by Google as an option. For example, Firebase documentation includes a “how to” for js, kotlin, java, node js… but no C# and libraries are just java wraps on a c# library.
    – TIme consuming, visual studio is a powerful tool, maybe to much, when you are used to vs code to flutter or react native the first impression of visual studio is:”is vs blocked?”. Also compile is a pain if you don’t have a powerful PC. (I will not repeat here the hot reload)

    I really want to work more with flutter and I hope it becomes more popular.
    Best Regards.

  4. Joel :

    Mi equipo nunca a tenido esos problemas con xamarin que es independiente de .net, xamarin.forms es super completo con rendimiento nativo, es la mejor opcion de xamarin en mi opinion, porque no usaron xamarin forms?

    1. Matt Clark :

      Basically, Forms didn’t fit our needs and now we are tooled and geared towards Flutter and love it!

  5. Hello, and thanks for this informative post. I’m a full-stack .NET engineer focused on C# and .NET technologies, I started developing mobile apps about 4 years ago, and I started out with Cordova. I’ve been building Ionic apps since their v1 and I have had a blast to be honest. After publishing a few projects, it was crystal clear that we need a native solution. So I started studying different platforms and creating sample applications with them. At first, Xamarin looked good because I could write C# and use Visual Studio. But after the first month, it was obvious that it’s not even near close to a cross-platform solution. No hot-reload, large packages because of Mono being embedded, and lots of other frustrating quirks. So then I moved to ReactNative and gave it a try. It was a breath of fresh air, of course. I got near native performance, it was easy to learn and adopt, good community and resources, and I liked the fact that I could write my app entirely in ES6 and not learn any framework specific features. But RN shouldn’t be called a native solution, in my opinion, because it is not. It’s a hybrid platform like Cordova. You’re still relying on a JS Bridge to communicate with the OS. And the UI is not entirely native, it just gets compiled to native elements, which in turn, compile to native UI. Still much better than Cordova, NativeScript and other frameworks, and it’s been gaining popularity ever since. Then came Flutter, and what a great deal that is! I was VERY curious about their architecture and I spent a few days studying their technical overviews and docs. Then I built a few sample apps and it was love at first sight. First of all, Flutter compiles all the way down to native code, which is fantastic. No bridges, no scripts and transpilers, pure native ARM code. Secondly, I love the fact that in Flutter, everything is a Widget, even the app’s root component. This means I can compose my UI trees however I want, customize them however I like, and go down to the deepest underlying layers of the framework. Fabulous. Another great feature of Flutter is their Stateful Hot-Reload engine. If you have worked with other frameworks before, you’re gonna love this madly! Another important fact, is the decision they made for composing UIs, using the Material Design specifications. Not only is it rich and beautiful, and highly and easily customizable, it also means that you wouldn’t worry about different platforms (iOS/Android). If you’re using RN for example, even for a simple task like Drawer navigation, you need to understand how it works in iOS, and then Android. Which means, you’re not gonna have a single code base for your entire app. With Flutter however, you compose your UI and from a single code base, you build for both platforms without a hassle. I’m not an evangelist, just a developer getting by. By honestly, I think Flutter is the future of mobile development. Worth mentioning that you could use it for desktop/web apps too, they’re working on it. The only down-side (not a down-side in my opinion) is that you’ll need to learn Dart. Which isn’t bad at all, it’s a great language and easily picked up by seasoned developers. I actually like it a lot, since I come from a C# and OOP background. Feels much like TypeScript and C# to me. Of course we can justify all use-cases and platforms, and sell them as the best tool there is, but I think any reasonable and experienced developer would see the pitfalls right away and realize that Google has done a much better job that the others. Hats off to the Flutter team, job well done. Cheers!

Leave a Comment

Your email address will not be published. Required fields are marked *