When it comes to mobile development, we often have to make a decision: either develop separate native apps for iOS and Android, or develop a single React Native app. At a first glance, the choice might seem obvious. It’s so tempting to have only 1 team of mobile developers instead of 2. But there are many things to consider, so let’s take a deeper look.

Look and feel

React Native apps look just as fine as Native apps. That’s not a surprise: both approaches use the same native UI components. The key difference is like a time bomb here: Javascript (the language of React Native) is much slower than native code, so the bigger your app gets, the bigger difference in performance there is. If you go with React Native on your big project, after couple months of development you might start noticing that the app takes a while to load, and the overall UI responsiveness is not perfect anymore.

Development speed

What is better: having 2 native iOS and 2 native Android developers, or having 4 React Native developers?

Based on our experience, building a small React Native app is about 30% faster than building 2 Native apps.

Why only 30%? It should be 2 times faster!

Well, 30% is actually an optimistic number. React Native can even get slower than native development in some cases. It all comes from one sad fact: the conditions are not equal. Native developers have advanced IDEs (XCode and Android Studio), larger communities and better documentation.

React Native adds an additional level of complexity on top of native SDKs (and brings its own bugs), so the apps are harder to write and maintain. Native iOS/Android developers gain instant access to all the latest features, while React Native developers have to wait for a while (and are not guaranteed to get those features at all: React Native’s roadmap is pretty uncertain).

And another factor is that React Native as an SDK does not cover everything native SDKs do: it certainly does make it a lot easier to write a simple todo-list or a Twitter client, but once the project requirements go beyond that, React Native starts lacking features. Native developers have access to a huge variety of third-party frameworks and libraries, while React Native developers have a much more limited choice.

Good news is that those native libraries can still be used in React Native, but it requires writing and maintaining an additional layer of codebase acting as a bridge between objC/Java and Javascript.


Just like anything else built-on-top-of-something-else, React Native doesn’t solve any platform-specific problems, but rather introduces the new ones. With React Native, most of the codebase is written in Javascript, which makes the app a lot easier to decompile (reverse engineer) than a native app.

On a product level, you have to agree to Facebook terms and conditions when developing a React Native app.

There are 2 concerns: the first is that the support of React Native project can be stopped any time. Facebook does not guarantee anything. The second concern is of a legal matter: if you initiate a legal lawsuit against Facebook, your React Native license will be instantly terminated. This is definitely a detail worth keeping in mind.



Although React Native has an advantage of sharing a codebase between iOS and Android, it comes with some disatvantages. So how do you make a decision? It all boils down to the following questions:

  • Are you planning to develop a small app like a cookbook, or a sophisticated solution like a social network? React Native works great for simple apps, but becomes a problem if you have bigger plans.
  • Are you working in finance or healthcare industry? If the app is going to interact with highly sensitive user data, it’s better to go native.
  • Are you a startup that is looking for a proof-of-concept app? React Native would be the best choice for you. But be prepared to throw it all away if you decide to go native after the POC: React Native and native apps are completely different on a codebase level, and the app cannot be simply migrated from one technology to another.

Here at Bekitzur we have huge expertise with both technologies, and this choice is really just a matter of choosing what’s best for you.

Alex Ulyanov, CTO

Alex is CTO and hands-on thought-leader for the technical talent portfolio at Bekitzur, Alex is responsible for devising and executing architectural strategy and scaling engineering operations for Beliuts’s customers. He and his team have own integrated Product development at our client companies including GE Digital, Zypmedia, Origami Logic and Thinfilm. Alex is an AWS Certified Professional Solution Architect.

View posts by

Talk to Us