ACA Blog

ACA Blog

August 2021


How development in React Native helped us start the app revolution – pt. 1

Yakup KalinYakup Kalin

Recently, the Belgian virtual network operator Mobile Vikings launched its totally renewed My Viking app, developed in React Native. As its app developer, we were incredibly proud to release the app to a user base of over 270.000 users! This renewed app introduces a fresh new user interface and a ton of new features, such as the Viking Deals, detailed usage lookup and drill-down capabilities.

How development in React Native helped us start the app revolution – pt. 1

In this blog post we will discuss some crucial technical aspects we dealt with during our development in React Native and provide some valuable technical insights regarding React Native development.

Plus: some bonus content regarding multilingual support within your app (i18n) at the end of the blog post! Curious? Read on!

Why Mobile Vikings wanted to renew their app 

Mobile Vikings already had a Viking app for their Android and iOS users. They had developed this Viking app internally using Objective C/Swift for iOS and Java for Android. The choice to use specific native language for both OS made it possible to deliver a fully native and integrated app experience on both platforms. 

When the time came to recurrently add new features to the app at a quick pace, an infamous problem became inevitable: doing things twice. The choice of going native meant developing (for) the Viking app two times (for both native languages) with mostly the same user interface, features and copy. It was also getting harder and harder to keep up with the demand of integration of new features.

If you are interested in the whole case, you can read a more detailed story behind this in our Mobile Vikings case study here.

Why we chose React Native

Before even being able to write a single line of code, there was one crucial question that needed to be answered. Which mobile framework or tool should we use to develop the new My Viking app? There are a lot of frameworks and tools available for developing mobile apps, each having important advantages and disadvantages. There’s Xamarin, Appcelerator Titanium, React Native, Ionic (Native), NativeScript and probably many others. So which one should we pick?

To answer this determinant technical question, we needed to consider several important aspects:

How development in React Native helped us start the app revolution – pt. 1Once we all covered those important questions together with Mobile Vikings, the winning mobile development framework became clear: React Native. Especially the learning curve for the development team, modular and intuitive architecture (that is similar to React), the community behind React Native and the level of reusability of the building blocks caught our eye. And so the app revolution in React Native began.

Are you having difficulties choosing the right framework for your mobile app or solution? Get in touch with us and we’ll glad to give you more insights that’ll help you making the right decision.

Setting up development in React Native

Creating a new React Native project is pretty straight forward. When we created our project, we typically considered things like:

By separating and organizing those project files, we increase the maintainability since every type of file/code will have its specific agreed location. A very dull yet important step to keep in mind!

Sharing logic across screens (state management)

Developers that are familiar with React Native know that you deal with ‘state’ within React Native. A state is a type of data (that can be changed) that controls a component, e.g. the visualisation (visible/invisible) of a Text label within your component. When you want to change the visualisation of that Text label, you update the state property within your component that will automatically redraw and show or hide your Text label. This is a very isolated behaviour that occurs within a specific component. Within a simple mobile app / screen, this behaviour suffices.

But when you need to share data across several components and screens (e.g. a user overview screen and user detail screen), you’ll need something more. A centralized state management system to be more specific. This state management system will manage the data (state) and make it available to all components that are interested in the data.

We used Redux to introduce this behaviour. Redux consists of a simple predefined pattern:

Redux Diagram - How development in React Native helped us start the app revolution – pt. 1

  1. When interacting with a React component (e.g. button), you create an action. This action will be dispatched to the correct ‘Store’ (e.g. UserStore, where all user related data is stored and managed).

  1. The Reducer will intercept the action with the data and update the state (setting the user status to offline). A Reducer is just like a traffic officer guiding cars in traffic.

  1. The React component will refresh/redraw itself with the new state.

This approach will keep your state (data) centralized and manageable. The redux pattern is also easy to (unit) test, which will help you guard the expected behaviour and the quality of your code.

How we deal with complex asynchronous calls (and other ‘side effects’)

When you need to fetch some data using an API, you set up a call to retrieve and process data. Some developers tends to do this directly within a component itself. In very simple apps/cases, this is fine. But in more complex cases where you need to fetch, process, transform and store data, it can introduce a mess.

To make application side effects (e.g. asynchronous things like data fetching) easier to manage, more efficient to execute, easy to test, and better at handling failures, we used Redux Saga.

Anything that results in changes that can be observed when the calculation is completed, beside the return value of the calculation itself, is a side effect. Calculation should return just result of the calculation. Anything else is side-effect. Just like an asynchronous call for fetching data.

How development in React Native helped us start the app revolution – pt. 1

Redux Saga lets you hook on a Redux action to perform another action (that performs an API call). If we want to do an API call after interacting with a button, we, as indicated within the state management section, dispatch an action. Without Redux Saga, this action will go straight to the reducer where the state will be updated.

Since we want to perform an API call, we register an additional action (that will perform the API call) that will hook on the already defined action. To be specific, when the USER_STATUS action is triggered (dispatched) from the React Component, the hooked updateUserStatus will subsequently be triggered. Within this updateUserStatus function, we can perform our API call. Once the call is performed, we dispatch another action to let know it succeeded/failed.

Hook action

ES6 Generator function that handles the async API call

This Redux Saga concept will help you bundle and manage your side effects. The API calls will be separated and located at a specific place instead of within components. You’ll definitely appreciate this when your project/codebase grows bigger.

How to cope with (unpredictable) React Native changes

When working with React Native, chances are very high that your implementation becomes obsolete after a short while. This is because React Native introduces and deprecates things quickly. The lifecycle events (componentWillMount(), componentWillReceiveProps(), …) of a component are good examples of this.

During the development of the My Viking app, we encountered deprecations and obsolete implementations. Some component lifecycle events and packages are not available anymore and are or extracted/removed from React Native. At that point you just have 2 options:

  1. get mad,
  2. or find a solution and adjust your code.

When going for the second solution, it’s very helpful that your code is easy to adjust. We keep our codebase manageable by applying best practices such as:

By keeping your codebase quality high and ready to adjust, refactorings become a lot easier. Also try to avoid temporary (hacky) fixes and immediately go for the better solution whenever possible. It’s also important to not jump on the newest things and consider changes carefully (functional components vs pure components vs React Hooks, for example).

Takeaway for How development in React Native helped us start the app revolution – pt. 1End of part 1

Thanks for reading the very first part of behind the app: Mobile Vikings series. We covered some interesting technical aspects of the My Viking App and React Native development:

If you have any questions, please don’t hesitate to contact us or leave a comment below. Additionally, if you’d like to know more about the My Viking app case study, you can check that out here!

In part 2, we’ll focus on (unit) testing our code to guard our code and app quality. Besides unit testing we will also look into snapshot testing and how it can help us to make sure our UI (components) does not change unexpectedly, so stay tuned!


As promised earlier, as a surprise, we would like to share an interesting approach for doing your multilingual support within your app (i18n):

  1. Define your text translations within (separate) JavaScript files (en.js, fr.js. nl.js), create an index.js file for matching and returning the correct translations file based on the device language.

  1. Import the index.js file within your component (e.g. as Language) and refer to the desired translation property (e.g. Language.cancel).
  1. Extra: manage your translations in a tool like POEditor (online localization service). POEditor helps you manage and collaborate on your translations. You can easily (manually or automatically) generate the output file.

As a Mobile Solution Expert at ACA IT-Solutions, I'm involved in Mobile ideation and development processes, where I develop and deliver technical input for realizing usable and likeable mobile solutions. I participate in various Mobile workshops, to deliver creative input and create prototypes for introducing and elevating Mobile innovation within businesses. I also love to give talks, presentations and write blogs about Mobile (innovation) to spread the word and knowledge.

I strongly believe in knowledge transfer.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Jessica Watson
1 year ago

Amazing Editorial!!
I appreciate the fact that you have explained all the information in depth.
Well researched & well-listed post, especially those who didn’t know-how development in react-native helped us start the app revolution, they will get support for sure. Keep focusing on such topics.
Thanks for sharing such a valuable post.