React Native has been with us for a while now. It was launched in March 2015, which means this month it’s turning five years old. I started working with it three years ago when it was in its initial phases. It became popular for three main reasons:
- Airbnb was using it, and they were blogging awesomely about it here on Medium.
- It was used and open sourced by Facebook*.
- React is a great JavaScript library.
*It’s important to clarify not all of Facebook was built with React Native but only some parts of the app.
I have no idea how I ended up in a project using React Native for almost three years. The great thing is I can’t say I regret it because that experience took me out of my comfort zone and made me a better developer. Being on both sides of the mobile world gave me a greater perspective and up to today, I keep seeing tons of companies willing to use or already using React Native.
If you have a doubt, just head to a startup page like AngelList, and you’ll see how many startups are looking for React Native engineers.
What’s React Native?
Before anything else, we should look at the definition of React Native. The problem is if you look at their website and documentation, there’s no about section or a formal definition. The closest thing to it I could find was the introductory lines of the GitHub repository:
“React Native brings React’s declarative UI framework to iOS and Android. With React Native, you use native UI controls and have full access to the native platform.”
So basically, React Native is a JavaScript library that allows you to use native UI controls and everything in the native platform.
React Native states, “Mobile apps built through them are indistinguishable from a ‘real’ mobile app”
The above was taken from React Native’s webpage — here’s the complete quote:
“With React Native, you don’t build a ‘mobile web app,’ an ‘HTML5 app,’ or a ‘hybrid app.’ You build a real mobile app that’s indistinguishable from an app built using Objective-C or Java. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. You just put those building blocks together using JavaScript and React.”
I’ve been a mobile developer for about eight years, and up until today, I had no idea what a “real” mobile app could possibly be. As far as I know, all apps in the App Store, no matter their technology, are real.
What they mean by this is that most of their React components have an equivalent in either Objective-C or Java, and when the app renders, the result is native code.
Is It Really Faster Than Developing Native Code?
There’s a bit of an obsession in the technology industry, and in all our society in general, on speed. Projects like mobile applications are complex. We overlook the fact that developers are crafting something, and speed is a subjective concept.
But aside from the idea of fast or slow, in a more technical way, React Native is not faster, it just enables you to deploy your apps to both platforms (and possibly others) with the same code.
But when it comes to bug fixing, which is the most time-consuming activity in software development, issues will be found separately in Android and iOS. In my experience with React Native, the time you saved by deploying in both would be lost in fixing platform-specific bugs.
You Just Need a Developer Who Knows JavaScript, and They Can Get the Work Done
After my first project in React Native, I helped build other React Native teams and also interviewed for a couple of roles on this technology. There was a constant phrase I heard from recruiters and people who had worked in React Native.
“Yes, you need to know JavaScript, but we also would like to have someone in the team who has done native, too.”
If React Native is so easygoing, why do you need someone who has done native?
- Some of the native features of Android and iOS aren’t available in React Native, and if your needs are very specific, you’ll need someone to add things in native code and then bridge them to JavaScript.
- Native developers better know the tools to debug apps in Android and iOS. And even when React Native generates all the code, you still deal with the native tools for specific bugs.
- Native developers simply know their platforms. When you work with a platform in your day to day, you know its setbacks. They know the bugs that come from one model of hardware. They know the bugs that happen after an OS update. They know just by experience what or where things need to be fixed. The same happens with a JavaScript developer in the JavaScript environment — they just know. But here you’re trying to mix three different profiles into one person.
If You Know What You’re Dealing With When Choosing React Native, It’s a Great Library to Use
Like many mobile developers, I’ve worked in a bunch of different platforms and languages. I used to have a boss that said great software engineers would be able to adopt a new technology’s basics in around two weeks of constant dedicated study. Maybe this is a bit of an exaggeration, but someone with the passion to learn and to work on a project will get through it.
The problem isn’t technology. Developers aren’t the problem either. The thing is we keep on searching for the fast and easy solution that’ll get us through successfully without effort or investment.
That simply won’t happen. React Native is an alternative, yes. If you ever want to use it on a project, make sure you keep this in mind. React Native is an alternative technology with advantages and disadvantages like any other — which doesn’t mean it’s a shortcut.
Thanks for reading.