I believe there is a wide misconception about developing mobile applications.

Many seem to think that the only proper way to create a phone app is by engineering it natively.

This splits codebases, increases costs, and consumes more resources. Depending on your needs and how fast it’s required to be done, this is not always ideal. Herein lies the cross-platform and single-source solution: React Native.

There was not an instance where I directly experienced a conversation about choosing between React Native and native. Throughout my career, I’ve always used tools or frameworks like RN to avoid this conundrum. While I believe that a project developed within a single source is the best way to go, I began to wonder why others might trust in the opposite.

Setup and Development time

You can iterate on development faster in React Native than in native development. I was surprised that setup time was basically negligible when I did it myself to compare native and RN.

React Native took just short of 5 minutes to get going while the collective time from Android and iOS app creation took about 20 minutes which excludes some environmental issues I ran into. RN springs your development time forward with all of the tools out there. There are many yarn and npm packages that solve a multitude of problems and/or provide utility, and they do it for both platforms.

For reference, I used a package that helped me manage push notifications for both platforms; Something that is normally specific to a platform. It saved me a lot of time because I didn’t have to develop two solutions for the same problem.

I think you’ll find that the fact that React Native lets you hit the ground running is a great benefit as time is the biggest factor when it comes to the cost of development. This lets us create a lot of momentum early which will lead to less hiccups and bottlenecks later.

A Case Study

Consider the following scenario: Your company needs a tool for internal use, and everyone uses their personal phones and/or you have a mixed bag of Android and iOS devices that are for work. Noone outside your workplace will be able to use it as it is made specifically for your business to do any number of things. In this case, I feel as though it is much simpler to go with RN.

Say everyone at your work has an iPhone, then you all might be inclined to go with the native approach which sounds easy enough. What if later on, during the development of the project, you hire someone with an Android device, or perhaps a current employee switches over. I would imagine that it’d be a tough sell to get them to switch devices, and now your app development time is doubled, assuming you don’t wanna start over from scratch with React Native.

What About the Device Features?

Also, if your app does need the capacity to perform low-level operations or get sensitive data, such as getting access to Location, Camera, Microphone, or even Bluetooth, you might think, “Native development should make this pretty easy.” While that is irrefutable, RN has tools that cover most of these options and are easily integratable.

“..things are never as complicated as they seem. It is only our arrogance that prompts us to find unnecessarily complicated answers to simple problems.”

- Muhammad Yunus, Banker to the Poor: Micro-Lending and the Battle Against World Poverty

I know what you’re thinking, “He said ‘most’, so there must be an exception.”

You would be correct, but that doesn’t mean if you suddenly need to add Bluetooth capabilities that it is impossible. Because of the fact that you have access to the individual platforms file structure (iOS and Android) within a React Native project, there are definitive ways to navigate around this situation; This most likely will not be as easy as it would be.

The Development Team

Having fewer people to coordinate with, when it comes to all stages of the software life cycle, is helpful because you’ll only field one team of developers for React Native versus having two for native projects.

A single band of engineers leads to the added benefit of maintaining a single source project and architecture.

As stated before, this is easier because you’ll only have one development team, so better communication, more fluid collaboration, and the ability to share resources between the engineers are all huge pluses. The two different teams that you would need for native development won’t be able to share what they’ve created. They’ll have to make everything on their own, yet you will come out with a look and feel that feels more natural for that device which some will argue is a benefit. With proper design in mind, this can be overcome when using RN because you still have the ability to use components conditionally depending on the platform, as the framework knows what device it’s being run on.

Testing with React Native

Now, when it comes to testing the application with React Native, your test suite will need to run on both devices, but you don’t need to make two separate flows, you just use one.

This might seem obvious, but I think it’s important to mention.

Having separate test suites for native development requires that they are checking all of the same behaviors and functions to verify that there is as close of a match as possible. This just spells time consumption because depending on how you chop up the verification and independence of these pieces, you can end up waiting on the completion of one side. Having one source for your project severely reduces any bottleneck that would likely occur if you need to get both native apps out at the same time.

Future of React Native

There’s one more important question left to address. What about the future of React Native?

I think the longevity of this versatile technology is dependent upon the lifetime of the age of smartphones. Once our personal portable devices transcend our pockets and purses into the next thing, RN will continue to retain its usefulness in the mobile space. It’s been around for a long time, and people still continue to update it because there’s always something new that it will need to support. In fact, a new version of it was just released the last month. As we keep pushing phones further by adding new features and hardware, there will always be gaps to close which can take some time to fill in. Hopefully, that is irrelevant to your situation.

To summarize, if your next mobile app needs to work on iOS and Android devices, doesn’t have to support brand new hardware features to run, or is required to be stood up very quickly; then you should be using RN.

This technology is powerful and useful in its own right. Consider using it for your next project because there are so many use cases that it covers, and it will continue to be relevant as it is always being updated by its maintainers.