Building the Thriva app — choosing the right technology

Thrivaling shopping for new technology

I’ve been working at Thriva for two and half years, and recently I got the opportunity to be Tech Lead for the squad building our very first mobile app. Building a completely new app from scratch for a business that’s been around for five years is a tricky process and the team and I would like to share some of the learnings that we’ve had over the last 6 months. We hope that by outlining the thought process and problems we come across can help others avoid them in the future.

Background

In October 2020 my team was asked to build the very first mobile app for Thriva. I’ve historically worked on ruby on rails apps and occasionally dabbling in some javascript, but I had no experience of building a mobile app. On the team, we had two senior frontend engineers, one senior backend engineer and a new frontend engineer due to start in January. Our product manager and designer had the most experience with apps having both worked on them in previous roles. However, the first decision we needed to make was what technology to use.

Our requirements

Going into the mobile build we had a couple of constraints and requirements:

Supporting iOS and Android from the start

We want to make access to the services we provide at Thriva as accessible as possible for our customers, so supporting iOS and Android from the start was a requirement.

This really ruled out using native languages (Swift/Kotlin) but opened up options such as Flutter, React/Vue Native, Ionic and Cordova.

Long term support

This App is hopefully going to be around for a long time, so we wanted to use a language or framework that we thought had good community support and would continue to be supported into the future.

Native languages are the most obvious choice here as they will be around for as long as the platform is around. React Native and Flutter both seem to have blossoming communities, but with big players like Airbnb dropping React Native a couple of years ago, we did have some doubts. Vue Native is too new to really gauge how successful it’ll be and Ionic & Cordova both seem to be losing popularity.

Snappy and fast app

There are many benefits to having a native app, but one that was important to us was making sure the app was as fast and responsive as possible. We are not doing anything too CPU intensive, but we want to make sure the experience feels as native as possible.

The obvious contenders here were Swift/Kotlin and then closely followed by React Native and Flutter. All of these are known to have great performance and while React Native requires the bridge, it’s got fast enough that it isn’t an issue (and there is ongoing development to remove it in the not too distant future).

Building the app in house

At Thriva we build as much as possible in-house as our technology is key to the success of the business. Therefore outsourcing the initial build wasn’t really an option for us, and it meant we would have to upskill the team on whatever technology we decided to use.

On our web stack, we use Vue as our core framework, so our engineers have a good knowledge of Javascript and the concepts of a component-based framework and unidirectional data flow. Therefore, we were keen to look at React/Vue Native which would allow us to write once in javascript and build apps for both platforms. Ionic & Cordova could also be good options here as they both rely on web technologies. Swift, Kotlin and Dart would all require substantial investment to upskill the team and there was no guarantee that the engineers would even want to learn these technologies.

Making the decision

So with those requirements, we went through our potential options:

Flutter was something I was particularly interested in after asking some contemporaries on the CTO Craft slack. It apparently has a great developer experience and it is starting to gain real traction in the mobile community, but it would require us to learn Dart. Google doesn’t have a great track record for supporting all their services so that was one concern about using it for an app we want to be around for years to come.

Cordova and Ionic were quickly vetoed after some engineers in the team shared some bad experiences with these technologies from previous roles.

Using native languages were also vetoed fairly quickly due to the need to learn two new languages and that we couldn’t have one code base for both platforms.

Vue Native was rejected due to how early in development it is. It would have been great to use Vue on both the web and mobile as we’re big fans of Vue at Thriva, but we wanted to build an app that would be around for years and Vue Native doesn’t have a long enough track record yet.

So then we get to React Native. All the engineers of the team had used React at some point in the past so we already knew the gist of how it would work. It would allow us to build for both platforms at once and has a near-native feel. Support for React Native also seems to continue to grow with the community keeping up support for a range of different libraries and some key services that we use releasing React Native packages (eg. Intercom and Sentry to name two). And finally, when asked what technologies the engineers wanted to learn (myself included), React Native was often at the top of everyone's list so we knew the team would be excited to learn it.

Conclusion

As engineers, we often want to try out the hot new language or framework, but at Thriva we always want to consider our options and make sure we’re using the right technology for the job. In this case, React Native ticked enough boxes to be the right choice for us and just so happened to be the language everyone wanted to learn.

We’ll be sharing more about the development process of building our first app so stay tuned! In the meantime, you can check out our app on iOS and Android. If you’re interested in joining Thriva, you can have a look at our open roles here.

Tech Lead at Thriva.co. Rails, React Native and Vue