Why we adopted React Native to deliver happiness to stores

One of the big milestones that I was part of this year was the successful relaunch of our Attendant app for our Collections product.

While you won’t be able to find this app on the iOS App Store or Google Play Store, you may have indirectly used our app when you arrived at your local Woolworths or Countdown store to pick up your groceries; or collecting your Christmas Party drinks list in under 30 minutes at Dan Murphys.

Our Attendant app — as the name suggests — is designed for shop attendants to process and keep track of click and collect orders. It will also notify the attendant that you are on your way or have arrived to the store.

Under the hood, our new Attendant app uses React Native — a framework developed by Facebook that allows you to create iOS and Android apps using JavaScript. We’re not the only ones using React Native to build our new apps either — Bloomberg, Uber, Tesla and Facebook itself are just some of the companies using it some people using it to power their mobile apps too.

Why did we decide to jump on board the React Native train? While there are many options out there — like Adobe’s PhoneGap — we ultimately chose React Native because it suited our requirements.

Same codebase, two platforms

What attracted us to React Native initially was the idea that we could use the same codebase to generate iOS and Android apps. It meant we could quickly introduce new features to both platforms at the same time.

This would also mean feature parity between platforms. Our previous Android app got all the new bells and whistles because most of our clients had Android devices. On the rare occurrence we had an iOS use case, we would get the developers stop whatever they were doing and quickly add missing features in a couple of days.

Faster development

Another reason why we went down the React Native path was it promised — according to all the puff pieces that are scattered on the internet — faster development time. Not only because we are coding for two platforms, but also so could leverage off the React Native (and the larger React) community to plug in any gaps with the sheer number of plugins.

This was crucial since we made the decision to rebuild our app from scratch, instead of shoehorning React Native in our old app to develop new features. We wanted to move all of our Collections clients to the new app as soon as possible, so it was important that we could build the app quickly (without sacrificing on quality).

Reusing our native SDKs

In addition to sharing the same codebase, React Native allowed us to leverage our existing native SDKs, avoiding a rewrite of our existing API calls with the JavaScript Fetch API.

Instead, we had to simply write some JavaScript bridge code that would call the relevant native method, and — in some cases — do some data manipulation to ensure it returned the same object to our React Native frontend.

It also meant that we got a lot of the fundamental features that we bundle in our SDKs straight out of the box — such as handling JWT refresh tokens, push notifications, and offline support. Our SDKs already have logic to handle all of those cases, so we didn’t need to go out of our way to reimplement them.

It’s just JavaScript

As a startup, we do not have the same level of resourcing for our mobile apps like Facebook and Airbnb. We have a very small mobile team who largely work on our SDKs that we give to our clients. Having them also maintain our white-label applications was not sustainable.

However, we have a lot of developers with JavaScript knowledge — our backend runs on NodeJS, and our frontend web apps are written with Angular or React. So, from a people perspective, it made sense to move some of the developers from web to mobile with React Native.

And that’s how I ended up learning React Native.

This year’s State of JavaScript survey results show that React Native is gaining traction, with a large majority saying they are keen to learn more about it. That’s no surprise — being able to use JavaScript to build mobile apps is a very attractive proposition.

However, React Native is just another framework. Before jumping deep into React Native, you should see first if it meets your needs. You might find that the alternatives — Cordova, Flutter, or even going native — might be a better fit to your needs than React Native.

For Localz, React Native suited our needs to build mobile apps quickly with the resources we currently. But like all new technologies, it was not a perfect transition.

But that’s a story for another day.

This blog post is part of the 2018 Localz Advent Calendar series. You can read the rest of the blog posts in the series here.

And don’t forget to hit that 👏 button — it lets people find some of the cool stories we post in the Localz Engineering blog!