How Coinbase Rewrote the App in React Native

Hi, everyone, I'm Siri Wong, an engineering manager from Coibase. Last year, I let the Coibase app rewrite from native to React Native, and today I want to share our experience on the journey. So today, I'm going to share about why did we rewrite in React Native, and at the beginning, we approach the rewrite, the project timeline, and key results, and then sharing the challenges and learnings that we have.

So the first question is, why did we rewrite in React Native? At the end of 2019, we observed that our velocity to add a new feature in the Coinbase app is not great. For features, it took several months on each platform and a lot of coordination across teams. This is by no means because the mobile Native technology is bad. However, our app architectures set was too complex and complicated to make any change without fear of regressions. The app has been built with a lot of changes in many, many years. We did try to fix architecture. But it was so hard to fix the foundations while having a lot of pressure to build a new feature at the same time. Also, our teams at that time have about 8 people on Android and 10 people on iOS. Which is divided by the platform at that time. In two teams. It also create communication and consistency challenges. For example, when we build features, we need to check what's another team or another platform is doing. And when there's a bug, we need to check whether it's happening on iOS or Android or both. Hiring is also another challenge. It was really hard to hire native engineers than web engineers at that time. I remember that the whole year we hire maybe one Android engineer or two Android engineers at that time. We did try to convert some of the web engineers to Android, but it wasn't really successful. Also, at Coilbase at that time, we have a lot of deep talent pool of JS engineers. We have a lot of staff engineers on the web side. That makes the React Native a great choice for us. And with all of this, we were thinking about rewriting our Coilbase main app in React Native.

So how did we approach the rewrite? First, we start with the Android app. Why Android app? At that time, our Android app generates less than half of the revenue from iOS. Android app also doesn't have the same feature set as iOS. It has much less features. And so it's easier to reach the feature parity. Also, we have less number of people on Android compared to the number of iOS engineers at that time.

So that's why Android app is like what's chosen to be re-write in React Native. And we will see how it happens for React Native before we move to the iOS.

Second, we are talking about should we re-write or should we do Brownfield. And we decided to do Brownfield. And as you can see, we are going to re-write or Greenfield because of the complexity. It's not just the complexity, it's also a lot of several other challenges. For example, if we have a new feature, we need to decide which feature to do in Native, which features we want to do in React Native. If you modify the existing features, should we really try to convert in React Native or Node.js? Those are the questions that we need to decide if we do the brownfield. Also, with the Greenfield, we can create a separate team working on the new app, which is separate from the existing app. So it's easier to reinforce the resource that needed to move forward.

Next is, we integrate existing Android engineers at that time. So the original team composed of six people, and then we bring in two Android engineers, and we train them in React Native. They haven't done any React Native on TypeScript before, so we train them. We host several sessions to design the architect of the new app with the existing Android team to learn more on what data layer that we're going to use, how to error handling, navigations, deep links, or any Native quirks or Native modules that we need to write as part of these rewrites. Then we create the architect and design document to support all of these current use cases that we have on the existing app.

So those engineers, the Android engineers, prove to be incredible value to the project. Not only do they have context on all of these how the app function works inside-out, they can also look up the existing code base when the requirement is not clear. Because we rewrite from scratch, I mean that's going to be a lot of features that no one knows about. They also can work on the native modules since they have the expertise on the native language as well, so this is, these Android engineers were the key to our project success. Before we start, we also create the code-based design system that composes of primitive like what color, theme, scaling, elevation, layout spacing, and components like what's the text button control, logo cells, tabs. Those are the key components, so we can build UI really much easier than building a custom UI or trying to match with the screen-by-screen. And engineers can focus on the functionality than focus on building the UI, and as a result, UI is more consistent, and make it more polished and higher quality. This CDS or corporate design system is the foundation to be used and improve upon even today.

And the last thing that we did was to set the guardrail metrics in the timeline at the beginning. This is so important to set the right expectation especially to the management. It provides the milestone, the transparency on how the project is going. We can evaluate the project progress and provide goal-no-go decision at any given point in time because we already set what to expect. On the metrics and guardrail, it is really important to discuss, even before we start in the project, on what does success look like. Let's say that we want to launch the app tomorrow, what are metrics going to be? Do we expect metrics to stay neutral, to increase or to drop, and how much drop that we can tolerate. Especially for our app, how much revenue on the metrics that we can tolerate, doing the rollout, for example.

So this is really critical to align at the beginning. So I'm going to talk about the timeline for the project and the key results. So we started the project in March 2020. At that time, we didn't know that Rewrite would be successful. That's why you can see that in here, the timeline, we still continued to develop native Android. We still continued to build native iOS screen with iOS features. We started to gain more insights when we hit the first milestone, which is the internal dock pool in July. So we have very basic bare minimum that can do only trade and checking price. So we can see, look and feel and be able to use, get into the hand of people inside the company. So we start to gain more insight, how long the project will be, and also gain more confidence on the project success. So at that time, we stopped the Android native development. But we still continue to develop on iOS, because we don't know that the Android launch is going to be successful. And then we roll out, we are ready by October 2020, we roll out the Android, and it was really successful in terms of metrics, the user engagement, and also performance metrics as well. After that, we continue to catch up all the missing features that iOS has done. And then launch on iOS in January 2021. So the whole project took a little bit less than a year from the beginning.

On the key results, we tracked several key results here on both Android and iOS. So the performance, there's no regressions on the performance that we are tracking. The call start time improves. The tap transition time crash also reduced as well on the key business metrics. It actually increased across all the metrics that we are tracking including the revenue as well. And the app rating for Android, the quality of the app is higher than before, so the rating increased from 3.8 to 4.4. So it was really a surprise on the rewrite of the project as a whole. We thought that it was going to be neutral but actually it is even better. So I want to share the challenges and the learnings of the app project that we had. So the first one is clearly the performance. As you know that the React Native has a performance deficit from the Native versions. We put emphasis on the performance at the beginning. We measure performance early, try to reduce the number of re-rendering, which is like 10% and at that time we our data layer using the race hook which calling multiple APIs in the same screen and cause a lot of re-rendering. So we did a lot of optimization on the client side.

It was like caching and we write some of the main API during the cold start to aggregate into the single API to improve the cold start time. As a result, the app performance is not regressed from before. Doing the project, we created a tool to track the performance. The key is to focus and measure performance metrics from the beginning.

The next challenge is deciding how to roll out the new app. We have been debating whether we want to roll out as a totally new app or a combined app that contains both new and old versions together with the switch. With the timeline complexity, we decided to go with the simpler approach by rolling out the new app and mitigate the launch using the slow rollout of the Android release process in Play Store. It's definitely not easy to measure the impact, as we have no control on who's getting the old version, who's getting the new version. But it helped us save a lot of time and mitigate the rollout risk.

Before we roll out, we leveled the beta program, we also do the qualitative survey to people to participate in this program. We measure the score before and after, also catching some bug in between. What we learned is that we need to dock earlier and create a beta program, and make sure that we understand how to roll out and measure the metrics properly. Another thing that is really important is the leadership support. The rewrite, especially at this scale, is a year long project. It means that we couldn't develop a new feature for a year. This is a lot of pressure. The key is to show progress and small wins. It helps the leadership also helping resourcing and communicating. We need to communicate with them and make sure to check in with each milestone.

Once a project moves forward, the leadership needs to bring in the existing native engineers who are not working on the project. We need to change and stop the hiring pipeline switching from native to React Native and TypeScript. During the rollout, there were times to make a call whether we need to move forward or not based on the metrics. Setting expectations early, constant progress, and communications are the key to get support and alignment from the leaderships. Another learning is re-platformizing existing native engineers. If you think about it, a native engineer got hired to a company, and now we ask them to switch and relearn the new language and platform, the TypeScript and React Native. We did have a plan. We have a training program. We provide them support, mentorship to ensure the transition to be successful. We also provide a guideline on how we evaluate individual person performance during the transition as well to make sure that we don't penalize them because of the change of platform and they cannot operate at the highest level. Re-Platformization is definitely really challenging but doable.

And also for us in our case, we were so lucky that there was no attrition as part of the transition. After we launched, we can see the success of people, transitions, building features on the Act Native. At the beginning of the project we had like 20 Native engineers and now we are hiring more engineers and we scale the number of engineers to be more than 100 engineers and keep growing. The key is to provide transparency for all the existing Native engineers. How we're going to train them, how we're going to set the right expectation during the transition and each milestone, when they're going to stop Native development on the existing app, when they're going to move on to the new app, and how that's going to work. So we need to provide them the support during the transition. And that is the story of how we rewrite the CODES app. Thank you.

Hey, good to see you, well, yeah, see you over your face. Happy to have you here, kind of in London. Thanks for your talk. We have some great questions from our audience, so let's just jump right into it. Everyone, you can still ask questions and upvote the questions you want to have answered, of course.

The first question is from Alice. Did you consider sharing components and functionality between your websites with React and this new React Native app? Of course, yes. You know, in the long run we want to release the first web app on mobile, but we are not there yet. First we need to make the code look the same, use the same technologies using the design system and also the data layer when we add those in the playlist. We are releasing in the same default, so all those will be much easier. All right. Thank you.

Next question is from Tom D. It's a good question. What tools did you use to measure and compare the performance between the two apps? Yeah, so we have our custom logging to really compare the performance. But initially, we just doing the side-by-side comparison and see the getting obvious performance so we can bring it out to those. But for the metrics that we're looking at is like cold start is definitely one of them. And then the page load or tab switch that we are using. Okay, thank you.

Next question is from anonymous. A reminder, if you want to win a T-shirt, you should not post as anonymous, but use your real name if you're here or your Discord ID if you're watching remotely. Oh, that was the same question also about performance.

Next question is from Alice again. What is the code or module split of your app between native modules you custom built and using existing modules React Native in the community provides? Can you repeat the question again? What is the code or module split of your app between native modules that you've customly built and using existing models React Native in the community can provide? Yeah we kind of use the mix of a couple. I think we use the React navigation and some custom module that we need to use for like biometrics for example. So those are like custom built because we need to do some custom logic over there. So there's a mix of both.

Okay, next question is from Anna. She's asking, I see that it took almost a year to rewrite Coinbase. How many developers are working on this? Yeah, people initially is like six people, originally and the team grow as the project progress. So it's going to and I think that the max is probably around 10 or 12 at the end of the project once we start catching up for the iOS features. So roughly, if I take an average, it took eight developers one year. Yeah. Yeah. All right, awesome. And now, of course, you have an increased velocity, because you only have one code base and all the developers can work on that same code base. Yeah, we have more than 100 developers on this code base. Awesome.

Let's see. Next one is from Lauren. Did you have to train in your engineers on this new language? And if so, did you save time on the long term instead of the short term? Yeah, I think we really train a lot of people from Android and especially on iOS. So the saving time for the existing native engineers, I wouldn't say we really save time, but we convert properly. We want to make sure that they get set up and measure successfully, right? Because you learned the native language for many years, and then now you should learn React Native. But the saving time piece is more in the long run, because we're hiring, right now, more than 100 engineers on client itself. That is, like, one part of it, and also the velocity that we have on the app. The retraining part is, like, maybe 10 people or 15 people, originally, that is in Native.

All right, and a question for me in between. Did you find any resistance in the team that people want, did not, or did really want to retrain as a React Native or JavaScript developer? Yeah, totally. I think that this is the things that we needed to communicate transparently, because as you know, many people may not really want to do React, or React Native, from if you do the Android, probably generally, or you do like iOS, Swift, I think that the key thing is we need to provide the support and make sure that have a training have like how we're going to measure the performance for all these people. So for us, luckily, that everyone needs really foolish in React Native and convert successfully we don't have any attrition per se, I would say maybe one person that want to try something totally different, like backend and all that. All right, so it's nice that the team was quite aligned still. All right, next question.

Would you recommend from now on building all your applications in React Native or are there still some perks to having a separate native app?

Yeah, I see the benefit I came from the native app and now I'm in the React Native world. It depends on the app. For Coinbase app, I think that the React Native makes sense. We are doing a bunch of things on the server side and the UI is pretty straightforward in some ways. So, if you develop games or if you develop something that has a lot of media, in that case, it may not work for those types of applications. But for us, I think that it works for us.

All right. Well, that was all the time we have for questions. I would like you to nominate a winner for our free t-shirt. So, what did you think the best question was? Well, I don't know what question we have so far. I think the questions about maybe the native module can be a really good one. Yeah, what the split is between the native and react community modules. Yep, alright. Exactly. That was Alice's question.