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.
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.
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
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.
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.
And that’s how I ended up learning React Native.
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.