6 things to consider before you start with React Native

“act like you’re shooting lasers” credits: Michał Rosiński

Some time ago, I came up with the idea of a mobile application; one that I would use personally, but with the aim of publishing it someday. Even though I’m a Java developer and I have some experience in Android, the multi-platform possibilities and React-like nature convinced me to try out React Native. Here’s what I’ve learned:

It’s good because it’s React

I’ve been working with React in numerous projects already, and it only gets better. It’s a library rather than a framework, so it lets you compose your own favorite pack of libraries. You’re new and you want to be efficient from the very first day? Good. Or maybe you’re an advanced React developer and need more complex tools? No problem. Thing is, React doesn’t usually get complex where it doesn’t have to.

It’s really native

To be honest, you don’t need React Native, or any library/framework in that place in order to create a multi-platform mobile application. You could accomplish that using WebView (browser bundled inside the app) and point to your web application from both platforms. At first, it might sound reasonable, and in some cases it probably is. Thing is, it’s a trade-off. WebView application performance isn’t great. The visual effects that users expect from a decent mobile application are not there. Handling complex gestures is troublesome. I could go on, but in general, the WebView application won’t provide a user experience comparable to a native one.

On the other hand, React Native compiles down to the platform’s native code. We can make use of underlying mechanisms that are unavailable in the bare WebView application, like background tasks or notifications. And it’s faster.

Work efficiency

Oh boy, it’s great. React Native makes it possible to work in short development cycles. It’s important to me especially when I design a new component and I want to see how each approach might look like. Thanks to hot reloading and very fast bundling, you won’t have time to browse all the cats and memes in the meantime. I recently switched from a real device to an Android emulator. By keeping both the IDE and emulator on one screen, I don’t have to pick up my phone every damn time. Gotta go fast.


For the sake of a low entry point for web developers, the React Native style system works almost like the CSS. Almost. If you’re an experienced developer and you leverage many of the CSS features, you might find yourself disappointed. There’s no cascade, limited inheritance, many properties are not supported. So you may struggle with drawing complex shapes. But maybe I’m complaining too much. The style system has its flaws, but it’s efficient nonetheless. It’s easy to use. If you keep your components small, both UI and styles fit on a single page. Every element is flex by default, and I like it. Oh, and definitely check out react-native-extended-stylesheet! It’s a library that makes styling great again.


The React Native community is huge, and there are hundreds of libraries ready to use. Unfortunately, some of them don’t get enough attention from creators or maintainers, and things start to get wobbly when you upgrade to a new React Native version. But here comes Expo. It’s a toolbox for React Native, helping to deliver fast and reliably. It consists of many useful APIs, has truly awesome build facilities, like building and storing artifacts in the cloud and even automatically updating your application in the background for the users that installed it through App Store or Google Play. Unfortunately, it still doesn’t provide some crucial APIs, so make sure that Expo has what you need before relying heavily on it. Here you can check what’s still missing and what the status is. As you can see, background tasks are not supported yet. Even though they are crucial to my app and I had to eject, I’m hoping to see Expo developing its features, because it brings the stability React Native needs.


Me and my colleagues at Pragmatists work in Test-Driven Development methodology. This means we write a test before any implementation is done. You may know this already from my previous post. No surprise, I wanted to do the same with my fresh new project. Yet the reality struck hard. I wanted to set up Jest along with Enzyme, as this was my primary choice. I learned fast that this is no use since I can’t mount components in React Native (if you did manage to set it up, let me know!), and shallow testing wasn’t the pathway I wanted to follow. Also, it didn’t work reliably anyway. I started browsing blog posts for how to test React Native components and to my surprise, the main trend is snapshot testing. Not only can you not test-drive your application with snapshot tests, but also, they bring little value and are very fragile. Summing up, there’s definitely potential to improve in this aspect. Eyes on you, React Native!

Wrap up

If you asked me if, everything considered, I’d start an important project in React Native, I would. Even though it lacks something here and there, I’m still amazed by how easy it is to transition from web to mobile. In this post, I’ve only mentioned things that are important to me. I’ll gladly hear out what you think of React Native.