Our switch to React Native

We are a startup founded in 2015, called Jack. Jack is a mobile messaging app that reconnects you with the pleasure of anticipation. It is a new concept of online messaging, where the message is delivered instantly but you decide how long the receiver must wait before he or she can read it.

Since this app connects people, we decided right away to support the two major mobile platforms, Android and iOS. And given the concept and purpose of the app, it also needed to have a beautiful and pleasant experience: it isn’t a practical tool for everyday use, it is an application where you find pleasure and emotions, so its design had to be attractive.

For these two reasons, we decided to skip the hybrid eco-system - judged too poor in terms of user experience and final product quality - and go for native development for Android and iOS.

Oh, and I must admit that I’m personally not a fan of developing in a layer upon a layer upon a layer …

So we started with one Objective-C developer, one Java dev, one Backend dev, a UX, a designer, and a web developer for the web application, which would come in a second phase.

A few months later

We put our app in production four months later, fine tuned & debugged it. Our MVP app had an excellent quality, we had unit & functional testing in place. We were steady.

We then started to iterate new functionalities. And this is where we weren’t really happy anymore. Testing a new functionality, even just internally, took way too long: first we had to think about UX for three platforms and ecosystems, and then implement it in three languages. Cost became an issue too.

Time to reassess

We first had to find a solution to iterate internally and at a better pace. For this we considered several tools: prototyping tools (Framerjs, Sketch, …) and hybrid mobile applications development tools (PhoneGap, Ionic, Appery.io, …).

Prototyping tools were impressive: the ease of use and speed is just amazing. But this solved our internal tests and UX issues, but did not address the development costs.

Hybrid mobile applications had a better potential, but the speed of development wasn’t that exciting, and again, it wouldn’t solve our development costs, since the end quality was too poor for such an application.

We then considered React Native. React Native gave us, in theory, everything we needed: a very fast development environment, capable of building quality products using native components, for both our mobile platforms. We tried it for a few days, and were delighted with what we achieved. So we started iterating.

Implementation

After a month of internal iterations, we had a continuous hope that not only would it allow us tests ideas very fast, but in addition would enable us to go to production must faster as well. And it actually did. We tackled all the technical doubts we had, one by one, to get to the point that we officially decided to rewrite the whole mobile application in React Native.

It was a great experience. The development environment is globally a pleasure to work with and the community is very active. Being able to live reload without compiling is even better than working with native! Not to mention the live updates we are now able to do thanks to CodePush.

Problems encountered

Of course, we faced problems and issues. But not that much: everything is not yet implemented officially, so we needed to rely on third party librairies, sometimes incomplete, but they have the merit of existing, and they fix issues very fast thanks to the vibrant community around it. We also realised that the Android implementation is not as stable as the iOS one, so we quickly took the habit of developing and testing on Android as soon as possible. The quality on some components is not as it could be natively - the navigation component for instance - but it is good enough, and I’m sure this will be improved over time.

Status and conclusion

After a few months of development using React Native, we now have our new product in production. Its quality and performance is not exactly as it should be yet, but it is much easier to maintain and iterate. This is particularly useful given the stage of our development, since we want to iterate very rapidly and react to our users’ feedback as fast as possible. This, with a business bonus of course, as our development cost has been drastically reduced.