How Coinbase Rewrote the App in React Native

Hi everyone. I'm Silly 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, how did 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 Coibase 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 architecture state 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 the 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 eight people on Android and ten people on iOS, which is divided by the platform at that time in two teams. It also created communication and consistency challenges. For example, when we build features, we need to check what 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 hired 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 Coibase at that time, we have a lot of deep talent pool of jazz engineers. We have a lot of staff engineers on the web side. That makes the react Native a great choice for us. With all of this, we were thinking about rewriting our Coibase 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 apps 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. So we have less number of people on Android compared to the number of iOS engineers at that time. So that's why Android app was chosen to be rewrite in react Native. And we will see how it happened for the react Native before we moved to the iOS. Second, we are talking about should we rewrite or should we do brownfield? And we decided to do the rewrite or greenfield because of the complexity. It's not just the complexity. It's also a lot of several other challenges. For example, we need 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 not? 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 reinvent the resource that needed to move forward. Third, we integrate the 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 or typescript before, so we train them. We host several sessions to decide 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 the AR handling, navigations, deep links, or any native quirks or native module that we need to write as part of these rewrites. Then we create the architectures and design document to support all 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 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, 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 these Android engineers were the key to our project success. Before we start, we also create the code base design system that is composed of primitives like what's 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 try to match with the screen by screen. And engineers can focus on the functionalities than focus on building the UI. And as a result, UI is more consistent and it makes it more polished and higher quality. And the CDS or code base design system is the foundation to be used and improved upon even today. And the last thing that we did was to set the guardrail metrics and the timeline at the beginning. This is so important to set the right expectation, especially to the management. It provides the milestone transparency on how the project is going. We can evaluate the project progress and provide go, no-go decisions 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 the success look like. Let's say that we want to launch the app tomorrow. What the metrics going to be? How we expect metrics to be 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 during the rollout, for example. So this is really critical to align at the beginning. So I'm going to talk about the timeline on the project and the key results. So we started the project in March 2020. At that time, we didn't know that the rewrite would be successful. That's why you can see that in here, the timeline, we still continue to develop native Android. We still continue to build native iOS features. And we start to gain more insights. One we hit the first milestone, which is the internal doc pool in July. So we have really 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 hands 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're ready by October 2020, we roll out the Android. And it was really successful in terms of metrics, the usage, 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 improved. 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's going to be neutral, but actually it's even better. So I want to share the challenges and the learnings of the project that we had. So the first one is clearly the performance. As you know that the react Native has the performance deficits from the Native versions. We put emphasis on the performance at the beginning. We measured performance early, tried to reduce the number of re-rendering, which can cost a bit. And at that time, our data layer using the Redress hooks, which calling multiple APIs in the same screen and cost a lot of re-rendering. So we did a lot of optimization on the client side, includes caching and rewrite 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. During 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. Despite the timeline complexity, we decided to go with a simpler approach by rolling out a 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 versions, who's getting the new versions, but it helped us save a lot of time and mitigate the rollout risk. Before we roll out, we leverage 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's 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. It is a lot of pressure. The key is to show progress and small wins. It helps the leadership also helping resourcing and communicate. We need to communicate with them, make sure to check in with each milestone. Once the project moves forward, the leadership needs to bring in the existing native engineers who were 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. Having expectation early, constant progress, and communications are the key to get support and alignment from the leadership. 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, 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 react Native. At the beginning of the project, we had like 20 native engineers and now we hire 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 are we going to train them? How are we 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 is that going to work? So we need to provide them the support during the transition. And that is the story of how we rewrite the Cortex app. Thank you. Hey, good to see you. 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? In the long run, we want to release the first webpacking mobile, but we are not there yet. First, we need to make the code look the same. It's the same thing as the webpacking. Now, it's using the design system and also the data layer. Once we have those in place, and we are releasing the same default, so all those will be much easier. All right. Thank you. Next question is from Tom D. And 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. Initially, we just doing the side-by-side comparison and see if we're getting obvious performance, so we can bring it out to those. But for the metrics that we're looking at, it's 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 build and using existing modules react Native and the community you provide? 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 and the community can provide? Yeah, we kind of use a mix of a couple. I think that navigation, we use the react navigation and some custom module that we need to use for biometrics, for example. So those are custom build because we need to do some custom logic over there. So we use 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 go to eight and I think that the max is probably around 10 or 12 at the end of the projects 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. So we have like 100, more than 100 developers on this code base. Awesome. Let's see. Next one is from Lauren. Did you train, did you have to train in your engineers on this new language? And if so, did you save time on the longer, 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 make sure successfully, right, because you learn the native language for many years and then now you should learn the app native. But the saving time piece is more on the long run because we 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 like the things that we need 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 originally 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 is like 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. Yeah. 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. So for it depends on the app or Core based app. I think that the react native makes sense. We are really like doing a bunch of things on the server side and the UI is pretty straightforward in some way. So if you like develop games or do you develop something that has a lot of media, in that case, it may not work for those type 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? I don't know what questions we have so far. I think the questions about maybe the native module, that can be really good one. What the split is between the native and react community modules. Yeah. All right. That was Alice's question. Alice, are you here? Alice, come to the stage and I will give you a shirt.