Thoughts about React Native after a few months working with it

I faced the following challenge in January:

• Porting a complex webapp to native Android and iOS. The web-app to be ported is written in ReactJs+Redux. Besides most of its business logic is in a pure ES5 javascript library.

So in this situation, React Native (“RN” from now on) seemed like the way to go as we wanted to have a working prototype in a month and it should be maintained in both Android and iOS without extra resources.

Misconceptions

Some possible misconceptions about RN that I’ll talk about:

1. RN is a solution for pure developers who only want to know a bit about mobile native development. (?)
2. RN means learn ‘once’ and write anywhere (?)
3. RN might not make sense if you are a proficient mobile native developer (?)
4. RN in the worst case can perform too badly to the point of having to rewrite everything to native when it’s too late. (?)
5. RN allows to reuse tons of code among platform (?)
6. RN is fun (?)

Let’s divide and conquer the discussion in different points and in the Summary we’ll get back to this points.

Tooling and learning curve

Minions in tech posts are a must.

react-native run-platform little disappointment

I’ll avoid talking about Expo as I cannot rely on it because I use a few native libraries that require the app to be ejected. So, the first experience creating a RN app is pretty cool, you just do react native init MyNewFancyApp and there you have a hello world which you can run with react-native run-PLATFORM

Do both react-native run-android / run-ios work as you would expect? Well, more-less:

• react-native run-ios compiles your iOS project, including native dependencies, links the project and runs Metro so that the JS code is bundled and offered by a Node server running on your laptop. Finally it runs your app in a Simulator target.
• react-native run-android compiles your Android app with Gradle and also runs Metro the same way but there’s a difference: it won’t start an emulator or simulator, it will try to run adb install against whatever is attached to your laptop: an emulator running in Genymotion, a real device connected to USB…

You get used to keep an eye on this.

This is the first little difference you find between using RN against each platform and this is just about tooling. react-native run-PLATFORM has different behaviour on Android and iOS. Actually, if you want to run your RN app in your device react-native run-android will work fine as “adb install” works both for emulator and devices the same way whereas react-native run-ios is only enough for running on the simulator. You’ll need to run Xcode to run it in your device. You might think “not a big deal” and you’re right but it turns out RN is full of this kind of details that could be improved and make dev experience better.

A RN app is a native app so you’ll need to learn mobile native stuff to certain degree

You’ll see react-native init basically creates a Gradle Java android project under /android folder, a /iOS project under ios folder and a /index.js to start the RN app.

You might think you won’t need to care about those autogenerated native projects and just about the JS and you’ll be wrong.

Every time you link a npm RN library containing native code (with react-native link) you’ll see how it patches your projects, and sometimes it won’t be enough and you’ll need to do some manual changes to integrate such libraries correctly. This means you cannot be a zero native knowledge developer to use RN, you’ll need to get your hands on those native projects from time to time. Don’t cry about it, embrace it as this will rarely change as RN is basically about patching those native projects that you scaffold initially over and over again and you’d better check what changes you introduce “automatically” when you link new libraries. It’s a good practice trying to understand the generated patch every time you run react-native link .

Does this mean you need to know both Java and Objective-C to be a productive RN developer? IMHO Yes.

I enjoyed this book but not sure why there is a bicycle there.

For Java there are plenty of books you can use whereas for learning Objective-C I can recommend Objective-C Programming: The Big Nerd Ranch Guide (Big Nerd Ranch Guides) 1st Edition. You can also learn Swift but you’ll see that you need to learn Objective-C anyway so that should be your priority as most of RN libs are written in Objective-C and your /ios RN generated project is in Objective-C. Same happens on Android with Java, you can learn Kotlin too but your autogenerated project is in Java and most of the libs you’ll use are in Java so it should be your priority if you have no knowledge of it.

There are other examples that enforce the idea that if you want to do serious RN job and you only know Javascript you really should learn mobile native languages anyway is that there are simple things such as changing the background of your app or tweaking the splash screen that you simply cannot perform just with Javascript. These are more exceptions than the general rule but you don’t want to limit yourself anyway. I can mention that you probably need to change AppDelegate.m when using certain libraries, and those libraries typically have some code you can copy-paste it but they don’t tell you how to mix different libraries there correctly, that’s something you need to do with care and at least some Objective-C understanding.

E.g some libs tells you to add a continueUserActivity method in AppDelegate.m which can collide with other libraries you had and you might need to figure out yourself.

Just a simple example of supporting 2 libraries at the same time in continueUserActivity

At some point, you might need to create a native module yourself. RN documentation documents two examples about how to do it so you can see that the vision of RN is not about avoiding any native development, it’s more about boosting productivity and sharing business logic and practices among very different platforms.

Debug mode and runtimes

Usually, when you’re developing with RN you will be using DEBUG mode. You’ll soon discover that running your app that way means that your JS code is being run by your laptop browser which is important to have in mind as in Android especially you can hit important differences that will make you introduce extra polyfills. E.g Symbol._iterator issue.

My advice for this is clear: test your JS code often in your device/simulator, don’t live in the browser runtime all the time until a bad surprise comes too late when you thought your code was already ready. You might think, Tests!: well, that kind of problems will be detected if your running those tests with the device runtime, otherwise won’t be detected either 😦

In practice, I’m usually developing with both Chrome and an iOS device runtime and I check from time to time on Android and It’s common finding a surprise to fix. It also depends on which is your prioritized platform, in my case I focus on iOS first and I care about nailing Android with less priority. You cannot assume things just will work in every platform out of the box.

Testing

Testing in native platforms is mature so I was not sure about whether I would be comfortable with RN in that regard. Luckily it’s pretty good, it takes some time to get used to the way dependency injection is done (basically ES6 imports and props) but Jest testing framework rocks and storybooks + snapshots is pretty cool. Besides, as Redux is the de facto standard to develop RN apps that’s a part which is testable by default as it enforces using pure functions. Perhaps I miss that in RN world is common seeing native libraries with no test coverage at all, my recommendation is checking the project README and the issues first as a project that seems great at first glance might be better to avoid for not being maintained or being buggy. You’ll find there are lots of react-native-foo libs that expose “foo” native APIs but the quality among them is different and there are different libraries doing the same thing with different level of quality.

Organizing your code

About organizing your code, don’t assume you should do it the way you see in the basic examples, consider them just a starting point to having something working but not something maintainable in long-term. E.g avoid adding all your business logic directly to your components, favour pure functions (using Redux is a must), extract redux part from component to containers, find a consistent way to organize your styles instead of just having them spread in your components and in general apply any good practice you know from other languages/frameworks even if you rarely see them in common RN examples.

One more thing: sometimes you’ll find you need different code depending on platforms, think carefully about how to do it as the typical “if(platform == ‘ios’)” can be a first working approach but you should try to wrap those blocks in generic classes or components which deal with the differences internally so that you don’t have lots of platform branching in your main business logic.

Preparing builds

Preparing release/alpha RN builds is as complex or even a bit more than preparing classic native ones as you also need to care about the JS bundle. Luckily you can automate with fastlane, something you should really do to avoid the pain of preparing them manually. Besides you can consider using Codepush so that you can avoid preparing new builds unless you’ve really changed native dependencies.

Performance

This was one of my main doubts about RN:

1. Most of your code is in JS and Javascript code does not run in UI thread, it has its own background thread. This is great for someone used to Android development where that’s a typical problem when running your code. In RN if you have bad performance because of your JS code you won’t be affecting UI thread as JS runs in a different thread. Besides the async nature of running your JS code makes deadlocks unlikely, something that I’ve seen happening in Android depending on the practices.
2. Performance issues are quite easy to detect thanks to libraries like slowlog and snoppy. With slowlog you can monitor whether components take too much time to mount and with snoppy you can watch whether you’re having excessive activity in the RN bridge.
3. There are lots of little easy details to care of like disabling console logs for production, typically avoid blocking JS event loop, profiling your app performance.. You can read more about them in this nice documentation.
4. Just avoid doing animations with the Javascript thread, search for native libraries that can help and useNativeDriver flag in animations.

The RN bridge

RN bridge is an important thing to understand as RN developer. Magic does not exist, in RN either. Your JS code runs in a background thread and your native modules run on their own background threads too so how does your JS code communicate with your native modules?

How is a call from javascript translated to native land?

Well, basically the message object you want to send to the native API that will send the message is serialized so that it can be communicated to the other thread, and then it’s unserialized in the native thread side. That’s basically the bridge and it has a cost. If you are doing too many communication from JS to Native or vice-versa that will degrade your app, those calls are actually batched but It can become a problem anyway. That’s a bottleneck as other code that needs the bridge to run will need to wait.

How can you take care about this? As I said you can use a tool like snoppy to monitor it. If you rarely see high peaks in such bridge, congratulations! You’re achieving native-like performance in your react-native app. Otherwise, you’ll need to do something about it. What? Well, if those peaks are quite rare you can try to improve the UX when they happen… whereas if they really affect the user experience or battery you might need to port some JS code to a native module because that’s something to take into account.

Pure JS libs vs RN native libs

Related to this you’ll often find different libraries that try to do the same thing but one does it in Javascript (always using JS thread) whereas the other one requires adding native code to your android/ios native projects. The pure JS library is probably easier to set up whereas the one including native code will require a react-native link in the best case (+checking the patch carefully) but It can also happen that you need to use Cocoapods and you might need to apply some monkey patches yourself. You need to evaluate each case because such “pain” might pay off. An example of this is choosing a navigation lib for your RN app, I prefer react-native-navigation to react-navigation.

A kind of magic

It can be interesting checking the RN repo to see the magic under the hood.

E.g: In BatchedBridge/MessageQueue.js you can see the enqueueNativeCall method:

In that method, you’ll see method and params data are pushed to _queue and that queue is flushed from time to time. calling global.nativeFlushQueueImmediate(queue). And what’s next step? If you look for nativeFkushQueueImmediate you’ll see you land into C++ world and you can see the interesting part where the queue is JSON serialized. From there you go NativeToJsBridge.cpp where you can see the implementation of both JsToNativeBridge and NativeToJsBridge. CallNativeMethod is finally run in ModuleRegistry.cpp and after that you’re already in platform specific area, e.g you can see the actual call being performed with reflection in JavaModuleWrapper.java whereas I think that job is done in RTCNativeModule.mm for iOS.

RN is fun 🙂

So why RN can be more enjoyable for a native developer?

Basically because you rarely need to recompile your app unless you change the native dependencies, something that you’re not doing N times a day and not even N times a week probably whereas you’re probably changing templates N times a day, or business logic, or assets, or colours… And those things in RN are in JS and you can just refresh and see the changes almost instantly! This makes RN development cycle way more similar to web development as the feedback cycle is way faster and you can be way more time in the zone having fun as a happy developer as you don’t need to be multitasking to find other little things to do at the same time your app is being rebuilt, even if your app is small and just takes like 30 seconds to rebuild that’s still way more than what JS code takes to be loaded again. You can even enable hot reloading! and you’ll see how your app changes as you change JS lines.

In Summary

So, when do I think react-native is a good idea as of today? IMHO it worths seriously considering if:

• You need to port a web app written in ReactJS+Redux to Android/IOS which is quite complex and just runs fine.
• You want to prototype a native app fast. I avoided talking about Expo but check it out, if you’re lucky and you can use it it can be a good extra developer performance boost.

And when do I think it might not pay off?:

• You have enough amount and good mobile native developers to develop the app for each platform.
• You already have solid native apps for each platform, rewriting them to RN might not make sense unless you want to reuse web version business logic.

And lastly, let’s review the possible misconceptions I talked about at the beginning:

RN is a solution for pure developers who only want to know a bit about mobile native development.

FALSE: you need to understand those android and iOS folders, you need to be able to install RN libs including native code and you even might need to write your own native modules!

RN means learn ‘once’ and write anywhere.

TRUE but… you need to learn as much as you can for each specific platform.

RN might not make sense if you are a proficient mobile native developer.

FALSE: productivity can be quite bigger in RN and that can be a good reason to adopt RN.

RN in the worst case can perform too badly to the point of having to rewrite everything to native when it’s too late.

FALSE: in the worst case you can migrate JS code to native code.

RN allows reusing tons of code among platform.

TRUE: In the app I built, the whole redux code is the same in RN and ReactJs and that’s where most of the complex business logic is. Besides code differences between Android and iOS are just some UI details here and there to improve the experience for each platform.

RN is fun.

TRUE!: See the minion “Fun” part 🙂

I hope this blog post can serve others introducing to this framework which is nice and powerful but there are a few things to consider or it’s easy to be disappointed.

Originally published at ivanmosquera.net on May 19, 2018.

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.