How Coinbase Rewrote the App in React Native

Rate this content
Bookmark

Last year, our team rewrote the Coinbase app from Android/iOS Native to React Native. The new app was launched successfully and with higher quality. The native engineers were re-platformed to React Native, and our productivity has increased. The talk will share our journey from the start of the transition, how we mitigate the risks, and the lessons learned.

Siriwong (Ching) Wongthongserm
Siriwong (Ching) Wongthongserm
30 min
22 Oct, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Last year, the Coinbase app was rewritten from native to React Native due to the complexity of the app's architecture. The Android app was chosen for the rewrite and a Brownfield approach was taken to integrate existing Android engineers. The project started in March 2020 and had successful launches for both Android and iOS. The transition to React Native was successful, with increased engineering resources and feature development. Recommendations for React Native include considering the app's requirements, and the best question was about the split between native and React community modules.

Available in Español

1. Coibase App Rewrite in React Native

Short description:

Last year, the Coibase app was rewritten from native to React Native. The decision to rewrite was driven by the complexity of the app's architecture and the challenges in making changes without regression. The team faced difficulties in coordinating across platforms and hiring native engineers. With a deep talent pool of JS engineers, Coibase chose React Native as the solution. The rewrite started with the Android app, which had fewer features and a smaller team compared to iOS.

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.

2. Android App Rewrite and Integration

Short description:

The Android app was chosen to be rewritten in React Native due to its complexity and the challenges of making changes without regression. The team decided to do a Brownfield approach, integrating existing Android engineers and training them in React Native. These engineers proved to be invaluable to the project, with their expertise in both the existing codebase and native modules. A code-based design system was created to streamline UI development, and guardrail metrics were set to ensure project success.

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.

3. Project Timeline and Key Results

Short description:

The project started in March 2020, with the team initially developing native Android and iOS screens. After hitting the first milestone in July, they gained more insights and confidence in the project's success. The Android launch in October 2020 was successful, with positive metrics for user engagement and performance. The missing features were then developed for iOS, and the app was launched in January 2021. Key results showed improved performance, increased business metrics, and higher app ratings. The team faced challenges with React Native's performance deficit but focused on optimization.

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.

4. App Performance, Rollout, and Re-Platformization

Short description:

To improve the app performance, we aggregated some main APIs during the cold start. We created a tool to track performance metrics and focused on measuring from the beginning. Rolling out the new app was a challenge, but we decided to go with a simpler approach and mitigate the launch using the slow rollout of the Android release process. Before rolling out, we conducted a beta program and qualitative survey. Leadership support is crucial, and showing progress and small wins helps with resourcing and communication. Re-platformizing existing native engineers was challenging, but we had a training program and guidelines to ensure a successful transition.

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.

QnA

Transition Success and Performance Measurement

Short description:

After launching the app, we saw success in people transitioning and building features on React Native. We started with 20 Native engineers and now have over 100 engineers. Transparency and support during the transition were key. We also answered questions about sharing components and functionality between websites, as well as measuring performance between the two apps.

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.

Code/Module Split and Training

Short description:

Alice asked about the code or module split between native modules and existing React Native modules. We use a mix of both, including React Navigation and custom modules for biometrics. Anna asked about the number of developers working on the project, which initially started with six people and grew to around 10 or 12. With more than 100 developers now, the increased velocity is evident. Lauren inquired about training engineers in the new language, and while it didn't save time for existing native engineers, it was beneficial in the long run. Resistance to retraining was addressed transparently, resulting in successful conversion to React Native for the majority of the team.

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.

Recommendations for React Native and Best Question

Short description:

Building applications in React Native depends on the app. For Coinbase, it makes sense as the server-side work and UI are straightforward. However, for games or media-heavy applications, React Native may not be suitable. As for the best question, the one about the split between native and React community modules stood out.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Debugging JS
React Summit 2023React Summit 2023
24 min
Debugging JS
Top Content
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
Monolith to Micro-Frontends
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
Power Fixing React Performance Woes
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Top Content
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
Building a Voice-Enabled AI Assistant With Javascript
JSNation 2023JSNation 2023
21 min
Building a Voice-Enabled AI Assistant With Javascript
Top Content
In this talk, we'll build our own Jarvis using Web APIs and langchain. There will be live coding.
Video Editing in the Browser
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

Introducing FlashList: Let's build a performant React Native list all together
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
WorkshopFree
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Yevheniia Hlovatska
Yevheniia Hlovatska
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
How to Build an Interactive “Wheel of Fortune” Animation with React Native
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Top Content
Workshop
Oli Bates
Oli Bates
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
Building a Shopify App with React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Jennifer Gray
Hanna Chen
2 authors
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
Build a chat room with Appwrite and React
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
Wess Cope
Wess Cope
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
Hard GraphQL Problems at Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.