How to build a successful app with React Native
In April 2021, Alex Adamec, Sr. Software Engineer at J.B. Hunt, presented a webinar hosted by Bugsnag about The Benefits and Challenges of Migrating to React Native. The engineering organization at J.B. Hunt migrated to React Native in 2018, and Alex delivered exclusive insights into their reasons for switching, their evaluation criteria, and the considerations they took to accomplish a smooth transition. You can watch the full on-demand webinar here.
After an engaging webinar Q&A, we were still left with quite a few submissions. Today, we’re sharing Alex’s responses to those remaining questions. We hope you find the information helpful if you are currently migrating to React Native or simply curious to learn more about the development platform.
Q: Why did you not consider building the app natively?
A: [Alex] Fully native apps are expensive to develop and time consuming. If there was a cross platform solution which offered the same performance and quality of fully dedicated solutions, would anyone not opt for the cross platform option? I think for our organization we considered the hybrid app solutions available at the time (and certainly today) to match the native iOS and Android apps closely enough to make it the preferred option. Also, while our mobile app teams have grown considerably over the last few years, at the time we began the re-platforming of our Carrier 360 mobile app, our team was relatively small. If your team is large enough to support the development of two separate codebases and your app is highly complex, utilizing a large portion of platform-specific code, it might justify the higher cost and development time of building the app natively.
Q: What drove the choice of Redux for state management?
A: [Alex] Unfortunately, I wasn’t around when the decision was made to use Redux, so I can’t provide insights into our specific reasoning for choosing it. In general, as your application grows in complexity, it can become tricky to manage with React alone. It is doable of course, but Redux can simplify the process, and make the code easier to maintain and test. The Redux FAQ addresses the question if your organization needs help deciding whether to use it or not.
Q: Is the “80% test coverage” requirement exclusively E2E, or a mix or E2E and unit/integration testing?
A: [Alex] Our code coverage requirements are for unit testing — measuring lines of code covered, branches, functions, and statements. We do not currently track code coverage for our end-to-end tests.
Q: Any quick suggestions for multiple input handling in a form?
A: [Alex] We opted for using redux-form when we built the app, but it is now in our backlog to migrate away from it. We haven’t yet prioritized switching to a different form library, so I can’t provide a firsthand recommendation. But, I would caution against using redux-form if you were considering it; the redux style guide recommends avoiding putting form state into redux, and beyond the performance concerns of dispatching actions on every keystroke, I found the documentation for the library to be quite poor (subjective of course). Formik is a library that is on our radar, and I’d suggest starting your search there.
Q: Do you use Bugsnag for monitoring network request errors in React Native? If so, do you have a Bugsnag notify inside your axios/fetch middleware? Or do you have a notify call for every individual request?
A: [Alex] We use other tools such as Dynatrace in addition to Bugsnag for monitoring our network requests, but with Bugsnag, yes, we use Bugsnag notify. Each individual request routes through a singular request function which handles the fetch and uses Bugsnag notify to report failures with the url, method, etc. and with metadata for the response.
Q: What tools and technologies do you use? Do you use webdriverIO?
A: [Alex] For state management and side effects we’re using Redux and Redux Saga. We use React Navigation for routing and Branch for deep linking. Rollout.io and Firebase are used to handle feature toggles and remote configuration. Native Base was the component library we started with, and React Native Maps is the library we chose for mapping components. Of course, we’re using Bugsnag for error monitoring. Jest is the testing framework we use for our unit tests, and we use WebdriverIO with Appium for our end-to-end tests.
Q: Could you give an order of magnitude when it comes to dev productivity (between supporting a React Native app vs. supporting 2 native apps)?
A: [Alex] When supporting separate apps, every feature has to be coded twice. This likely requires two separate teams and two separate testing and deployment pipelines. On top of this, the two separate streams require additional planning and oversight to remain in sync. At best, you might have a team of developers which is proficient in native development for both platforms and avoid the cost of two separate teams; however, it’s unlikely that the team will be able to develop the code for each codebase twice as quickly as that of a React Native team, meaning the time to market is almost assuredly higher. Providing a singular, accurate number isn’t feasible in my opinion — there are simply too many factors to sum it all neatly into a definitive value —, but the simplest answer would be 2. If you assume the time to produce a feature in React Native is identical to the time needed to implement said feature in iOS and likewise for Android, then the simplest answer is that the same app produced using fully native development would either cost 2 times as much or take 2 times as long.
Q: What are you using for styling?
A: [Alex] We’re currently using the Native Base library for components and theming, but we also have a separate team working on a design system for our mobile apps using the React Native core components and React context to handle theme switching.
Q: What did you use for location services/tracking?
A: [Alex] For positioning, we’re using the react-native-background-geolocation library and react-native-maps for mapping.
Q: Have you tried a Penetration Test on your app?
A: [Alex] Yes, we have a Security Engineering team which tests our applications for vulnerabilities and notify our application teams with their findings.
