React Native at Scale

React Native https://reactnative.dev/ is an open source framework developed by Meta that allows engineers to build mobile applications for both iOS and Android using a single JavaScript codebase. The framework bridges the gap between web development and native mobile, which lets teams ship to both platforms simultaneously without sacrificing the look and feel of a truly native app. Manjiri Moghe https://www.linkedin.com/in/manjirimoghe/ is a Staff Software Engineer at Coinbase https://www.coinbase.com/, where she has spent five years building and scaling one of the world’s most demanding React Native applications. Her work spans performance optimization, reliability engineering, and the developer tooling that keeps large engineering teams moving quickly without sacrificing quality. In this episode, Manjiri joins Josh Goldberg to discuss why React Native has become the framework of choice for high-velocity mobile teams, how Coinbase measures app health, how to handle data fetching and loading in production, how AI coding agents are changing the day-to-day workflow for mobile engineers, and more. Josh Goldberg is an independent full time open source developer in the TypeScript ecosystem. He works on projects that help developers write better TypeScript more easily, most notably on typescript-eslint: the tooling that enables ESLint and Prettier to run on TypeScript code. Josh regularly contributes to open source projects in the ecosystem such as ESLint and TypeScript. Josh is a Microsoft MVP for developer technologies and the author of the acclaimed Learning TypeScript https://www.learningtypescript.com/ (O’Reilly), a cherished resource for any developer seeking to learn TypeScript without any prior experience outside of JavaScript. Josh regularly presents talks and workshops at bootcamps, conferences, and meetups to share knowledge on TypeScript, static analysis, open source, and general frontend and web development. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/05/SED1925-Reactive-Native-at-Coinbase.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post React Native at Scale https://softwareengineeringdaily.com/podcasts/react-native-at-scale/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  React Native is an open source framework developed by Meta that allows engineers to build mobile applications for both iOS and Android using a single JavaScript codebase. The framework bridges the gap between web development and native mobile, which lets teams ship to both platforms simultaneously without sacrificing the look and feel of a truly native app. Manjiri Mogay is a staff software engineer at Coinbase, where she has spent five years building and scaling one of the world's most demanding React Native applications. Her work spans performance optimization, reliability engineering, and the developer tooling that keeps large engineering teams moving quickly without sacrificing quality. In this episode,

• 0:45Speaker 00

  Manjiri joins Josh Goldberg to discuss why React Native has become the framework of choice for high-velocity mobile teams, how Coinbase measures app help, how to handle data fetching and loading in production, how AI coding agents are changing the day-to-day workflow for mobile engineers, and more. This episode is hosted by Josh Goldberg, an independent, full-time, open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES-Lint, a powerful static analysis toolset for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf,

• 1:30Speaker 00

  a conference for excellent web developer tooling. Find Josh on Blue Sky, Fostadon, and dot com as Joshua K. Goldberg.

• 1:50Speaker 01

  Hello, everyone. With me today is Manjiri Mogay, staff software engineer at Coinbase. Manjiri, welcome to Software Engineering Daily.

• 1:57Speaker 02

  Thank you. I'm excited. I've been an avid listener and yeah, excited to talk to you today.

• 2:03Speaker 01

  Great. Well, we're excited to have you here. Let's start off with you. How did you get into coding?

• 2:08Speaker 02

  Yeah, so I got into coding pretty late, at least I like to think that I got into coding pretty late. I am an electronics and telecommunications major and we did have coding subjects in engineering, C, C++, Java, but I never really liked them. It's probably because my mom was actually into software. She started coding in nineteen eighty-three in Kabul and I grew up around programming books like ERP, SAP, Java, and I made up my mind, this is not something I want to do. So I definitely resisted it. But it wasn't until my final year hardware project where we designed the PCB,

• 2:49Speaker 02

  wrote hardware code in, it was called VHDL, Hardware Descriptive Language, and I saw it working on the circuit. That's when I was like, okay, I built this, I can do this, and I realized the power of coding and software engineering in general. So right out of college, I got my first job at a consulting company. I learned iOS and Android. It was the AI back then, you know, twenty eleven, twenty twelve, everyone wanted to learn mobile development. And I was very happy, I was working on like cutting-edge technology. Love native development back then. And then moved towards hybrid mobile development, which was this phase when everyone wanted the apps on iOS and Android to be built at the same time,

• 3:35Speaker 02

  but we didn't have React Native. And we used to have this wrappers using like PhoneGap, Cordova. It was just wrapped around a web view, did not feel native at all. But you built only once, actually web mobile built together and then deployed on iOS and Android. And then React Native came out in twenty fifteen and everyone was so excited. We didn't have to wrap web views around anymore. We could write code that felt like native, write it only once and deploy it on iOS and Android. And yeah, I have never looked back since twenty sixteen. Did multiple rewrites from hybrid or native mobile to React Native.

• 4:17Speaker 02

  And at my previous company, Game Time, where I worked, we did the rewrites. And I joined Coinbase because Coinbase was a big proponent of React Native. They had just done the native to React Native rewrite. When I joined Coinbase in twenty twenty-one and it's been five years and I haven't looked back.

• 4:36Speaker 01

  It sounds like a wonderful journey. Let's dive into some of the high-level attributes of React Native you mentioned. So, a lot of developers may have heard of React as this sort of front-end web space thing. Why and how is React suddenly on mobile? What does that mean for a developer?

• 4:52Speaker 02

  I think the biggest thing here is React Native gives you the native feel, but the underlying technology of writing like JavaScript and CSS, which is the same as web, remains the same. So, many web engineers were able to adapt to React Native fairly quickly, I want to say. React Native does need native understanding and some native skills, but not too much. That is why I think it was a brilliant home run from Meta to build React Native, because it attracted web engineers, it attracted native engineers, and it created this community that now builds mobile apps. And that's what I even love about React Native. It's been around for 10 years and only getting stronger because of the community

• 5:37Speaker 02

  and the contribution it gets from all these amazing native engineers and web engineers together.

• 5:43Speaker 01

  It's kind of a best-of-both-world situation, it sounds like.

• 5:46Speaker 02

  Yeah.

• 5:46Speaker 01

  So, when you say that they're built at the same time, what was the difference between writing native apps versus a React Native app?

• 5:53Speaker 02

  Yeah, I think the biggest difference from a company perspective is obviously the speed, right? The velocity that you build products with. iOS and Android, you have to build code on them separately, unfortunately. And in my experience in the past, I have realized that you are always playing catch-up. You always have that business priority of a product, what that needs to be launched on X date, and then it comes down to, okay, 80% of my users are on iOS. I'm going to first build it on iOS and then Android follows. So, you are never able to maintain that feature parity between iOS and Android. Whereas on React Native, you write that code once and then it goes out on both.

• 6:38Speaker 02

  Yes, there are differences because iOS and Android are just different architectures, but rarely, if you are writing like pure JavaScript code, you have to. To make distinctions for iOS and Android. So it depends on the space you are in. Like if you are working on animations or if you are building a game, I would not recommend React Native. Because it's not there when it comes to, you know, animations and the performance that's needed. But if you are building a financial app like we do, like Coinbase. And where velocity matters because the world is changing so much, the crypto industry is evolving so much. We are launching products at such a scale that if we were building two apps, iOS and Android, we would just not be able to keep the feature parity.

• 7:23Speaker 01

  That's a very appealing value proposition of reducing velocity. Let's say that a company is just now getting started switching to React Native and or making a new app in our end. What advice would you give them?

• 7:33Speaker 02

  Yeah, I think I have three pieces of advice. First is observability. Many teams or many companies building mobile apps consider observability as their P one or a non-functional requirement. But I feel like observability is so important. Like if you don't measure it, you don't know how to improve it. So I think observability needs to be the first thing because people go to React Native and then say it's slow. But what is slow? Like if you don't measure it, you will never be able to improve it. So you need to have observability in place. Second is guardrails. There are so many good patterns, bad patterns that are already defined in React Native.

• 8:17Speaker 02

  That if you're using TypeScript and you have E S lint rules, you know about E S lint, Josh. I love E S lint and I feel like it's the unspoken forced rule that you can, you know, have developers follow. You can write multiple documents, you can have so many like presentations or you know, learning sessions and whatnot, nothing.

• 8:40Speaker 02

  Is more impactful than something that blocks the developer while writing code and gives them information as to why this is a bad pattern. So I think that's very, very important when you are building in React Native, especially it may apply to, you know, other technologies too, but especially in React Native, we have been like exhaustive dependencies. It's such a simple ASL rule, goes such a long way and can catch so many performance regressions. So yeah, that's the second thing. And third thing is, I think just discipline built into platform, you know, defining performance budgets is how long should this screen load take? Should it be under two seconds? Should it be under three seconds? How do we want the navigation to work?

• 9:24Speaker 02

  You know, because React navigation is such a critical part of React and also sometimes the biggest foot gun. Lists, again, in React Native, because we have the virtualized DOM, I think defining what you want to do in that area, creating shared components for it in the beginning, not after a fact, so playing offense for building that shared repositally is the third thing I would advise teams or companies that want to move to React Native.

• 9:53Speaker 01

  It's a lot of great info. The last tip there, you ended with what almost sounds like a design system. I know front-end folks and websites are very often these days building design systems. Is that also all true for React Native apps?

• 10:04Speaker 02

  Yeah, I think so. Shared design system, especially for a React app or a React Native app, is very critical. So we do have a Coinbase design system, which is actually now open source. So if you're writing web code or React Native code, sometimes you won't even realize that you are in a different repo because it's the same design system, you are using the same elements that you would use on a web app, on a mobile app. So that's great, actually. If your code looks like my code, it's a win. If two developers at the same company are writing the same pattern of code, that's actually a great thing. So yeah, definitely, I think design systems are a way to go. We have so many abstracted components in design system like lists, models, trays.

• 10:49Speaker 02

  So you don't have to do the same performance optimizations again and again when you are building new features, they are just given to you. Out of the box.

• 10:58Speaker 01

  That sounds like another example of improved developer velocity.

• 11:01Speaker 02

  Yeah, exactly. And it's also easy to onboard to a design system because there's just a lot of examples, so much documentation, you don't need to reinvent the wheel. So if new engineers are joining your team, they are ready to go super quickly.

• 11:17Speaker 01

  Well, let's dive into some of the more deep and rich end user facing metrics you mentioned, performance. How do you optimize for performance or design or architect for performance in a reactive world?

• 11:28Speaker 02

  Yeah, so I think there are many ways to look at performance. My simple definition of performance is how does the app feel? When you open the app and try to do something that you intended to do. For example, we all open our apps, especially our stocks and crypto apps to check the balance. How is my portfolio doing today? So I consider that as like a critical operation that needs to happen under certain seconds. Also, am I being shown many suspense or like loading states? That's a big turn off. So I try to divide performance into four buckets. One is the cold start metrics.

• 12:11Speaker 02

  Cold start is when your app is totally killed, you open the app, how long does it take for you to land on the main screen of the app? Second is how does the app feel when I navigate between like screens? Are there too many loading indicators? Is it slow? Is it getting stuck? Third thing is how many errors am I experiencing or is the app user friendly? Am I getting full screen errors? And something that's putting me off or not letting me do the job that I came to do, which is check my balance. And the fourth metric that I want to talk about is the end to end journey. By that I mean is I open my app, I see the landing screen, I check my balance. Now I want to buy crypto.

• 12:55Speaker 02

  How long does it take me to get to buying crypto and finishing my trade? That's the other metric that we look at. Before I get into too much detail, I want to pause and Say that metrics are great, but having too many metrics adds confusion. So there needs to be a limit to what you measure and what you improve. If you try to improve every single metric, it's like boiling the ocean. You cannot achieve what you want to, so the focus needs to be extremely narrow when you are trying to improve performance.

• 13:30Speaker 01

  How do you choose which metrics to focus on then? If you've got a big app with a lot of them.

• 13:34Speaker 02

  Yeah, great question. It depends on what's the need of the hour. Like, what should we focus on today? You know, you improve a certain metric and then it, I think it takes two years in my experience for that metric to regress. And then two years later, you're again talking about it. It's also because, you know, the trends change over two years. You just have shipped so much code, new team members have joined. So they don't know the metrics that you talked about. That is why I think automation and guardrails is just so important. So you fix one problem and it never happens again. But unfortunately, in performance world, it does not happen.

• 14:15Speaker 02

  I feel performance is recognizing certain bad patterns and then optimizing it is just a task. It's not something heroic because you keep running into the same problems again and again.

• 14:27Speaker 01

  Performance is a flat circle.

• 14:29Speaker 02

  Yes.

• 14:30Speaker 01

  Let's say that you have an app and you've noticed that cold start used to be wonderful, now is terrible. Let's dive into the tech details of it. What would you do to debug this performance issue?

• 14:39Speaker 02

  Yeah, so we do something called as React profiling. We profile the app, we use React Dev tools to profile the app. See exactly what is happening, which API calls are taking too much time. Is any JS thread operation that is long running on a JS thread? That we can, you know, move or defer to a later time. Do we have bad rendering patterns? Are we re-rendering our code too many times? That's something that we look at. So I think the approach is multi-fold. Bad fetching patterns. Audit the data that we are requesting for cold start.

• 15:20Speaker 02

  We look at any JS long running tasks that we can defer or move away from the main thread. And yeah, profiling gives us all of that data, if not most. That's something that we look at and also sometimes updating React Native versions or moving to the new architecture that you know is out helps with cold start metrics. It's not always your code, it's also sometimes your dependencies and your infrastructure.

• 15:49Speaker 01

  Interesting that you mentioned threads in web land. It's all just one thread and then maybe you use a service worker. But here it sounds like we've got a lot more intricate stuff to work on. How does that work in React Native?

• 15:59Speaker 02

  Yeah, so for React Native, you can fall back to the native thread. I call it the native escape or an hatch. You can defer some of the heavy programming or heavy computation or long running tasks to the native thread. You can also do something like run after interactions. There used to be a hook, it's actually being replicated, but there are some similar things that React Native has been launching. But run after interactions are complete, which means once your screen is loaded, you can run those computations. For example, if you have any analytic events that you are sending back to your service. Now those can run after, you know, all the interactions on the screen are complete.

• 16:42Speaker 02

  So yeah, I think that's the best part of React Native where it lets you hand off certain operations to the native thread and not take away from the JavaScript thread.

• 16:52Speaker 01

  It's a powerful feature. I want to switch gears a little bit and talk about reliability. You mentioned analytics. Let's say that I have an app and it's in production. What should I do to figure out even whether it's reliable at all?

• 17:04Speaker 02

  Yeah, so reliability, I want to say is there is a single user using your app and the app works great. Right now there are hundred users and they are using your app. Does your app scale? Do your APIs respond in a way that they should be? So does it handle traffic? And there are many ways to look at reliability. Ability, one is obviously, am I able to get the data from back end or do I just see a bunch of errors? So the way we do it is we have certain reliability metrics, the biggest one being error rates. Error rate is we categorize them into a few buckets. Error that blocks the user, error that does not block the user.

• 17:48Speaker 02

  And a blocking error is not just a full screen error or something. But if a user is not able to perform a journey that they intended to do, that's considered as, you know, something that's blocking the user. We monitor them literally every minute of the day. Our eyes are glued, like if you are on call, that's like your biggest responsibility. Because we have high traffic and also being in an industry which is influenced by like even tiny like price movements in like major crypto assets, we have to be on top of it. So if we start seeing like these errors spike up or until we immediately start investigating, okay, is there a price movement? Is our traffic spiking?

• 18:33Speaker 02

  What's going wrong? What do we need to do to, you know, figure out? So we start that root cause analysis and this is very established framework at Coinbase on how to figure out if something's happening. So error rates is our biggest metric. Also like traffic usages, if we see some of our critical services seeing very high requests per minute, that is also another indication that, okay, something's happening or why is this happening? Do we need to investigate it further? So yeah, those are some of the metrics that we look at.

• 19:07Speaker 01

  It's interesting that you talk so much about end user behaviors like price surges. Do those in your experience have a significant impact on stability of the app or areas that you have to focus on?

• 19:18Speaker 02

  Yes, they do. And that's something that also drives most of our optimizations, honestly. Because we experience like new scale. Like so four years ago Coinbase had X million of users and now we have even more. So once the user scale, we have to scale for it. And the user behaviors definitely drive what we do because that opens like a new can of worms or like presents new challenges to us because I think user behavior is driven by the UI that we ship. And if we change certain aspects of the UI,

• 19:57Speaker 02

  we need to measure or we need to see if that's actually scaling well. So that is done by experimentation. We do a lot of experiments. If we are shipping like an ambitious change, be it infrastructure or be it a product change, we do it behind experiments. So we analyze the behavior and control and treatment and see if the treatment is actually one that is going to be permanently shipped and if we are ready from the infrastructure side to scale that behavior.

• 20:27Speaker 01

  Must be devastating as a developer to work on a feature, to launch an experiment and then to decide not to ship it. Is there anything you can do to make that feel less stingy?

• 20:36Speaker 02

  No, honestly, it sucks. I have been there. I have had not too many, I want to say, just maybe one that was resolved to control because it just didn't move the user engagement metrics. It's very disheartening. To delete that code that you have written, it's very disheartening, but it is what it is.

• 20:56Speaker 01

  Yeah, better that than shipping something worse for users.

• 20:58Speaker 02

  Exactly, exactly. Yeah. Customer is the ultimate, you know, power.

• 21:05Speaker 01

  Hmm. Speaking of customers, as you grow as a company, the way, for example, Coinbase has, you pick on different kinds of customers. A lot of companies start, you know, North America or United States, perhaps even California focused, and next thing they know, they're shipping to Europe and Africa and Asia. Has that changed significantly, the areas of the app you look at or the way that you deal with users or packages?

• 21:25Speaker 02

  Yeah, so Coinbase is obviously global, as you know. And from my view, when it comes to just performance and reliability, we do not have the same devices across the world, right? So when I look at performance and reliability metrics, I see so many devices. And if you look at like P seventy five metrics and P ninety five metrics for these devices outside of United States, they look terrible. And you have to do, improve and, you know, improve those metrics because those users are also key users of the app. And even though our like user base is very like North America focused,

• 22:06Speaker 02

  we want to grow in those areas and make Coinbase the crypto app that everyone uses globally. So it's critical that you optimize those user experiences. I think time is money. And if it's taking me six, seven seconds to do something extremely simple in an app, I'm going to just move to another app because there is no shortage of apps today that let you do the same thing. But if you want to build user trust, you need to make efforts to build that trust by making sure your app is actually letting the users do what they want to do and quickly.

• 22:45Speaker 01

  Let's say that you receive a bug that a user on a particular device, very common in, let's say, India, is experiencing slowness. And you don't reproduce on your device, but you see the recording that on their device, it is very slow. What do you do to investigate or debug this?

• 23:00Speaker 02

  Yeah, so at least on iOS, thanks to like network link conditioner, you can simulate the network that the user is on and try to reproduce that bug. We also have various like devices. We use a third party tool that lets you run your end to end tests on certain devices that you pick and choose. We also have an external QA team that has like a device farm. So yeah, you know, those are the things that I would typically do to investigate a certain bug. Yep.

• 23:35Speaker 01

  Let's move on a little bit from performance to reliability. You mentioned user trust. Having things break or be very slow erodes that trust. How do you make sure that your app stays reliable, especially as you scale?

• 23:45Speaker 02

  Yeah, there are a few things to look at. One is the load that you are putting on your infrastructure is the number one thing. There are just so many obvious problems that you can find if you start digging deep. One is just over fetching data. The patterns that I have realized don't work well with React Native especially are over fetching data because React has this re-renders and you fetch data that's not necessary. Your app keeps re-rendering, that causes slowness. So when you are designing your API layer or data layer, it's important to fetch just the necessary data.

• 24:30Speaker 02

  For example, if you are in the US and there are some UK or you know, Europe specific compliance things that need to be fetched or shown to the user. I don't need to fetch those for a US user, right? If you're running experiments, right? And I am not part of the experiment group, but the data is still being fetched for me. That's putting load on my backend services and that's totally unnecessary. And it's not always just one request, right? We are in this microservices architecture where one service calls 10 other service that calls 10 other services. So it becomes like a giant fan out and one request from client leads into like 100 downstream requests to your APIs, right?

• 25:13Speaker 02

  So over fetching data is one of the biggest things. The second thing is polling. I think polling is one of my biggest pet peeves in software engineering. I think it's when used incorrectly, it can cause so many issues, honestly, especially in a React Native stack. So say you have polling on screen one, now you go to screen two. The polling is still active unless it's handled properly. That's how like the navigation state works in React Native. So until you go back completely on the navigation stack and you don't discontinue polling, it's going to continue hitting your services all the time, which is again added API load.

• 25:55Speaker 02

  And third thing is, I think, having good guardrails, like keeping a tab on, we spoke about cold start in the beginning. We have a very close tab on how many requests we make on cold start. If they regress, we make sure, okay, what is the need to fetch this data? Can this be deferred to a later time? You know, there is always this battle between showing experiences quickly and then regressing another metric because you want to show certain experiences quickly. So I'm specifically talking about preloading. Lot of people like to preload data, but they don't understand that there is a cost to it. You preload the data, but what if the user never goes to that screen?

• 26:39Speaker 02

  Now you have wasted the preloaded data, right? You need to have like strong metrics to support that, okay, preloading is really necessary because ninety-nine percent of the users are going to go to that screen. Only load data when you are sure about it. Otherwise, you know, you should just stick to fetching data when the user goes to that screen.

• 27:02Speaker 01

  We've now stumbled onto the blog post section of the Q and A.

• 27:05Speaker 02

  Yeah.

• 27:06Speaker 01

  Well, how do you make sure that you design for the correct amount of fetching? That you don't overfetch data, as you said, or even underfetch and not have data available that you need?

• 27:15Speaker 02

  I have tried to automate it a lot because I was working on this topic in twenty twenty-four and I wasn't really successful in finding a way to give that feedback to the developer when they are actually writing code. Like when they are writing, when they are trying to fetch certain data. Can I give the feedback that hey, adding this field right now or fetching this data is going to add, say, like ten requests to your API calls? And that ten requests are going to add, say, forty millisecond latency to your screen. Is that acceptable? I'm still trying to find a solution for it and how we can do that. But if the feedback is not given at like development time.

• 27:57Speaker 02

  I think the best part is, once the feature is live, that's where, you know, experiments come in. You start with a slow. Roll out or you know one percent ramp up, two percent ramp up, observe how it's performing, how it's impacting your infrastructure, what are the number of requests, how can we optimize it? And then continue the rollout of that feature. I think that's what I have been like doing. The one other thing is now with AI, we actually have some AI conventions. When a dev opens a pull request, we find these patterns that are footguns. For example, I mentioned pooling

• 28:34Speaker 02

  is a footcan like network cache, you know, if I see a query asking for data with every time and not using the cache. We ask the developer, the author of the PR that, hey, why are you fetching this data every time? Can this be cached? So that's also like a way to educate the dev that, oh, this is not something that I intended to do. Maybe let me change it back to the cache policy, which is use cache data if available, if not, go and fetch the data. So these are some of the things that we could do to avoid or you know, making sure the app is reliable.

• 29:12Speaker 01

  Do you recommend using something like, say, relay and GraphQL, the way Coinbase does to automate some of that?

• 29:18Speaker 02

  Yeah, I think it's definitely depends on what sort of app you are building. We use GraphQL, as you know, heavily as our data layer. And it definitely has like pros and cons, like every data layer. Yeah. So it actually just depends on the use case of the app.

• 29:37Speaker 01

  So what does GraphQL actually do for or give to your app?

• 29:41Speaker 02

  So as you know, like GraphQL lets you request only the necessary data that you need. And over the years, GraphQL has evolved so much. For example, it now lets you defer certain fields that you don't need right away to render your critical UI. So the way GraphQL good GraphQL is structured is you have one query on a screen which fetches all the data and then you have fragments on that query, which are then passed down to your child components. And in an app like Coinbase. Where we have so many screens, you can end up having a lot of child components. So all that data is fetched on the main screen.

• 30:23Speaker 02

  But having something like defer lets you defer the load of, you know, the data that's needed for your child components and focus on the critical data that you need to render the screen that you are on right now. So the user sees the data that they should and then all the other rest of the data is kind of loading behind the scenes and is being suspended.

• 30:47Speaker 01

  This brings up a lot of the recent developments in React. Suspense and being able to tie data loading to as things come in. That seems like a very kind of streamlined, easier to use system than manually setting this all up yourself.

• 31:01Speaker 02

  Yes, exactly. And in addition to having that being set up seamlessly, I think it's it's one of my favorite loading states, honestly, like it just looks good on the app, like there are no giant spinners anymore. The suspense is so contextual, it looks great, it keeps the user engaged that yes, this is where the data is going to load. This is what's going to happen. And it also gives you so much out of the box for measuring metrics for, you know, how long did this component take? How long did this suspend for? And yeah, suspense instrumentation is something that we use at Coinbase to calculate how much time it took for a certain component to render or even a certain screen to render.

• 31:45Speaker 02

  Like we do calculate the total rendering time of screen using suspense instrumentation. So that's been a huge win.

• 31:52Speaker 01

  Let's segue a little bit into more of the architectural features. Since we're already talking about them, what are some of the other cool things that you're recently excited about with React Native?

• 32:01Speaker 02

  Yeah, so we just enabled new architecture and I am very excited. I think there are so many cool things happening in the new architecture. One is definitely the G S I. If you have been doing React Native for a long time, you remember how painful it was to bridge data between Native and React Native. When we first started building React Native, many of the payment modules or integration with banks, they were just not available on React Native. So you had to bridge data to Native, connect from the Native side, get the response and bridge it back to React Native. And this communication took such a long time.

• 32:42Speaker 02

  And I am so excited that JSI JavaScript interface is finally getting rid of that bridge. Already gotten rid of that bridge. Actually, new architecture is going to make things so fast. And yeah, the next thing is Turbo modules, very excited because we don't use too many native features, but we do like, you know, cameras, then secrets and then storage on the native side. That's going to be like, you know, speeding up very quickly on the new architecture.

• 33:12Speaker 01

  So it sounds like React Native's new architecture is they're rolling out a whole bunch of new features and ways to integrate with Native. What are Turbo modules within that?

• 33:20Speaker 02

  Yeah, so Turbo modules, I say you are interacting with camera or you are interacting with the keychain, which is very native specific. It's time consuming and it adds like a lot of load on the whole infrastructure. So Turbo modules is just something, it's a way of making these native interactions faster for React Native.

• 33:41Speaker 01

  And how does that come into play with apps? Is it not kind of straightforward to just open up the camera in a React Native app?

• 33:47Speaker 02

  It is, but it does go through native layers. That's not something that React Native does out of the box. So we would use some dependencies like React Native camera or, you know, having Turbo modules on React Native just makes it super fast.

• 34:01Speaker 01

  Let's talk about AI. AI is everywhere. What have you been up to with AI in the context of React Native?

• 34:07Speaker 02

  Yeah, I mean Coinbase is, our CEO Brian just tweeted about this two days ago, is we are writing more than fifty percent of code is, you know, AI generated. And I like it, like it's been, honestly, it's been hard to keep up with everything that's been happening with AI outside. But Coinbase is building like tools that we can use, internal tools that we can use, like we have, we are heavily using Claude at Coinbase. We have so many like internal commands that have been built. We have agents, internal agents that have so much context of Coinbase that our day to day tasks are becoming easier and easier and we are able to ship so much code. For example, in the past, I would probably be able to open

• 34:52Speaker 02

  one PR a day, but now I have all these agents. You know, I just give them a prompt, make a nice plan, tell them exactly what needs to be done and then I have five PRs open and it's just massive velocity. But I do think that it's important for you to give the right context to be successful with getting the output from AI. I think that's very important.

• 35:17Speaker 01

  Talking about React Native, how do you set that up so that the AIs know how to deal with your, say, scaled React Native application?

• 35:24Speaker 02

  Yeah, so we have a lot of agents, like conventions, agents dot M D files in contextual agents dot M D files. And if, say, I'm working on a UI component, there are some things that we want the UI component to do out of the box. We want, say, a screen name so that we can measure some rendering metrics. We want something called as page information, which tells me, okay, this is the page that the user error on. I think that's some of the context that we provide out of the box. So when I tell AI that, hey, build this component for me, it knows exactly what it needs to add in my UI component that is contextual to the codebase and, you know, will reduce the back and forth between a human and an agent.

• 36:10Speaker 01

  Have you found that agents tend to write idiomatic React Native code rather than non-idiomatic or idiomatic for something else like React Web?

• 36:17Speaker 02

  Not really, especially because we have so many abstractions. We spoke about design system before and the code may look similar on mobile and web. I have not experienced it writing like React web code because honestly, it may not look that different. Because we are using design system, because we are using React, obviously, in both places, similar lint rules too. So, yeah.

• 36:43Speaker 01

  Have you found that the lint rules are particularly helpful with AI agents? I ask because a lot of developers have reported that AI agents write code with a million squigglies and then with the lint rules they can sometimes clean it up for them.

• 36:55Speaker 02

  Yeah, I think so. I have been using them a lot. Like I use AI to just say, okay, give me violations for this lint rule because people like to disable lint rules and then I say, okay, go fix these lint rules. You do have to check the work. I still see that, especially when it comes to fixing lint rule violations. But some of them are super obvious, but for some you need to check.

• 37:19Speaker 01

  Before we start to wrap up, I want to circle back on something we were talking about earlier. You mentioned that oftentimes metrics fall over, let's say, the course of two years. How do you set teams up for success to not create, succeed, and then gradually fail at their metrics?

• 37:34Speaker 02

  Yeah, so operational excellence is something that we take very seriously at Coinbase. And yeah, there is definitely that two-year cycle. So we try our best to put these guardrails in place that will not regress. I don't want to say regress, but that will not be forgotten two years later. They will regress for sure. That's how the nature of these metrics are. But at least someone's looking at them. So we have so much automation for operational excellence. Almost every single team at Coinbase runs their own operational excellence where they review these metrics, like they review error rates, they look at performance budgets, they look at the number of incidents that happened in the past week

• 38:18Speaker 02

  and try to summarize what happened and how we can prevent it. I think these learnings are so important. We also have these operational metrics bubble up to the leadership. So at org level, we look at them and everyone takes it very seriously. It's not something that you just bucket for like 20% of your time and 80% goes to feature development. This is very like top of mind for every engineer at Coinbase. And even in operational excellence, we are trying to use AI as much as possible. To do the heavy lifting where, you know, do all these queries, get me all the data, find the common themes.

• 39:00Speaker 02

  And we find avenues to share these lessons amongst each other. Because more often than not, there are incidents that happen because of the same root cause. And that is something that we want to avoid from happening. We don't want repetitive mistakes. I think new issues is something that is unavoidable. But I think we categorize wins when the same incidents don't happen two weeks later because of the same root cause. So yeah, operational excellence is something that is very, very critical. And again, a very important aspect of reliability at Coinbase and how we have been able to, you know, stay reliable in the industry.

• 39:42Speaker 01

  Let's cover a horrifying hypothetical. Let's say that you're in a team that traditionally has been very stable, not that many users have used that area of the product. And all of a sudden, a whole bunch of users are using it. So you're getting these new bugs, you're getting slow loading times, your servers are overloaded, and leadership needs a whole bunch of new features from you. What do you do in that situation?

• 40:00Speaker 02

  Yeah, this is the classic panic moment, right? Like as an engineer, like do you focus on the new things or do you focus on something that's broken? I think my thought process is priority, you know, like how bad is something? I'm getting all these bugs, I'm getting all these alerts, but what's the scale of it, right? Is it impacting one user? Is it impacting ten users? If it's impacting a lot of users, we have something called as in severity metrics at Coinbase, where we use that to assess how severe it is. So I think I would just add priorities to all of this and attack it from that angle.

• 40:41Speaker 02

  It's very important that if one user is facing this problem, yes, it is important. Also, it depends on who the user is. That's also something, you know, if that user is some high net worth individual, yeah, it needs to be addressed like today. So I think it comes down to prioritization in the end.

• 40:58Speaker 01

  That makes sense. Jerry, I've got one last set of questions for you. I'd like to end every interview with something non-technical, just to cleanse the palate. What is it like or what is the best part of having a photographic memory for you?

• 41:12Speaker 02

  I think the best part of having photographic memory is if you are somewhere where you shouldn't be and I spot your car, I know that's you. I remember number plates of all my friends, well, not all, but like close friends, also neighbors. And yeah, it's also a fun thing. Like, you know, if I spot you there and I'm like, okay, this person's here, but you told me you are not here. Now I don't care as much, but back in the day, it used to be fun.

• 41:36Speaker 01

  Do you find that having this incredible memory gift is useful at all in programming or your day to day job?

• 41:42Speaker 02

  It used to be. Now with AI, you don't need it as much, but sometimes, yes, like I tell my team, wait, I have seen this somewhere on Slack and I try to quickly go find that because I just know where it was, which channel, who said it. And it helps in remembering like names of people to go back to because I've just, I remember their picture, I remember their name. And it's like a photo in my mind. So yeah, it helps to find people. Back in the day, it used to help me because I used to remember all like the database connections and port numbers and whatnot, but now we don't do that kind of thing. Maybe I'm too old now, but yeah, that's just, but it does help in many ways. Yeah.

• 42:26Speaker 01

  That's so cool. Well, great. Thank you so much, Manjri, for coming on. We talked about React Native, the trade offs, when to use a performance reliability, scaling, architecture solutions, kind of team practices around it. Last few questions on that. If you wanted to get started anew as a React Native developer, where would you go?

• 42:43Speaker 02

  Honestly, now that we have so much AI stuff, other than, you know, React Native websites, yeah, just take help from AI, have them build that greenfield app for you and ask the questions right in your prompts. And I think it's the best way. I think if you're starting as a new React Native engineer, I think AI is a great friend to have. I wish I had it back then because I could ask AI dumb questions and not get judged, but unfortunately I didn't have AI back then.

• 43:13Speaker 01

  It is nice to be able to ask dumb questions and not get chucked. You know, not everyone can support that on either side.

• 43:19Speaker 02

  Exactly, yeah.

• 43:20Speaker 01

  Well, great. There's AI, there's React Native dev. A lot of great resources out there for this technology. And about you, let's say someone wanted to find out more about you or the work you've done at Coinbase. Where do you direct them on the internet?

• 43:31Speaker 02

  Yeah, LinkedIn is the best way to get hold of me.

• 43:35Speaker 01

  This has all been a lot of fantastic info. Manjiri, thank you so much for talking us through React Native. This has been really wonderful. For Software Engineering Daily, this has been Josh and Manjiri. Thanks for listening, everyone. Cheers.

• 43:46Speaker 02

  Thank you for having me.