Why React Native is not a good choice for Native Apps?
We are currently updating the technology stack at Poverty Stoplight — an App created by Fundacion Paraguaya whose aim is to eradicate poverty.
Over the last years, we have developed Native Java Applications that have been discontinued in favor of React Native. This post explains the reasons, findings, and thoughts behind the decision to switch
Questions Around React Native (RN)?
There are still a lot of people that have not yet heard of React Native and still, quite some that associate it with something like Cordova / PhoneGap and all the other early mobile development frameworks.
Furthermore, Airbnb recently posted about discontinuing ReactNative for their applications in favor of building them natively, which might have given some people the impression that React Native is just a hype framework.
This post hopes to give a more differentiated view and show the advantages of the technology and the situations where it makes sense to use it. This post also aims to communicate the reasons for the team’s decision to move away from the current stack to the new React Native one.
Who uses React Native
After AirBnB decided to stop using React Native, many people have the impression that RN is not used anymore in any meaningful way beyond Facebook.
To start, the graph below shows that React Native is a robust technology and mature is enough to be used by the world’s leading companies in their flagship products.
Tesla, Walmart and Bloomberg are also heavy users of React Native. Here is a list with further projects that rely on the technology: https://facebook.github.io/react-native/showcase.html
So What is React Native?
Quoting Learning React Native:
React Native is a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android. It’s based on React, Facebook’s JavaScript library for building user interfaces, but instead of targeting the browser, it targets mobile platforms. In other words: _ web developers can now write mobile applications that look and feel truly “native,” all from the comfort of a JavaScript library that we already know _ and love. Plus, because _ most of the code you write can be shared between platforms, React Native makes it easy to simultaneously develop for both Android and iOS _ .
Essentially, React Native is a toolkit that allows us to not only work the way we do on the web but also use a shared code base between Android and iOS, speeding up the development process greatly. This means the following:
- We can develop one component for two Systems while ensuring that they are consistent with each other.
- We only need to write tests once, which saves us a lot of development time with the TDD approach we have.
- We don’t have to concern ourselves with the difference in implementing mobile & web apps, thus reducing the number of technologies we have in our systems and the amount of expertise we need to develop and maintain things.
Why is React Native so interesting?
This post mentions a great amount of the advantages of using RN. https://hackernoon.com/react-native-is-it-really-the-future-of-mobile-app-development-31cb2c531747
To list a few:
- Cross-Platform Compatibility (Android, iOS, Web)
- Native functionality (In fact code is executed just as native code)
- Simple to Learn
- Positive Developer Experience (one of the most important points)
- Supported by Facebook and a growing technology
Our goals for this technology:
- Faster Iteration Speed (Faster Development and Burn Down Rates)
- Write Code Once Instead of Twice — Shared code between app and web with the option to also support iOS
- Easier on-boarding for contributors
- Improve the Developer Experience
- More aligned technologies (we use React in the Web App and Website)
What could go against it?
Despite all the reasons to move to React, there are a lot of arguments against React Native in general. Some of them we picked up and looked at them more in depth.
(1) Stated Problem: React Native is less compatible with older devices (The old native app supports back to API 19)
API 19 is KitKat or Android 4.4. With RN we support backward to 4.1 (we only tested it with 4.4 devices). Globally, that means we are only missing out 0.6% of the devices and actually cover even more than most current Native Apps do.
Looking at the picture in Paraguay (South America and Africa just look the same): We have slightly more devices with Android 4.1 and 4.2 (around 1.4%).
(2) Stated Problem: _ React Native is slower on older devices _
There are countless statistics made on this. One report (where I also took the graph below from) is here: https://codeburst.io/react-native-vs-real-native-apps-ad890986f1f
Codeburst states it like this:
This is the biggest setback for me. If you’re planning to develop a complicated app such as an image/video editor, React Native isn’t a good option for you.
In our case (and most cases where you consider React Native), we are not creating a complicated app for video editing! Instead, we are creating a data collection application BTW: The graphs show that in some cases React Native is even outperforming Swift!
(3) Stated Problem: There is no React Native library to handle synchronization (offline functionality)
It is clear that an app that should feel like an app needs offline capacity. But with Poverty Stoplight we have an additional challenge. We are operating in countries like Sierra Leone where our app is used without internet for several days or even weeks and only 2G connections available.
Today, a bit over 1 billion people have access to high-speed internet, 3 billion have some access to the web, and over 5 billion people own a mobile phone. Every single year more people will be gaining access to the internet. Most of them will be mobile users, connected via low-speed, intermittent connections.For these people, offline support is not a luxury, it is basic accessibility. Read Bruce Lawson’s essay World Wide Web, Not Wealth Western Web for a deeper look.
Redux Offline is a technology for Offline-First Apps (and Web Apps). They have above 5k Stars on GitHuband wrote a very interesting article about the idea behind the framework.
At the moment we do not have a need for background sync but will look into it as soon as it becomes relevant.
(4) Stated Problem: _ A major concern with using React Native is the lack of long-term commitment to the project. _
We look into open-source projects very carefully and think twice before adopting something. The two key elements we always consider are:
- How much does this framework help me?
- How well is it maintained? Who is the guarantee behind it?
Both questions have to match the strategic position a technology has for us. How we look at our App: It’s an App that’s based on our API (there are multiple Apps based on the API so the API is much harder to change). We want to develop it for 3 to 5 years. It is an important part at the moment and we will invest a medium-level amount in the development. The functionality is very UI heavy not computing intensive.
We must remember that React Native is an open source project and is driven as much by its owner as its community. It would be crazy for Facebook to break React Native just to change it to what it wants. Looking at the Github Repository https://github.com/facebook/react-native, there have been more than 1,700 people contributing code to the project over the years with more than 13,000 issues that were identified by the community resolved. This is, in fact, a lot of commitment by a lot of people who think that the technology is important and valuable enough to help improve it.
We don’t see a lack of long-term commitment to the project at the moment. Every technology will be discontinued at some point (hopefully). Looking at it with a 3 years horizon and the current support and growth in the community, it seems to be a very solid decision.
(5) Stated Problem: _ React Native is still in beta, and breaking updates are pushed out directly. This makes it very hard for a small development team to maintain _
It is true, that RN is under heavy development and has gone through some major improvements over the last years. Compared to a more stable framework, this leads to higher cost in updating and a certain risk for breaking changes.
We expect the advantages related to time savings listed in the section above to outweigh those drawbacks.
One note to mention here: RN has been around for 3 years now and became more and more relevant. As we are moving forward we anticipate less breaking changes (or at least not more) than in the past.
(6) React Native was created by Facebook and so it caters to Facebook’s needs which can break things that you depend on.
Again referring to the contribution statistics on the React Native repository mentioned above, RN has to be able to listen to its community of developers and include their needs in the project to be as successful as they are at the moment. This is something that they have done to an extremely good level and the input has only improved the technology and made it more accessible and feasible for others to use.y
RN after 1 Year with 10 Developers?
Let’s have a look how RN scales. What do developers and companies report after using RN for a longer period and in a bigger team? That is the topic of a post with many answers: https://news.ycombinator.com/item?id=15293573
The question was, if it works in bigger teams and if those regret it after having at least one year of experience with it. Here are some answers:
We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is much faster with React Native than what we were able to achieve building natively. Our app has over 100 screens, and only needing to implement features once to have them on both platforms is nice. The feedback loop when making code changes is much faster, especially when writing unit tests. There are some rough edges, but the benefits far outweigh the costs for us.
Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. […] We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of native apps (native/react native/web views) with 90+% code sharing. We also added a bunch of features (regex based routing, etc) to help with seo. We do all of this from our single framework based on react.We had a lot of front end ‘frameworks’ in use and no consistency. Now we do. It’s been a lot of work, but for us totally worth it.
We also have done a bunch of optimizations to make react fast, including how we handle webviews in a react native/native app. It’s seamless. I’d like to link a video, but proprietary work that isn’t done…blah blah blah, company secrets, blah blah blah. We will be releasing another blog post, detailing all the native enhancements soon.
The team I’m a part of (~14 people) started building two new Android apps and transitioned our iOS apps to React Native a little over a year ago. Overall, I would call it a great success; we have four apps (2 iOS and 2 Android) built from the same codebase, soon to be 5, and React Native has allowed us to be incredibly nimble in developing the framework and features for them.Some things I regret:
- We didn’t go all in on React Native, keeping large portions of code in native in case of performance or security needs. This means that any given feature requires iOS, Android and React Native development. All of us are now fluent enough in each to do the work, but the context switching and debugging of actions moving across the bridge are a velocity killer.
- We didn’t realize that RN’s cross-platform integrations testing story was so poor; we thought that we’d “just use Appium, it’s perfect.” Nope — design decisions made by the React Native team actually make Appium unusable for our Android apps. This has forced a lot of churn in our testing strategy and we still have a lot of manual testing at this point. This is, IMO, the #1 thing that should be focused on either by Facebook or the React Native community.
At Penguin Digital we focus on using the right tools and helping our clients to make decisions that match their situation. We work alongside our client Poverty Stoplight to eradicate poverty! If you want to get to know more about some awesome technology, the penguins, and our work, do not hesitate to contact us or visit www.penguin.digital 🐧 and make sure to check povertystoplight.org 🚦.
Top comments (0)