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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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