user-icon Michael Ruhl
18. January 2021
timer-icon 3 min

When to use React Native

I first got in touch with React Native on UIKonf 2015 (an indie iOS Conference in Berlin). Besides some talks, Facebook presented in a workshop their two month old cross-compiling framework.
I was intrigued by innovative features like the Hot Reloading functionality and that you can distribute updates without submitting a new app to the AppStore.

On the other hand I was not very excited to use Javascript, when around that time I just started using Swift.
Back then it was still limited: On iOS not every component was supported and Android was only on the Roadmap for the future.

Times app

When we started in 2019 developing our internal time-tracking app (called Times), we needed it for iOS and Android. So we decided to do our first React Native project.

I want to share my experience with you, when I would suggest using React Native for an app.

1. Custom Design

React Native is best, if you don’t want the vanilla iOS and Android Design, and instead want a custom design with both version to look alike. For example if the company or the product itself has an already established design.

React Native uses native UI, unlike other cross-compiling frameworks, but not in all places you would expect. Take for example a table like you would know from the Apple stocks app:

This will be difficult to do with React Native, because the underlying table does not use the native components.

Instead of using an UITableView, it has a custom implementation with UIScrollView and UIViews.

This means, you can use it well if you have a custom design shared between iOS and Android, but it is not recommended, when it should look like a stock Apple or Google app.

2. Have also a Web app

React Native like the name suggests is based on React. React is a web framework also developed by Facebook. Therefore you can share code between mobile & web apps, if they are built on React, which is something other frameworks currently cannot compete with.
It’s not that you will only need to write everything once, but rather you are able to reuse some components & business logic and to have one united development team, that can take care of mobile & web.

3. Developers are okay with Javascript

Sometime ago, there was a real buzz, that Airbnb switched away from React Native. So you could read everywhere, that this is the end of React Native, but it’s important to not just read the headline and rather listen to the reasoning behind it. The main problem was: The developers wanted to develop native and not in React Native and Javascript.

For Times we used Typescript, it’s not perfect, but better than Javascript of course 😉

So if your development team is biased against that technolgy: It will not work out.

4. Only an app

This is the case for most cross-platform frameworks: They are great to develop an app, but it will be difficult to do anything outside the app context.

In an app, the platforms allow a lot of freedom for rendering other things, that cross-platform frameworks make of it. But outside the app context, there is not so much freedom, for example for battery saving purposes. This for example applies to widgets and watch integrations.

You only want an app, and do not care about a deep platform integration with extensions and everything.


React Native has its advantages and limitations that you need to take in consideration. If you have the right use-case and development team it can be a good way to develop apps.

In our case, we were happy developing Times with React Native, and already working on the next app.

Comment article