(This is a reproduction of a post I wrote for my consulting company. The original can be found here).
Is React Native (RN), a valid choice to write cross platform applications? Will your codebase be smaller? Will it be simpler? Will it be more maintainable?
These are important questions. A bad decision on core technologies can be costly to larger companies. It can be fatal to smaller ones. Care should be taken when adopting new technologies. They should be vetted and evaluated. What you’re looking for are the game changers, the technologies that will increase your productivity by an order of magnitude. Is React Native such a technology?
Reacticity has tens of thousands of lines of codes (LOCs) written for Android. We’ve been ignoring the iOS market but now have a hard requirement to support both Android AND iOS. Considering this, we need to make a decision as to how we will support this new requirement. There are two approaches considered:
- Write new iOS clients that duplicate the functionality of our Android apps.
- Convert ALL our existing codebase to React Native.
The first option is the standard approach in large enterprises. It is the least expensive in the short term. This becomes more expensive over time, as each new feature needs to be added twice, tested twice and maintained twice . It is less technically risky though as you don’t build on a common platform that reduces performance and limits the functionality of the underlying platform to the lowest common denominator.
The second option implies re-writing a large codebase and taking a multiple man-months (MMs) penalty where, feature wise, there is little improvement to our codebase. That being said, there are possibly large economies over time as (all things being equal) our efficiency would theoretically double (as we support one codebase instead of two).
To make a decision between these competing options, we evaluated how RN would fare for us. We did this by re-implementing a non-negligible part of one of our Android applications and comparing the RN and Android apps on a set of evaluation criteria. These criteria will be detailed later but generally can be classified as:
- Code Analysis
- Language and Libraries
- Development Tools
Urbanoe Mobile is an Android application that allows registered users to report infrastructure problems for any city in the world. It uses a REST API to communicate to the Urbanoe PaaS. It also uses GPS, the camera and the Maps APIs. It took us 8MM to implement this app.
Here are a few screenshots of it:
Note that the app was written using API 22 (Android 5.1) which is a few years old. Re-writing this application with a more current API would definitively reduce the LOCs but not enough to invalidate the analysis made here.
The new application is the Montreal Issue Tracker, an application that lists known infrastructure problems for the city of Montreal. This application allows anonymous users to browse existing issues, news and statistics collected from the Urbanoe PaaS. It uses the same REST API as the one used by Urbanoe Mobile. It also uses the maps API but not the GPS service (which was tested separately).
Here are a few screenshots of it:
We decided on this app by first time boxing the whole exercise to 1MM. Furthermore, we wanted a “real app” (something that would be offered on both the Play Store and the App Store). Basically, it’s not enough to demonstrate features, we wanted to implement something from concept to released product.
The application was actually written and released within the timeframe we had set. If interested in the result, feel free to download the app from your favourite app store.
For the iOS version:
For the Android version:
Now on to the analysis of the results.
About this article:
This article is divided in 4 parts:
- Part 1: This post. Introduction to our test approach.
- Part 2: Code Analysis.
- Part 3: Comparison between both ecosystems (coming soon).
- Part 4: We’ll sum everything up and explain our decision (coming soon).