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
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):
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.
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)
Do you have a specific question, comment or inquiry? Simply fill out the form and we'll get back to you soon.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.