Xamarin vs. React Native - pros and cons
Mobile applications are everywhere. According to some sources, we all use on average 10 applications every single day. For better or worse, we are used to reaching for our phones and checking something: play a game, do some banking, order some dinner. This is personal computing at its best, because it is so seamless, natural and for the most part faster than going to our laptop or desktop computer. Phones are brimming with the latest technology; you name it, face detection, fingerprint scanners, enhancing your photos with AI assistance, VR, AR, fast payments… We can’t go back, the only way is to march forward and appreciate what we have.
Table of contents
Growth in the mobile market is unprecedented, revenues are now not in millions but in billions of dollars every year. A company that wants to get slice of this pie needs to be present on its users’ phones - there is no question about that. Every day in Apple Store or Google Play there are hundreds of new apps that fight for your attention and money. The question remains, how can a company create a product that is compelling and, for the most part, cost effective.
Going down the rabbit hole(s)
Developing a mobile application that is both functional and eye-catching is hard, every developer that has tried will tell you that. There is a balance between making something that is really useful, and a bloated UI that can distract a user anytime during a session with the app. At the same time, your product needs to be responsive to any user interaction.
We need to decide what route we will take as mobile apps can be created in two major ways: native (with Swift / Obj-c in iOS world, and Java / Kotlin on Android ) or hybrid-native (with Xamarin or React Native, or another available framework). My goal is not to convince you to use either of them but to draw your attention to the most crucial parts, and in the end, you will know what is best for your upcoming project.
Native
Let’s get the elephant out of the room. If you want to have an app only for Android, or only for iOS, and your developers are masters of their craft, you should definitely go native. If you’re thinking of making your app cross-platform, you should definitely consider Xamarin or React Native.
Native will give you the most rounded and hassle-free results, with other benefits like easy upgrade paths from one SDK version to another and the sense that you have the most control at your fingertips. You will also receive new features faster, as soon as Apple or Google release them.
If you plan on doing an initial version of the application for a single platform with the second available for the other (for example, the first on iOS and the second on Android) then you will have to tackle a number of problems that you probably didn’t know existed. Xamarin and React Native will let you minimize the impact of those problems on your development team and, ultimately, on your organization. The cost of development may not be cut in half, but it’s likely you will get what you need in less time.
One of these problems is that you can’t create a cross-platform UI. This means that you will have to manage two codebases: one for iOS, another for Android. You will have to resolve problems for two teams that are working separately on the same product. Those teams will have a hard time talking to each other and aligning their tasks, and god forbid you change something in the already available version - the second team will need to align along the way, hoping that they know everything and no important feature has been forgotten.
All of this will cost additional money and time because you will need to hire more people to manage it. It can be done, and for sure many companies do it, but it is always something that you need to think about and be prepared for.
Hybrid-native
I am calling Xamarin and React “native hybrid-native” frameworks because both will let you create an application that is native underneath, with native controls and native APIs. In the end, you get a package that you can take and upload to either Apple Store or Google Play. What is different is how they operate, how they take the code, add their “secret sauce”, and let you take advantage of their features.
When you look at the surface, they do the same thing, but the devil is always in the details. Let’s take a look at both and see what makes them “tick” in their own way. There is a reason that they are both successful in the marketplace.
Frameworks
React Native
This framework was created and is maintained by Facebook for the vast majority of their apps (for example, Facebook and Messenger are created with it). It is based on React (which is a JavaScript framework), and I mean that literally because for React Native to even work, you need to import React as a dependency. The main advantage of doing things this way is that when React is updated with new features or bug fixes, React Native will get those changes almost immediately (usually shortly after React when a new version of React Native is made available).
Xamarin
This cross-platform framework from Microsoft allows you to write mobile applications in .NET and run them on Android or iOS devices. Previously it was known as Mono and it allowed developers who wrote their application with the .NET framework to also target Linux or Mac OS X. That shows that even in the early stages of the platform it was planned to be a cross-platform framework. Microsoft updates Xamarin with stability fixes and features, and the Xamarin Forms package receives new features at a steady pace.
Requirements
React Native
JavaScript ES6 (or TypeScript), React, and web development is undoubtedly a plus as you will probably have knowledge already that will allow you to start quicker. JavaScript developers and more general Web developers are your target.
Xamarin
C# programming language, .NET framework (WPF or preferably UWP), and XAML (knowledge of behaviors and converters is a plus). Developers that are deep into the Microsoft development ecosystem will feel at home here.
More general mobile application development is not required but it will let you see results faster, with less time spent on researching two mobile operating systems. Both iOS and Android have a distinctive look and feel and they are not equal on features. Sometimes one platform has the advantage over the other, and this knowledge is needed to realistically calculate the development time to achieve your goals.
UI
React Native
The building blocks of React Native are components, which are units of HTML-like UI (called JSX) & JavaScript code added together to make specialized chunks that you can re-use throughout your application. If you have knowledge of web development, you can literally change <div /> or <span /> to <View/ > and <p> to <Text />, but please remember, this is not HTML, it is JSX which is JavaScript underneath.
Xamarin
A UI can be created with Xamarin Forms, which is a cross-platform collection of components to create interfaces that run on many platforms (as of writing this article, Xamarin runs on iOS, Android, Windows UWP, Linux, Mac OS X). It uses the XAML language to define a hierarchy of UI objects, their dependencies, and even how they will behave in certain situations. For example, you can write XAML behavior code that will be executed when a user presses a button without the need to write any backend code. This route is great for prototyping and getting results faster with just one codebase to maintain.
It also supports writing a UI using a Xamarin Native API, available for each platform respectively. iOS or Android developers can re-use their knowledge of those systems at a high level. It is not possible to copy and paste code directly one from another but it will look familiar to them. The advantages for going with a native API arealways speed and the ability to access any functionality, even if the Xamarin Team is not providing a way to handle such edge cases.
What is really good about Xamarin Native Forms is that you choose what is best for you in the moment. For example, you can create one UI base with Xamarin Forms (that iOS, Android and UWP apps will share inside the project) but in the case of emergency, you always have the option to tap into the native UI and do any custom changes you need.
UI blocks for both platforms will look native. On iOS it will retain an iOS look and feel, on Android it will use Material Design. If this is what you need, you don’t have to do anything. Your results will be good with either Xamarin or React Native.
If you need something more customized and you want to retain the same look and feel for both platforms, you need to create a “new style” yourself or use one of the many UI frameworks available. For React Native, I recommend NativeBase.io; for Xamarin, the most common option is to use custom global styles for both operating systems.
Performance
I know, this is very sensitive topic, but it’s extremely important because mobile apps need to be responsive to touch, quick to launch and not too heavy on resources. If one of these areas is not be covered properly, users will feel it right away. The obvious symptoms are: clunky controls, weak responsiveness when going through the app, loading UI elements multiple times because they were queued, and last but not least, super fast battery drain.
If your application has any of these symptoms you are out of the game. Users will uninstall it in a heartbeat and to get them back, you are in for some serious work. Preventing such a scenario is much better than fixing it afterwards.
The preferred situation is that your application runs all intensive tasks asynchronously (calling external resources, business logic calculations, updates to the UI itself) without too much interference with the UI / Main Thread. The UI / Main Thread is common in all applications that run on an operating system. This is the place where the UI is rendered with lots of cool animations and transitions from one screen to another. For the most part, you want this thread to be locked in 60 FPS mode to get a smooth performance.
React Native
Applications in React Native are written using JavaScript, which is interpreted not compiled. There is some optimization that internal tools can do to speed things up but in general intepreted languages have a greater computation overhead than compiled ones.
Any code you write in React Native is computed on a so-called JavaScript thread that includes calling external resources, updating data inside the views or even JavaScript controlled animations using the Animated API. This is the same thread that will render and update your components as well. Any unoptimized business logic inside your app will also hit it hard, so it is always wise to remove unnecessary code when you finish working on a particular set of features. The less code, the better.
There is also Main Thread but that works only to render native controls, so even if you lock the JavaScript / UI thread, native controls that live there will be able to send data to your components. That data will not be processed until all JavaScript tasks have ended, so you don’t want to lock your JavaScript thread.
It would seem that this is all bad, but not so. It is a limiting factor, and definitely games should not be written in React Native, but for business-oriented apps it is sufficient to get good performance. With every iteration of the hardware itself we can do more, because CPUs are getting faster and more optimized to handle computing-intensive tasks.
Xamarin
This Microsoft framework using a version of .NET, and C# which is a compiled language. This means that it is interpreted and optimized during compilation, then it is packed and runs on the desired device. There is even something called JIT (Just in Time) compilation that compiles and optimizes code on the fly (only executed code is compiled) for the specific platform that it will run on. It gives Microsoft and developers the means to make an app “as fast as it can get” on any particular device.
Xamarin uses Mono iOS or Mono Android at its core, a specialized version of the .NET framework optimized with mobile devices in mind. It is even optimized for particular systems, as you can see by the iOS and Android in its names. Operating systems behave differently in relation to each other, so selective work to get as much as we can squeeze out of them will generate better results in the end.
There is also UI / Main Thread that renders the user interface on-screen, and can do any computing-intensive tasks. One advantage of the Xamarin way of doing things is that developers can create their own background threads on-demand. This is huge when you think about doing specialized works that will compute any business logic and get the results afterwards. You can run those threads in parallel, so many complex scenarios can be achieved without worrying that you might affect the performance of your UI / Main thread.
You can’t create an infinite number of threads and expect that your app will run great (“with a great number of threads comes great responsibility”) and it can become complex to grasp what is going on. You have the power, use it wisely.
Testing
Development of any application can be hectic and it does not always go well from the start. A development team contains usually not one, but many people that need to head in the same direction. Every day they work on the same codebase, they add / remove features, merging their changes to achieve the final product. Code is changing every single day for as long as the project is in active development. To ensure that the development team will deliver what is known as a “finished” product, some testing is required.
Testing can be done in two main ways. In the first, you assign more people to the team and they carry out “manual testing” (or “black box” testing) of the application. They go through, screen by screen, button by button and check if everything is working. The second way (so called “white box testing”) is automatic testing and this is when developers write small chunks of code to test the functions or components that they have created. This will extend the development time but in the end you can’t do without it because those small chunks of code in the future will minimize the impact of the next batch of changes that undoubtedly will need to be done if you want your product to be relevant in the market.
React Native
Self-described as a “delightful JavaScript Test Framework”, in my experience, JEST is very easy to get into. It includes the notion of snapshots, and with the execution of a single command you can create templates of your components. This is huge because you don’t need to write those templates yourself. When someone in the development team changes any component that JEST knows about, it will compare one to the other. If they are different you will get an alert, but in the event that the change is correct you can re-run the the command and the base template is updated.
JEST is a framework that will work with any JavaScript code. As components are written using JSX and the “backend” code is also JavaScript, we can write tests to ensure component structure and functionality works in the desired way.
Xamarin
In the .NET ecosystem there is library that is called nUnit 3 that allows the testing of any .NET language code. To make sure that we use it correctly, the code needs to be written in a way that is testable.
We write code in an object-oriented way with classes that contain not only properties but also functions, doing units of work for that specific class. Class doesn’t need to have any dependencies and a self contained class works without the need for outside resources. More common are classes that are dependent on one or more resources, and in that case we need to be sure that we can use those resources for the test.
A design pattern that ensures that classes with any external dependencies can be tested is called dependency injection. Instead of getting into this topic too deep - because this is not the focus of this article - the simplest explanation that I can think of is that any external resource needs to be injected into the class by the constructor. In that case we can always exchange this resource for the mock-up being tested and test any edge case scenario that might occur.
I am writing about it here because if you follow this pattern you will have less work to do and you will be able to test your code fully without the need for major refactoring. It is really important.
Ecosystem
React Native
This is built using Node.js, which is a JavaScript framework that allows the production of desktop class applications using web technologies. There are lots of great libraries ready to install via NPM (Node Package Manager). You will end up using it anyway, because it is the main packager used by React Native. Just to name a few useful ones that will speed up your development: Redux, Lodash, Axios, moment.js, and there are many more that are commonly sees in any major project. Overall there is great open source community that is full of pre-made solutions. The main drawback is that you may find a React Native library that is available but not maintained by the original author.
Xamarin
This is very well integrated with the Microsoft ecosystem of SDK and cloud solutions. There are lots of additional packages that can be installed via NuGet Package Manager. Official Microsoft SDKs are well documented and maintained with bug fixes and new features. Third party solution companies like Telerik are creating custom UI controls that will allow faster development time. You can find many free and available components, but also paid ones.
Xamarin vs React Native - final summary
When I got to know about hybrid frameworks, it changed my way of thinking about mobile application development. Normally, to make an app you need to hire iOS and Android developers. They specialize in their craft and give you what you need but you end up with two teams, one for each a platform. They need to be aligned and work together to produce the same app, twice.
Everything that you just read has a common pattern, both of the frameworks are well suited to their respective audiences. On an organizational level, hybrid frameworks will give you great results when you want to create the same application but you don’t want to invest in two development teams. Developers will be satisfied because in trying to achieve your goals they will have less work, less problems with maintaining the same app twice and more time for providing you with the best results that are, in the end, cost effective for you.
As a side note, there is no Holy Grail of development in general, but when making mobile applications, Xamarin and React Native will give you more ways of dealing and coping with the challenges.
React Native is better for developers that are skilled in web technologies, Xamarin is better for .NET developers.
This shouldn’t be general rule of thumb though. I was a developer that mainly did .NET apps within the Microsoft ecosystem. About a year ago, I started to look at React Native because of the company’s goals and also because I was extremely interested in learning something fresh and new. Two major projects later, I am pleased with the results, and I am assured that my decision was right.
If you are a developer and you are hesitating, please don’t, you will learn a lot and have a better understanding of mobile app development in general. You will gain confidence and in the end it will be great for your career too.
Share this article:
