Migrating to React Native (2 years on)... Part 1

It has been two years since some of my team gave this talk at the React Native meetup in London. A lot has happened since then (pandemic aside), so I wanted to give a further update on our journey to React and React Native at Qudini.

Recap

Qudini has been around for 9 years. When we started out we made the choice to use Angular.js for our web frontend, and native Android (Java) and iOS (Objective-c). We did evaluate the 'cross platform' technology at the time, but felt it either wasn't mature enough, or didn't feel it would be around long enough.

The team was fairly small and so was the product, so we didn't feel the overhead of writing everything three times as the team comprised of 1 backend, 1 web, 1 iOS and 1 Android developer. We managed to make good progress and deliver customer value quickly.

Fast forward 4 years and we found ourselves in a position where there was always feature disparity between the different platforms. An increase in customers also came with an increase in feature requests, which mean we had to prioritise, but this often meant we'd prioritise a feature on one platform ahead of another (because customer x was on iOS).

It's always difficult to get agreement to do a full rewrite, and in most cases I wouldn't advocate this. However we assessed the effort in doing an incremental re-write and found it would slow us further due to significant differences between the iOS and Android versions, so we used the opportunity to refresh the app and provide cleaner UI which was consistent between OS's.

So.. how did it go?

We launched the app around the time of the above presentation, and the feedback from our customers has been really positive. They loved the new UI and because we had clients using both iOS and Android it has really helped with the training and onboarding process as no matter which platform the UI components look the same.

All of our front end engineers are now are fully skilled up in React Native and Typescript and still work across both mobile and web which allows us to ensure we build all functionality on all platforms at once to maintain consistency.

We have spent time refining the build and release process using App Centre, so now all new builds are released on TestFlight for iOS and available as an Android build too. This allows for much quicker feedback from both internal teams but also customers who agreed to be beta testers.

As a B2B company, we have to be mindful of our users, and ensure we don't affect their daily operations. In order to release quickly while maintaining a consistent experience we have utilised feature flags to allow us to release and test quickly before then rolling out a release by enabling flags from our backend. Our clients love that they have this level of control whilst allowing us to innovate.

During the Covid-19 pandemic we like many businesses had to adapt quickly, this new way of working allowed us to build an entirely new feature 'occupancy tracking' to allow our retail stores to count customers in and out of the store and automatically fall back to a virtual queue once it got busy.

Upcoming

I'll be sharing further posts over the next few weeks with a deep dive in some of the key learnings.

This will include performance, testing, accessibility and developer experience.

Hiring

We are also hiring, so if this sounds of interest, and you'd like to shape the future of our mobile experience please get in touch via https://qudini.workable.com