React Native 2 years later, the story


6 years ago when ideal systems started to develop mobile apps, there was not much choice regarding development platforms. More specifically, platforms that allowed to handle multiple target platforms like iOS, Android and Windows, while using the same codebase. Therefore, after an analysis of development frameworks, we chose Cordova as our platform.

First platform used: Cordova

There was not really a problem using Cordova for small apps. However, we noticed that when the apps became more complex, the single JavaScript threading model reached its limits. As a result, the performance was slow and the behaviour was sluggish. The main reasons why we chose Cordova at first was:

  • the possibility to update the app without a new download,
  • the possibility to update the app without passing by the app stores.

As we kept in mind what we had learned so far, we conducted in 2016 a new analysis regarding the new available platforms and chose React Native.

Transition to React Native and Redux

Through the development of our first app, we encountered some restrictions of the framework (at least we thought so at that time):

  • state management,
  • updating the code in real-time,
  • a skeleton framework,…

In order to solve these ‘shortcomings’, we looked at the community for solutions. As a result, we chose Redux for state management.


The advantage of Redux is that the state of the object can only be changed through an action. This means that there is no two-way communication between the layout and the store. All communication follows the same pattern. This results in clean code, easy debugging and above all no ‘magic’ happens behind the screen when syncing store fields and layouts. An additional advantage of Redux is the characteristic of forcing its users to work with some kind of skeleton. This skeleton includes actions, reducers, components,… which results in a more legible code.

After a rewrite of our initial app, using Redux instead of Flux, we finally got a clear understanding about the advantages of React Native.

As soon as the skeleton was in place and the basic framework functions had been implemented (network on/off, device foreground/background, REST functions, push notifications,…) we rapidly advanced in developing the user interface. Once you get the hang of it, the development goes really quick and the multi-platform aspect was also straight forward.

Creating native modules

Next step was making our own native modules based on external SDK’s (like WebRTC). With some of the SDK’s we encountered some issues preventing them to be integrated in React Native. Mainly the SDK’s including visual layout could be an issue. SDK’s that only provide functions – without layout – did not cause any problems.

One of the shortcomings of the React Native bridge component is that all communication with the native components are done asynchronous. This means that if you need to wait for results from the native side and then want to continue in the app, there is no solution at the moment. The React Native team is working on a new architecture (code name Fabric) that allows synchronous communication. Moreover, it will also be possible to hook your own JavaScript engine! This brings us to the next part of the story, React Native’s version management.

React Native’s version management

Each month there is a new version of React Native. This implies that, if you want new features and bug fixes, you need to keep up with your code to get it running with the newest version. Additionally, the current version 0.X is not officially supported. The first official supported version (as seen on Facebook’s blog) will be the 1.X version including the new architecture. This new version will probably be launched in 2019. Although, no official word on this topic yet.


At the moment, we have a full-grown application build on top of React Native that is working at 60 fps, where this was previously the bottleneck when working with Cordova (and the reason why we chose React Native).

In summary, I would say that we have made the right decision and are very thrilled with the next developments that are going to happen. Even now, when other frameworks like Flutter pop up, we are still convinced about our decision and will continue using React Native.

Article written by Dirk Slootmaekers (CTO at ideal systems)


React Native 2 years later, the story
  • Get in touch

    Do you have a specific question, comment or inquiry?
    Simply fill out the form and we'll get back to you soon.

      I agree to the ideal systems privacy policyI agree to the ideal systems privacy policy