Jed Bartausky:
Welcome back to another episode of the React Native Radio Podcast. Episode 373, Real Life React Native, Mark Goldstein with Chime.

Mazen Chami:
Hi everyone. I'm Mazen Chami and we're reviving our series on React Native Radio called Real Life React Native. This is the series where we interview developers who work on real life React Native apps. They're quick, rapid fire, and fun. Let's get started. Today I'm sitting down with Mark Goldstein, who leads the mobile platform team at Chime. Mark, go ahead and introduce yourself to our listeners.

Mark Goldstein:
Hey everyone. Thanks for having me. I lead the mobile platform at Chime. I have been working there for just about two years and really love the React Native space. So really excited to be here talking with you all.

Mazen Chami:
Thanks for coming on, Mark. We appreciate it.

Mark Goldstein:
Yeah.

Mazen Chami:
Now let's get into our questions. So what's the elevator pitch for your app?

Mark Goldstein:
So Chime is a US-based FinTech company that provides banking services. Our main goal is to provide helpful, easy to use, free banking services. We now serve over 10 million monthly active users through primarily our mobile app.

Mazen Chami:
When did you start using React Native and why?

Mark Goldstein:
Well, we first launched our app in 2014. We moved to React Native in 2017. The main reason was consolidation and simplification. With React Native, you have one product surface, mental model, review cycle, and release to manage. Over the time, we've seen many different moons and evolutions. We lived through migrations to Hermes, new architecture, navigation migrations, and much, much more.

Mazen Chami:
What is the architecture stack that you all have and how did you come to choose it?

Mark Goldstein:
Our stack has evolved over time quite a bit. So we're using modern React Native. So Hermes, new architecture, our code is almost entirely TypeScript. We use and leverage Expo Modules quite a bit as well as our own native modules. React Navigation with our own implementation for some of our own use cases, as well as Redux, persisting state, GraphQL with Apollo, and a shared component library and design system. We also have a few implementations using Reanimated, Skia, Filament for some of the more complex animations in the app.

Mazen Chami:
Can you describe some unique challenges you all encountered while developing your app using React Native?

Mark Goldstein:
Yeah, definitely. There are a few performance challenges that come up naturally, especially when operating at this scale. One comes to mind around measuring telemetry around startup. For Android and iOS, there are different implementations. The app life cycles vary. And for Android, the lifecycle handlers can get triggered by things you wouldn't expect. So we measure app cold start with Android using React Native Performance, and we're seeing really odd numbers for above P75s, things in the magnitude of hours. We ended up figuring out that the issue was that when you switch your appearance natively for your theme, let's say going from dark mode to light mode, that re-triggers the lifecycle hook that we were using in Android to track the telemetry. But the React Native Performance package we were using didn't clear the observers. As a result, we would get telemetry that was claiming a cold start was many hours long that was scratching our head.
So a lot of times there are these cracks and crevices at this scale that really can skew your P50s and above that can really make things look odd.

Mazen Chami:
Are there any other challenges that come to mind?

Mark Goldstein:
Yeah, definitely. One big one we saw was around warm start and the performance of screens loading related to build time Babel plugin for GraphQL. So we use lots of fragments and there is a setting by default that basically compiles these fragments at runtime, which can be really expensive when you have lots of them. There's a plugin called Babel Plugin GraphQL Tag that can pre-compile all of them that basically brings down the time for loading and that runtime tax to almost zero. It was able to save the performance of the warm start and loading of screens tremendously. And if you're using GraphQL and seeing your app scale and the time for loading scale linearly with that, I highly recommend you look into that. There are also a bunch of other optimizations for your app that you might want to look into relating warm starts, things like making sure you have some defaults that may not have been default in the past, some defaults that you may have switched to false inadvertently, things like inline requires and other settings that might be slowing you down.
One other quick one is general cross-platform and consistencies. Just because something performs well in iOS, it doesn't necessarily perform well on Android and the native API differences, we've definitely run into a bunch of hiccups around things like keyboard and things like that.

Mazen Chami:
Yeah. All those challenges sound very familiar, so it sounds like everyone else is dealing with the same thing.

Mark Goldstein:
Yeah.

Mazen Chami:
So how do you all handle testing in your React Native application?

Mark Goldstein:
Yeah, testing is a broad subject. There's two main angles for this. One is a strong dog fooding culture and then there's actual testing and code. Generally, we have a strong dog fooding culture, which we enable with an internally distributed auto updating app for employees that allows you to get the latest remain, check out pull requests, codes and leverages some of the superpowers of React Native over their updates to check out changes in seconds. In the actual code quality side of things, we use a mixture of unit tests, some selective snapshot testing, a suite of end-to-end tests with Detox and a few dynamic CI pipelines to determine what suites to run. We're also looking into and building agent-based adversarial user acceptance testing, something like a CI check that pulls your app, takes a test plan and runs your PRs changes in a sandbox to validate the intent and behavior.

Mazen Chami:
That's cool. Leveraging AI these days, taking many different routes and this is definitely one that we can have it leverage.

Mark Goldstein:
Yeah, it's kind of a hot one now. It's a bit tricky. There are real questions to ask of how it scales the price and efficiency. There are a lot of solutions coming to the market now and it's really interesting to see how that place, that space evolves.

Mazen Chami:
Can you share some ways in which you've optimized performance for your app?

Mark Goldstein:
Yeah, so I shared a little bit of the challenges previously that are related, but in terms of optimizing that are related to that, instrument first has helped us tremendously. Being able to measure your app and have telemetry enables you to have clarity on what to optimize, what to fix. So things like cold start, warm start, time to interaction for a screen, different loading states are really helpful. Build time optimizations for development is incredibly rewarding as well, especially if you have a larger team setting up something like a remote build cache and leveraging Expo Fingerprint to decide when you can leverage a build cache build for your development or your agent or when you actually need to rebuild is incredibly powerful. We found that even with an eight plus year old app code base like us, only 5% of pull requests actually change the fingerprint and require a rebuild and you can save 95% of the time of building the app for most machines, so that's a huge one.
Generally going more into the product side of things, warming up things that are slow on first call for your app startup, not awaiting things that don't need to be awaited, really important. There's a tendency to use FlashList, Legend List, all these amazing lists everywhere. It's not always necessary. So I would recommend not over migrating, but making sure you have the telemetry to rationalize that change and some more trivial ones like making sure you have Hermes, Newark using Expo Image or something similar that is going to make sure that your images are efficient is really helpful.

Mazen Chami:
So these days everyone uses packages that have native modules within them, and I think we all use them and the developer experience is good within it, but have you all had the need to build any custom native modules?

Mark Goldstein:
Yeah, definitely. There are a few that we built out. One is for our native widget, a way for you to see your balance on your home screen. There are other ones that we've used for things like lifecycle observers for app state changes to handle analytics and other privacy screens. Then there's also ones for special animations, authentication and other supporting libraries for our native modules that we use in the app. One thing that becomes kind of tricky is when you are building native modules for custom implementations is building on each individual platform and then building for the third platform. I've seen a bunch of different patterns and currently we are moving from the legacy inter-op layer of writing native modules to trying out Expo Modules pattern of writing.

Mazen Chami:
Have you dealt with cross-platform differences, iOS versus Android while using React Native and how did you solve them?

Mark Goldstein:
Yes, there are a few that come to mind. One is around keyboard handling. There's different behavior in iOS and Android that we've implemented, things like date pickers, animation, and I think really the bigger ones are around lifecycle, similar to the issue that we talked about for app startup measuring and also build pipelines that are completely different. One other thing is around profiling. They're very different Xcode Instruments as opposed to Android's tooling. It's quite different. Android has Flashlight, which is only Android, Perfetto and the native Android Studio tools that require custom knowledge.

Mazen Chami:
How are you all using AI in your day-to-day workflow?

Mark Goldstein:
Yeah, we use AI quite a bit. We recently shared that 84% of our changes are AI assisted. We use AI at every point of the development process with humans in the loop. Generally, we have many different tools to help develop with AI. Most engineers use tools like hot code, Cursor, Codex. We're also building our own software factory, which we recently announced Archimedes that builds alongside engineers. In terms of actual mobile development, we have lots of skills that help from things as trivial as making a new screen, using the correct components from the component library, including analytics, feature flagging, kill switches to more intense developer assisted flows, things like AI prototyping, using things like the Maestro MCP and other MCPs to actually take a prompt and a Figma design and validate the changes that it makes across the design. We also have analytics skill to help you validate that your analytics is up to date with the spec and other MCP servers and tools, things like Argent to help debug and go through profiling issues.
Another area that we're using AI is for triaging and monitoring. When we have a new release and there's a spike of an exception or stability goes down, we have an agent triager, what we call, that investigates the issue, determines the likely cause, potential fixes, and leverages ownership data to attribute the potential team and also the pull requests that could have introduced the issue.

Mazen Chami:
Awesome. So it sounds like you all are using AI beyond code generation also with testing, debugging, writing documentation. What about one thing recently I've been seeing a lot of is code review.

Mark Goldstein:
Yeah, we use AI for code review quite a bit. There are a few tools that we have to use for that, things similar to BugBot and our own internal tools that help give you confidence that what you're building is likely correct. One thing I want to point out around Chime's culture and general culture with AI and code review is the importance of a human in the loop and validating the behavior, even with PRs that are automated by AI generated, AI validated, have a screenshot. There's a strong culture around a human testing the changes, validating the code, and having that human validation before things go to production. A lot of the motivation for the dog fooding app and over the air updates for internal distribution is to make the human in the loop as easy as possible. So when there's a PR, even if the AI generated it and the tests and the review looks good, you are still expected to check out that branch's changes in the dog food app, and that is handled all automatically now with the infrastructure that we've built.

Mazen Chami:
Awesome. Where has AI fallen short or burned you?

Mark Goldstein:
There are definitely a few places where AI doesn't really deliver on the full promise. One I may have hinted at already is intent versus behavior mismatch. Just because an agent makes a change, writes some unit tests, they all pass, opens a PR, or even has the ability to take a screenshot and attach to it, the behavior might not match. One example is an agent implemented some feature to copy some text. It wrote beautiful tests, the PR looked great, but when I went to check out the changes on the dog fooding app, when I copied it, it copied the whole Markdown, so lots of additional data that I wouldn't want there. There have been numerous other examples where this has come up where a feature doesn't really work. One example is a list of items where only one item is pressable, so on and so forth.
So the intent versus behavior mismatch. There are other areas that more commonly you may have seen that aren't mobile specific, things like over complicating simple problems, creating unnecessary systems, and generally creating systems that don't have the context that you may have as someone who's worked in the industry or company and has opinions on the direction of a technical decision should go.

Mazen Chami:
Absolutely, yes. Sometimes AI loves to write more than you ask it to. I get it.

Mark Goldstein:
And then when you tell it to go another way, it tells you you're absolutely right.

Mazen Chami:
We're always right. What advice would you give companies considering React Native?

Mark Goldstein:
If you're not considering React Native, you should. Generally, the keynote at App.js this year, Charlie shared how React Native is winning in the AI era, and I tend to agree. There was another talk around rebuilding an app on Native only, Swift, Kotlin and React Native. I think React Native is no longer a question of something to be considered or not. It's something you should, if you haven't considered, is a huge missed opportunity, especially as coding has. With AI LLMs, the levels of abstraction of engineering is going higher and higher, and this is where React Native has a superpower. React Native is native, and when you do need to go and build iOS or Android or even web-specific features, it's all supported. The ecosystem and the documentation is unparalleled. There's a lot of documentation with the existing web, the existing documentation for web JavaScript support type script, and the ecosystem that Expo has created, navigation, and the history that React Native brings on top of the existing documentation for Native, for dipping into Native when necessary, really provides you a superpower.
Additionally, some unique React Native productivity gains is unparalleled. Fast refresh is something you can't really get in iOS and Android to the same extent you can get it in React Native. Over their updates, both for internal development and now AI assisted development and iteration is extremely valuable, and the ability to do over their updates in production to your members is a huge advantage.

Mazen Chami:
What advice would you give to new React Native developers?

Mark Goldstein:
Well, the first piece of advice, probably the most important, is to attend conferences, particularly ChainReact.

Mazen Chami:
What?

Mark Goldstein:
Joking aside, I really do mean that. Go to conferences, ChainReact, App. And other local meetups is so valuable. Meeting the people who are building things, shipping things is so impactful, so meaningful, and really I've come away with huge lessons and been able to provide a lot of value for my own career and for my company from these experiences. More technically, I would say learning one native platform deeply is super valuable. Understanding the debugging tools, profiling tools, and APIs is really important. Also, the deployment process for each one helps. Making sure you test on real devices. The ecosystem for testing remotely has gotten really great, but testing on a real iOS and Android device is worth it. You can pick up a modern popular Android device for 50 bucks. Having a strategy for feature flagging, telemetry and ownership is super important, especially if you're working at a company as opposed to an independent developer.
Once you have large complex systems, adding those things can be complex, costly, and extremely non-trivial. That's what I would say. And just do it. Just do it. Keep going. Just do

Mazen Chami:
It. Mark is not a spokesman for Nike.

Mark Goldstein:
No, I'm not.

Mazen Chami:
Would you still choose React Native if you could go back with the knowledge you have today?

Mark Goldstein:
Most definitely. React Native has been really good to me and the companies that I've worked with. The ecosystem has evolved in the best ways possible. I feel at least some part of it is luck, and the other part is just the incredible skill and contributions of the React Native community. Like I said earlier, it's something that I believe almost any use case you should consider. There are some edge cases where maybe it's not the best case for you, but I've seen even great games built with React Native. Generally, if you're building an app that is not a completely net new problem or net new experience on a mobile device, I highly recommend it. I would absolutely choose React Native if I can go back with the knowledge I have today. The changes of the space with new architecture, Hermes, and the development of the platform has been amazing.
I feel lucky to be a part of it and to see the space evolve and the new changes with React Native and now the React Foundation are all really exciting and encouraging that this was the right decision and I would do it all over.

Mazen Chami:
Awesome. Well, thank you, Mark, for joining us today on our real life React Native series. We really appreciate it.

Mark Goldstein:
Yeah, thank you so much. Really love talking about these things. If I can plug just a couple things, my team is hiring. If you are a cross-platform engineer who's passionate about developer experience and large scale info problems, reach out. I'm at mark.goldstein@chime.com or find me at LinkedIn. Also, I'll be at ChainReact. Say hi if you see me. Love to chat and thanks so much for having. I'm a longtime listener of the show and super appreciative for this opportunity, so thank you. Hope this was helpful.

Mazen Chami:
Of course. Yes, it was. Thank you so much, Mark. If you'd like to be on this new series and talk about your experience using React Native in the real world, email us at rnradio@infinite.red and introduce yourself and your app, or feel free to reach out to me on our Slack community at community.infinite.red. See you all next time.

Jed Bartausky:
As always, thanks to our editors, Tyler Williams and Jed Bartausky, our marketing and episode release coordinator, Justin Huskey, and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze, and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.