Xamarin and Flutter are frameworks that have been in the mouths of many developers, offering an interesting working model that has caught the attention of many people. I’ve seen many people who advocate for a framework by making comparisons based on bad past experiences or commenting on what others heard.
If you think I’ll talk about the wonderful world of Disney, then I’m sorry to disappoint you. The idea is to show both sides based on previous research that was done in order for this to reach a wonderful place called “Consciousness”.
I will still add and give credit to those interesting comments that have basics, in order to update this report.
So far I’ve only met a few people who tried Flutter, but they don’t work with it, and we’ve talked about it and I can tell you that there are things that people don’t comment on, but nothing happens because it’s normal with new technologies. I’m not going to go into those details, I might mention some details depending on the section, but in the end, I’ll always recommend that you do your own research and don’t take my words as the final decision. You start with a simple search like this one or this one.
The truth is that there are many comments about these two Frameworks and there is always the discussion of which is better or where the future of a certain tool is. While it is true that the future is uncertain, we can always bet on a certain technology in the end; that will depend on our environment.
- Flutter vs Xamarin: Evaluation Criteria
- Architecture – Technical Level
- Architecture Pattern
- Learning curve
- Launch time
- Shared code
- App size
- Community support
- Supported platforms
- Price/ OpenSource
Never forget this!
I am really skeptical of these kinds of conversations, in this case, I want to share the information because I believe that in many communities conclusions are being assumed on past experiences or badly informed rumors.
Hey! If you are one of those people who has had bad experiences with a certain tool I want you to visualize this word in your mind: EVERYTHING EVOLVES. Yes, that’s right, everything evolves. Repeat with me, Everything Evolves! One more time! All… Okay, stop.
For me (personal opinion), all Frameworks are tools and the quality of the final product does not depend on the tool, but on the developer behind it.
Knowing that the environment in which I operate is Xamarin, the points to be explored could be seen as biased. That’s why I want to emphasize that the information you’ll see here is a topic of discussion exposed in several communities where I was able to interact with different points of view. In addition to this, I had to research every detail on my own to try to bring you truthful information.
It is good to mention that I will try not to make any statement against or favor useful tool(If I miss something, well…? What are we going to do to him?), we will only consider evaluations for analysis. When we start to see the tools as what they are we will start to get more out of these climbs to the next level.
That said, let’s get started!
Flutter vs Xamarin: Evaluation Criteria
These are the evaluation criteria that we will be detailing:
- Architecture Pattern
- Learning curve
- Launch time
- Shared code
- App size
- Community support
- Supported platforms
- Price / Open source
Likewise, I leave you a Conclusion in case you are very desperate and want to see the final resolution.
Now let’s do it!
Actually, I would not take the installation as an evaluation criterion, as the installation is done once and should not be an evaluation point no matter how complicated.
In the Xamarin Universe community on WhatsApp, some commented that the VS environment is better. Just need to give a few clicks and leave the VS with the components you need by downloading and installing, and that’s it. You can say that the process is almost automatic.
I did not install Flutter, but for this section, I set out to investigate. To be able to install Flutter, you have to do everything by a console and you have to install SDK, Android Studio, Tools, Editor, etc. Need to add o edit some environment variables and stuff like that. It’s not that it’s something from the other world, although I think with VS the process is more intuitive since you don’t have to do practically anything. Similarly, I saw some comments that say that with VSCode the Flutter installation process is almost automatic as well.
Regardless of, I don’t think this is a point to evaluate these Frameworks. In the end, this process is only done once. Anyway, I won’t take that into account. You may leave your comments about this section.
Update: The console is not bad, I use it from time to time, I just say that people who do not use the console will find it difficult to learn.
Architecture – Technical Level
Flutter and Xamarin have within their engine all the components needed to develop an app.
The Xamarin architecture looks stronger if we make the comparison. If we want to make use of the native API of the target platform, we can do it with C# or F#. It’s good to mention that Xamarin doesn’t have support for Kotlin or Swift at run time.
Now, aren’t we supposed to use a cross-platform framework to not use native code? Wouldn’t this lengthen the learning path? Within the Xamarin environment, we can use native components without the need to use native code.
On the other hand, Flutter uses the platform-specific code (Java/Kotlin on Android and Objective-C/Swift on iOS) to make use of these APIs. This would greatly increase the line of learning by having to learn several languages (more on this topic in the learning path).
There are some specific cases, where you have to use very specific libraries or frameworks developed by the same companies, and you will have to use those libraries or code. Xamarin allows you to bind those libraries, in the case of Flutter, although it allows you to bind those libraries you also have the option to use a portion of code, as it uses native code for specific cases.
Flutter here has a point in favor. While it is true, giving the option to the user who can or cannot do what he wants in various ways, in this case using the native languages, is not bad at all.
Both Flutter and Xamarin in this section have advantages and disadvantages. Depending on the world in which you come one or the other it may be more convenient or interesting for you.
If anyone wants to add something else to this section, welcome be a companion. I’ll leave it here.
In Xamarin.Forms, clean architecture is used through the MVVM (Model-View-ViewModel) pattern. In Xamarin.Android, MVP (model-view-presenter) is used. In Xamarin.iOS, MVC (Model-View-Controller) is commonly used. All of them are clear and well-known patterns of architecture or design that have proven to work well for any type of application.
In Flutter, a universally accepted standard or architecture approach has not yet been defined. As far as I’ve been seeing, all articles show simple examples, which is normal because they need to guide people on the basics before talking about more advanced aspects.
Based on what I’ve read, if you’re thinking about using Flutter for a large project, it would be preferable to have a clear idea of how it’s going to be structured, so that it’s scalable and easy to maintain as your application grows in size and complexity. Obviously, this has its pros and cons; but we won’t talk about it here.
There’s talk that C# is better than Dart because it’s more popular. Okay, calm down! Certainly, the use of a certain technology can mean something special within technology, but the popularity of a language does not define how solid, mature and functional it can be. C# is a powerful, well-designed and readable object-oriented language (OOP).
There are many features in and out of the environment so people recommend C# over Dart as a programming language (you don’t have to believe in me, google it). I’m not going to get too far into those details, here it seems that the main focus is DART.
“Dart is being developed by Google because Google has a business interest in migrating off the JVM. If you don’t have those same business interests, what is Dart offering? It’s lacking in features (No multi-threading, poor support for higher order functions, no null safety, no union types, no extension functions, no data classes, syntax quirks like the cascade operator, etc.), it has less robust tooling, a less mature ecosystem, etc.”
This is what some people say. I don’t have any knowledge of this, but that’s where I leave you the thread.
Note : With Xamarin you can also use FSharp (F) which is a functional programming language.
When I talk about the learning curve, I literally talk about the domain of what you’re doing. In Xamarin.Forms, many complained that they had to use a CustomRender when they needed to do something that was specific to some platform.
This doesn’t happen that much anymore, the community has matured quite a bit and there are good plugins and tools that save us a lot of headaches. But what happens when we need to do something very specific? That’s right, CustomRenders are the solution.
With Xamarin, there are configurations that you’ll need to make on each platform-specific to launch your app, for example, in Xamarin.Android and Xamarin.iOS. These can lengthen the learning curve a little, and I say a little because at first, the changes you would have to make would be minimal. Among more advanced cases, more advanced some configurations.
As I mentioned earlier, I saw that in Flutter you have to make use of the native APIs in native code which would greatly increase the line of learning by having to learn several languages.
As you can see, regardless of the platform or framework, it seems that there will always be such cases and guess what? Unless you’re the boss, you’re going to have to solve the problem, that’s what you get paid for.
On the other hand, Flutter uses a command console to perform many tasks. Don’t people who don’t use console much affect you on the learning curve? I’m just saying because, in the end, I’m talking about learning, not copying and pasting.
By this, I don’t mean that Xamarin is easier to learn than Flutter. I haven’t seen Flutter, I’m just saying there are a lot of evaluation criteria that affect the long-term learning curve. It’s not just creating a TODO or following a tutorial and saying that one or other is easier. It’s adding up all the details and seeing what makes you more productive.
In the end, your learning path will vary greatly depending on the environment in which you are in and used to work.
Update: With both frameworks you can create an application without the need for customization on each platform (CustomRenders in Xamarin / Native Language in Flutter).
While it is true, the Flutter community is growing enormously and is being very active. But still, its ecosystem still lacks maturity. The Flutter community has created a lot of components and plugins, but the list is still not as extensive as Xamarin’s.
“Flutter has a decent list of UI components and other great-looking add-ins, but it’s not as rich as the plugins you can find for Xamarin. The options are limited, and many add-ons are old, not maintained, and may no longer work with current versions of Dart/Flutter. Some components (especially non-UI components, map platform-specific features) are only available for iOS or Android, but not both (usually android compatible because Android developers they’re more with Flutter than the iOS developers right now, as Flutter comes from Google).”
Opinions in the comments box.
In Xamarin, depending on the platform you’re working on, you need to place the resources you’re going to use in a specific folder for handling resolutions across multiple devices. Of course, with Xamarin you also have the option to reuse resources in your shared project and depending on the resource you will have to use some extra settings.
In Flutter you have the files in one place (with subfolders if you want) described in a YAML file. Other files, such as launch icon and platform settings, as well as other Frameworks must be inside a specific folder.
Now, in terms of maintenance, updating, and productivity-level file synchronization Flutter is really useful as most resources handle it in one place.
The Hot Reload is a feature that has become very useful and eye-catching to developers, and why not? This greatly increases our productivity.
The hot reload is one of the highlights in Flutter, among communities. Flutter has some very interesting tools that you can see here, beyond these and some extensions in VSCode I found nothing striking. We’ll talk about testing tools later in the testing section.
Xamarin has several Hot reloads from third-party tools, some with some interesting features. Similarly, the official hot reload was announced before the end of the year.
On the other hand, in Visual Studio, Xamarin.Forms have XAML Previewer that lets you see what your page will look like on the iOS and Android platforms (Remembering that controls are completely native). It has a Toolbox to use Drag and Drop controls and a property editing panel for your XAML.
In this article, I talk about some third-party design-related tools, packages, and extensions in Xamarin.Forms. Similarly, Xamarin within the Visual Studio environment has other very interesting tools that you can see here. The latter, we will detail them in the testing section below.
For Visual Studio there are many interesting extensions that can help us in productivity issues. In the Visual Studio environment, we have tools like IntelliCode (AI-assisted development) and on the community side, we have Multilingual App Toolkit (helps us with multi-language support services in our app), for mention some.
Each native platform has some specific configurations that must be performed before an application is launched. No matter what framework you use (or at least taking into account current ones) these settings will always be the same, the only thing that changes in the process of making these settings between Frameworks.
On the other hand, with Xamarin + VS ( Android/iOS) this setup process is very intuitive because everything is handled graphically. It is good to mention, the Xamarin documentation in this section is more extensive and detailed, having some additional configurations that might be of interest at certain times.
An app in Xamarin can share more than 95% of code, while in Flutter you can share up to 70% of code. It is good to clarify that these percentages may vary depending on the complexity and customization of the project.
In some mean, it will also depend on the native functionalities of the application. Luckily, Xamarin’s environment has a set of components and libraries, among the most prominent Xamarin.Essentials, which as the name implies, contains the essential cross-platform APIs for our mobile apps. Other libraries can be found in Nuget and others can be found in the community, some examples of them in Xamarin Universal Library.
Within the environment of Flutter, we can find some interesting libraries that meet the same goal. These are mostly for some reason in the Developers Preview. On the other hand, on the part of the community, I found a repository, named Awesome Flutter, which contains libraries, tutorials, Frameworks, etc.
Both environments have similar features, although in Flutter lists many of the libraries shown are still in preview. Maybe you guys take a look and let me know your opinions.
Note:Analyzed in August 2019
Update: The code reusability in xamarin is not only among mobile but also the code between server and client can be reused. The DTO, request and response classes along with business logic can be shared. Now that, everything .net is going towards .net standard libraries, xamarin ecosystem will become more capable.
UI Components and Development APIs
This is one of the most difficult sections to value, both Frameworks offer large amounts of components to create any type of application. Many of these are completely different and the API varies greatly.
If we evaluate based on quantity, Xamarin supports more platforms than Flutter so Xamarin has a clear advantage in this approach.
Similarly, if we evaluate based on maturity, although Flutter has many components, they lack maturity. According to the research I’ve done, many of Flutter’s components have many bugs (to see this there are only going to their repository) open for a long time, some basic for some components.
More on the subject in this thread.
On the other hand, Flutter allows you to play a little more with the components with the only idea of facilitating the design area to the development teams. It can be said that one of the advantages that Flutter offers is working the design with incredible simplicity. Working on a small team without a full-time designer seems to be a blessing.
I leave it there, your comment on this peculiar case.
Within this section, there is a lot of controversies because there are different views and options to analyze.
When developing cross-platform mobile apps, support for native components can be the key. Without support for native components, in many cases, our application will not feel like a native application. It is very important that the framework has an API to access native components without any problems.
How beautiful and awesome an app is does not change the point of perception described above. If you’ve worked in corporate application development teams or at least have in mind getting to work on one someday, you should know how important the user experience (UX) is to them. I can tell you that there are teams that are only dedicated to creating UX because if the user does not feel comfortable the product that is offered can be a failure.
Within the Flutter environment, we can find a lot of components that really help quite a lot at the level of design and effects. However, even if in Flutter the controls appear native, they are not. I’ve still found several articles showing how to introduce a native component into a Flutter view with a little extra customization, an example here.
I say this because there are many of these components that need to mature a little more, for example, here you can see one of the threads I found while doing research.
Something curious that I want to comment is that I have done a search about the consistency of user interface designs in mobile applications and I have found an article that mentions something that caught my attention.
Consistency in UI design is concerned with making sure elements in a user interface are uniform. They’ll look and behave the same way. This helps constantly prove a user’s assumptions about the user interface right, creating a sense of control, familiarity, and reliability.
To develop consistency in UI design, you should aim to be consistent with device UI guidelines and behaviors, other similar apps/sites, and with your own design. Different platforms have different UI and usability guidelines you should observe when designing.
MARIA DE LA RIVA
Many people get confused between design consistency and cross-platform consistency. These are totally different.
Ok, let’s continue.
In the case of Xamarin, the components seem native because they are. This means that they meet all the requirements of the user interface (UI) and user experience (UX).
I would like to leave your comments about what they think about this section. It is a topic that can be written only one article about it, but it’s ok for now.
Integration and Continuous Delivery (CI/CD)
Within the DevOps environment with Xamarin, we can find some quite interesting tools like App Center and HockeyApp. On the other hand, within the DevOps environment with Flutter, you can see tools like Fastlane and Codemagic.
Taking into account the official tools, Visual Studio App Center certainly does many of the things Fastlane does, but it depends entirely on your individual use case to be able to compare Fastlane with App Center.
With App Center you can count on:
- Support for: iOS, Android, Windows, React Native, Xamarin and even more apps
- Intuitive but powerful UI
- Integration with GitHub, BitBucket and VSTS
- Push notifications
- “The crash reports are so good that you’ll almost want your app to break.”
- A lot of analysis and graphs.
What you get with Fastlane:
- About 170 integrations with other services.
- 100% open source project under MIT license
- The local solution, so you know where your data is, doesn’t need to worry about data security (except your own je)
- Integration with all major IQ tools
- Support for iOS, Mac y Android.
- Unlimited customization possibilities
- Deployment from anywhere
Within this section, both environments are very complete and trained. This time, I’m going to show you some tools from these environments for you to compare.
Flutter has some very interesting tools that you can see here. Let’s look at some below:
- Flutter Inspector– A tool for viewing and exploring Flutter widget trees.
- Timeline view– Displays information about Flutter frames.
- Memory view– Lets you see how isolation is using memory at any given time.
- Performance view– Allows you to record and profile a session from your Dart application.
- Debugger: DevTools includes a source-level debugger, supports breakpoints, stepping and variable inspection.
Similarly, Xamarin has some very interesting tools that you can see here. I describe some of them here:
- Xamarin Inspector: Tool that allows you to visualize your controls in 3D to inspect, debug and diagnose your running application.
- Xamarin Profiler: Tool used to analyze the behavior (memory snapshots, statistics, call tree, assignments, time profile, etc.) of the applications.
Within Visual Studio there are many built-in tools (Android debug log, Android device monitor, Debugger, etc.) and others from third parties that help us a lot. In this article, I talk about some related to design.
Most commented problems at the beginning of Xamarin, today it seems that Flutter is dealing with this issue as well.
The same can be seen in the Flutter official documentation:
In July 2019, we measured the download size of a minimal Flutter app (no Material Components, just a single
Centerwidget, built with
flutter build apk --split-per-abi), bundled and compressed as a release APK, to be approximately 4.3 MB for ARM, and 4.6 MB for ARM 64.
On the other hand, within the Xamarin environment, we can find a “Hello world” of 2.9MB. I had already talked about this section a little more in detail, I leave the article here.
The performance of an application depends entirely on the developers who work it. However, there are some tips or details that make a small difference. Among Frameworks, it may not even be noticed, but with the necessary tools, you can see the most contrasted information.
All the research and data shown in this article were obtained from the great and wonderful world of the internet. Unfortunately, I couldn’t find any statistics or similar evidence with these Frameworks.
If you know of any evidence let me know, I will analyze the truth of the data and update the article if necessary. If you want to do a test, you still leave me the details and we publish it.
How can we measure community support?
- Through the GitHub repository? Flutter has 72k stars, with 424 contributors. While Xamarin has 6.6k stars, with 367 contributors(Xamarin.MaciOS 1.7k stars, 86 contributors + Xamarin.Android 1.3k stars, 70 contributors + Xamarin.Forms 3.6k, 211 contributors).
- Through contributions (components, tools, etc.)? Here we can only make assumptions.
- Through the maturity of these? Assuming it’s not quantity, it’s quality.
- Through community groups? This varies depending on the location, but the same how do we measure this?
These days, Xamarin is the framework that supports the most platforms so far. With a total of six (6) platforms, Xamarin supports Android, iOS, Windows, macOS, Linux, and Tizen.
One thing I was surprised to find was Xamarin.Forms support for web, which you can see in this repository. This is unofficial and apparently does not have a stable version yet.
It seems not, but when you work on development teams for companies with high volumes of requests, developing for different platforms adds a lot of value to the development team. It’s just not Android and iOS, believe me when I tell you this.
Officially Flutter only supports Android and iOS. However, according to official statements they have in mind to support Windows, macOS, Linux, and Web.
Both Frameworks are completely free and open source. End!
Certainly, the future is uncertain. What works today may not work tomorrow. This is part of evolution, and more in these times where technology advances very fast.
Nowadays, in the area of general development, the acceleration within the development processes is being taken into account and it is here that Flutter introducing its widget concept greatly simplifies a part of the development of mobile applications.
On the other hand, Xamarin being a more mature tool is also introducing new concepts such as Shell that are speeding uptime and reducing the complexity of mobile application development.
As I have said several times, the only person who can tell you if a tool is good or bad is yourself. Search, analyze, test and draw your own conclusions. Many think that making a hello world can see the true potential of a tool, and on several occasions, I have left some evaluation criteria for them to take as a starting guide.
If you look, I have never said that one tool is better than another. In the end, I am not paid for you to use a certain tool. I just like to share information, my opinions, knowledge, and experiences that I think can help most of those who enter this blog to consult.
I like to value everyone equally. What I want with this article is to stop misinforming, to show clear points, sources, authors, etc. There are many people who are sharing wrong information in the communities, but we cannot judge these, in the end, they are teaching what they learned.
True Ignorance is not the absence of knowledge, but the fact of refusing to acquire them.
– Karl Popper
My opinion is not the final decision
In the same way, I would like to validate all the points that I have mentioned and if there are others, leave them in the comments. I have always liked to hear the opinions of others.
If you have any extra information that could be used to add it to the evaluation, you can leave it in the comment box without problems, I will gladly take them into account.
Thank you somuch for reading this post!