Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast. Episode 367, Ask Us Anything with Robin and Mazen.

Robin Heinze:

Mazen, it's really good to have you back.

Mazen Chami:

Thank you.

Robin Heinze:

Where did you go?

Mazen Chami:

I was in Poland for App.js, Kraków.

Robin Heinze:

Ah, I see. I think a lot of people were at App.js.

Mazen Chami:

Yeah, it was a good turnout. I believe there was about 400 or so attendees.

Robin Heinze:

Did you meet some cool people?

Mazen Chami:

I did. I met a lot of cool people. A lot of people that we will be having on the show for a Real Life React Native or even just for an RNR episode. So yeah, a lot of good conversations. I went with Gant and Frank.

Robin Heinze:

Oh, that's always fun.

Mazen Chami:

Yeah. Gant gave his

Robin Heinze:

Talk. Gant, he has to be one of the most fun people to go to a conference with of all time. And he was speaking. So if you guys are listening to this and you are at App.js and you saw Mazen or you heard Gant's talk and you liked it, give us a shout on Twitter. We'd love to hear about it.

Mazen Chami:

And if you are at App.js and you want to go to Chain React, reach out to us. We got a nice coupon code that's actually I believe 20% off for anyone that

Robin Heinze:

Reaches out. Can we just tell them? Can we?

Mazen Chami:

We'll just ask for forgiveness later. Sure. APPJS20. That's the code. Very hard.

Robin Heinze:

There you go. Someone could

Mazen Chami:

Have cracked the code.

Robin Heinze:

Consider that our gift. Our gift to you. APPJS20 for listening to this episode. Thank you.

Mazen Chami:

Yeah. Just don't tell the editors or the owners that we put that in there. Yeah, no, it was a nice trip to Poland. Good people, good food. We got to hang out with the Maestro team and hear more about them. I got to hang out with Aaron Grider for the first time in person. He's over at SpaceX Starlink doing some cool stuff there. And a lot of people, David Leuliette, Jamie Birch. Awesome.

Robin Heinze:

I could keep going

Mazen Chami:

Here. But yeah,

Robin Heinze:

All these people will

Mazen Chami:

Be on the show soon.

Robin Heinze:

Okay. I did want to ask you, people aside, Kraków versus Wrocław in Poland, which is the better city? You've been to both now, right?

Mazen Chami:

Yeah.

Robin Heinze:

Yeah.

Mazen Chami:

Let's see here. Let me think about this. Let me give a long, hard... I don't have to. Kraków. Yeah. Okay.

Robin Heinze:

So why is Kraków

Mazen Chami:

Better? Anyone from Wrocław or that lives out there or prefers Wrocław. It's different in the sense that Kraków, they both, they have history. It's an Eastern European city that has years and years and years of history. But Wrocław to me didn't seem like it was a very touristic town. Now mind you, a lot of European cities these days are overrun by tourists, but Kraków didn't seem like that. There were tourists, but it wasn't very busy. The streets weren't as crowded. Sure, Thursday night or so, the city center, the square was pretty busy. But again, that's closer to the weekend and stuff, and that makes sense. There seemed to be more life, more restaurant options, more bars to hang out at at night and stuff. And it was a bigger city too than Wrocław. So yeah, there's that. And now my opinion could be a little skewed here because when I was in Wrocław, I was giving my first talk.

So I was in the hotel room quite a bit.

Robin Heinze:

You were a little stressed out, Mazen, huh?

Mazen Chami:

And in Kraków, I was just -

Robin Heinze:

You were having a good time.

Mazen Chami:

Gant and Frank and having some fun.

Robin Heinze:

You made Gant do all the work. Well, that's amazing. I'm super jealous. I hope to get to go to one of the Polish conferences someday. You

Mazen Chami:

Should come with us one day.

Robin Heinze:

Sounds like a lot of fun. All right, you tuned in to hear us talk about React Native because this is a React Native Radio podcast. And so we will do that in just a second, but before that, we need to hear from our sponsor.

Jed Bartausky:

Infinite Red. Infinite Red is a premier mobile app consultancy focused on Expo and React Native. We're a team of 30 that's located fully remote in the US with highly experienced mobile app developers. And we've been doing this for over a decade. We're also one of the first development teams to adopt agentic coding in a way that keeps high quality standards while also being able to dive in and do things the old school way if we need to. If you are looking for mobile app, Expo, or React Native expertise for your next project, hit us up at infinite.red/contact. Thanks. And now back to the episode.

Robin Heinze:

All right, let's get into it. This is a special episode. We don't do this very often. This is our AMA, which if you don't know what AMA stands for, it stands for Ask Me Anything. There's two of us, so I've been calling it the Ask Us Anything, but I think it originated from Reddit? Yeah. Maybe it was somewhere else, but I think Reddit made it really, really famous, but it's just you send in questions for us and we answer them. That's the idea. And you guys definitely delivered. We got tons of questions. I really apologize that we won't be able to get to everybody's, but we'll get to as many as we can and I'm excited. So let's just start it right off with a question from some guy named Gant Laborde. Yeah.

Mazen Chami:

Who could that be?

Robin Heinze:

Gant very kindly sent us a question and it was a good one, so I decided to kick us off with this one. Gant Laborde on Twitter said, "You all use React Native from many angles, open source, consulting, conferences, et cetera. What's one thing that teams outside that bubble, like fresh clients, consistently underestimate?"

Mazen Chami:

That's an easy one for me. I think it's how large the community is for React Native. When you look at other, not even cross-platform, let's just talk iOS and Android, so Swift and Kotlin, those communities are smaller. Now, sure they get larger pulls at their conferences and you hear about thousands of people going to those conferences. That's fine, but put yourself in those shoes where you go to a thousand plus person conference. One, it's intimidating. Two, I doubt you're really meeting people. The speakers might also be people that after they speak, they go through some tunnel and they disappear for the rest of the conference. You don't get to see them. But the React Native community is truly the nicest people that communicate with people in their community. You see that on GitHub. Some great packages are there. And again, I said it to some people at the conference and there was this young gentleman that approached me at App.js.

He had just graduated college. His boss had told him, "Hey, time to do a React Native app." He was not a React Native developer and he started learning React Native and they were like, "You go to App.js and learn a little bit more." And he found it incredible that the speakers who were talking on the specific topics, he was doing a desktop topic and he was asking me questions about it. I was like, "You know what? I'm not the expert in the room here. Let's just go talk to Jay Meistrich and Jamie Birch, put them in touch." And he came to me later in the conference and was like, "This is great. Everyone's so friendly. I get to talk to the speakers, learn from the people that are building it, the pain points and what's working." And he's like, "That's great." I don't think you could get that at any other conference.

So my point is the friendliness and the openness of this open source community that makes React Native what it is and makes it so successful.

Robin Heinze:

Yeah, that's a really great point. Just the strength of React Native as a whole. There's a lot of doubters and people who say it's a dying framework or it's not worth using. And I just don't think they're inside the bubble and they don't see how big the community is and how strong it is and just what it's capable of, honestly. There's a lot of people outside the bubble that don't realize how close to native you can get with React Native just because you can always dip into the native layer and just basically build the same thing that you would in a native app. So yeah, really good answer. Let's move to the next question, which is from Pedro Castro, handle Knoodle. It's Knoodle with a K and an N on Twitter. Since Infinite Red works heavily with consulting, have you noticed significant shifts in the types of problems and challenges that clients are bringing to you over the last eight to 12 months?

Mazen Chami:

That's a great question. That's a great question. It's essentially asking has the landscape shifted over the past year, what clients are doing?

Robin Heinze:

So it's a good question. I would say yes, we have seen a shift. Whether you could argue if it's significant or not is semantics, but I definitely think there has been a shift. A lot of clients now are coming to us with a team already iterating on a React Native app, probably maybe with AI tools and agents, and they want us to offer our React Native expertise to help make sure they're not going off on a wrong path. They're still coming to us for React Native, but it's sort of a different flavor because their teams are often a lot more empowered to write some stuff themselves, but they still don't necessarily feel like they have the expertise to evaluate whether things are going well and to really dig into the heavier, more complex problems where you really want architecture decisions and stuff still being made by a human.

Even if it's a human guiding an agent, it's still a human sort of in control. But yeah, it's still a lot of React Native, but just with AI flavor, if that makes sense.

Mazen Chami:

Yeah. And one thing that I have noticed too is in the past, most of the time we were coming onto a project to a team that did not necessarily know React Native. It was more of a, let's just say a business leader did their research, React Native is the way to go. And then they were either starting their app or potentially changing their brownfield app into a React Native app. And they were like, "Okay, Infinite Red are the experts. Let's bring them in to work on this project with us." And then we were coming in and doing more of training and giving the visibility like, "Okay, what is React Native in a nutshell? How does it work?" And all that. We've almost skipped that and we've moved forward. It almost sounds like we went from working initially with junior or fresh React Native teams to more senior plus React Native teams.

Robin Heinze:

Right. Our clients either didn't have devs or mobile devs at all, or they had previously native devs who were in the process of learning React Native or becoming React Native devs from being native and just didn't know anything and needed our help from soup to nuts. And now AI can help get them a baseline. But when you're shipping a production app, a complex production app to a ton of people, you want probably a lot of them want more confidence than agents will give them, but it does increase the baseline that they can do without bringing in consultants.

Mazen Chami:

Because again, it's like that whole thing where AI can get you somewhere, but you still need that human senior engineering judgment to come in. And as the experts, we will give that opinion and help you get past that barrier and make sure your app is five star. That's how you say it.

Robin Heinze:

Awesome. Great question, Pedro. I think it's a question a lot of people are asking at the moment. Yeah. All right. Next question is from Sean Barker who's on Twitter, SeanBarkerDev. AI made a big impact on the amount of software that teams are able to ship, but I think most users would say that it has had no positive impact on their experience. What practices do you think teams should adopt to make sure quality is just as, if not more important than quantity?

Mazen Chami:

Yeah, so I've said this on the podcast before. Let's go back a little bit, couple, what, six months or so. When AI first had that big explosion, it was hard because you're just sitting there watching this text fly on the screen. It's a lot of information, a lot of stuff happening. And it was almost that system overload where you just almost burnt out is probably the best way for me to describe it for myself. And now things have shifted a little bit where we've gone over that hump. And maybe the best way to say it is we now know how to use AI or we're using AI better. Because in the past at the beginning it was just like crank it. Yes, go, go, go, and get that output. And then we realized that, wait, hold on, that output might not have been great. We need to slow down.

So for me, I think some practices that I've adopted is, I don't know if you're familiar, Robin, with Matt Pocock's skills. He has two.

Robin Heinze:

Yeah, he has a couple. GrillMe is one.

Mazen Chami:

GrillMe and TDD. Those are my two favorite ones from him. I believe there's one by Vercel, if I'm not mistaken. It's like React Native best practices. That's a very good one too. And using some of the, again, you could say don't overload it with skills and all that. I think for me personally, if you're building a React Native app, those three are the best ones to do if you're developing an app, make sure you have those set up, make sure you have your agent files, all those configured, you need them for your project, whether it's React skills and stuff like that too. And at that point you can ensure that the quality will get a little bit better because the plan mode is very important and you need it to grill you. That's why I like GrillMe because before GrillMe, it would ask you one question and just completely agree with everything.

But wait, there's a lot of context here that you might be missing out on. So GrillMe is great for that.

Robin Heinze:

Right. It asks you one question and it's like, cool, I asked them a question.

Mazen Chami:

Check. Yeah, exactly. Exactly. It checked a box. It was like, you told

Robin Heinze:

Me to ask you a question. It didn't actually assess whether it had the full picture of what - Yes.

Mazen Chami:

And maybe that's also a testament of the times where AI has gotten better at understanding context more by just reading the code, but there's that. And then the other thing we've talked about a little bit here, and it was kind of Gant's talk at App.js, but TriForce, we mentioned it here internally. It's basically AI governance. And if you haven't listened to that episode, I would recommend you listen to it or even watch Gant's talk at App.js. AI governance is very important. So putting together a practice of how do you or even who maintains code quality, who maintains the code integrity? So keeping those two high is very important. So find your swim lanes as a team and be sure to push with that and always, always, always still have the human have the final say.

Robin Heinze:

Yeah. TriForce is really cool because it addresses the problem of the fatigue that it causes for a single developer to not only be vibe coding and creating features very quickly with the help of agents and also trying to maintain architectural integrity and quality and performance and accessibility and all these things. And it sort of is a system where, okay, let one person just go, hey, I'm vibe coding. And then you have other humans whose entire responsibility it is to maintain integrity in various areas. And it sort of rethinks the division of labor in the engineering world. It's very cool. Listen to the episode, read the blog, we'll put them both in the show notes. But yeah, very important for humans to still be involved and to have agents checking their own work too. There's something to be said for using agents thoughtfully, not only to write the code, but also to review the code.

Agents are good at that too. And having a system where every PR is reviewed by an agent as well as a human. And there's lots of different tactics that people are taking. All right, really great question, Sean. Another one that I think a lot of people are thinking about constantly these days. All right, this one's from Josh Yos also on Twitter. What is one of the most challenging performance problems you have dug into on a React Native app?

Mazen Chami:

Can I mention performance? How do I phrase this? If you're listening to the episode, you know who you are. But not a performance problem, but a performance... Let's try and push React Native to its limits based off

Robin Heinze:

Of performance. I know what you're talking about.

Mazen Chami:

Yeah. Okay. I need to make sure the lawyers don't call me mid-sentence here.

Robin Heinze:

A client.

Mazen Chami:

A client asked us -

Robin Heinze:

Who shall remain very nameless.

Mazen Chami:

Very nameless. Reached out to us and asked us to do a spike on React Native. So essentially we do the spike, we prove out their points, we answer their questions, and then after the six months, we can then move forward and build the app in React Native. They gave us challenges and the idea of these challenges were to find where React Native breaks. And I want to say they came from a good place, but I kind of want to say they came from the place where they wanted to find where React Native breaks and report that to leadership. Okay, I've given too much information. The exercise was, and if you know of any app that does this, please hit me up because I had a lot of issues with this exercise in the first place. Okay. The idea of the exercise was a list and the goal was not to use any third-party packages, use React Native packages alone, which already is kind of skewed.

So it was like use ScrollView, not even FlatList, to create a list of tiles of variable heights across the screen. Mind you, it needed to be like 100X the screen. So ScrollView one, I would never use that for a list that big. I would never even use ScrollView for four items, have you? I'd use FlatList if I had FlashList or even Legend, I would definitely use Legend List.

Anyways, I digress. Wasn't allowed to use third-party packages or FlatList. So thousands of items on list, variable height that were drag and droppable while they were being -

Robin Heinze:

Which not letting you use a third-party list component for this is diabolical, but that aside.

Mazen Chami:

Yes. So now I'm not done with the exercise. That's the hilarious part about this, which I have no idea what app does this, so I'd love to know. Well, when you click that item to drag and drop it, as you're dragging it and dropping it and scrolling down, as the screen is scrolling down, every item tile that you're not scrolling in the background needs to be spinning on just like spinning 360 constantly kind of thing while you're scrolling. What was the goal? Find out if React Native can break and if it's not performant. Well, okay, if any of you -

Robin Heinze:

Well, first of all, did they prove that you could do this in native? Was there a control where they're like, native can do this?

Mazen Chami:

Robin, that would be the logical thing to do here. And that was my first question. It was like, "Hey, okay, your app or no app in the App Store does this. Can you do it in native so we can compare metrics?" The answer was no, we're not going to do that because that doesn't make sense. I was like, "Well, it doesn't make sense in React Native either, but that's fine." We did the challenge. It obviously wasn't performant. We did our best to get it as performant as possible. We used third-party packages and all of that, and we got it to a decent place. What would expect thousands of items you're dragging and

Robin Heinze:

Dropping -

Mazen Chami:

Spinning. Spinning. You're talking about Reanimated. We used FlashList at the time, which was early V1. I believe it was even beta at the time and doing all this fancy stuff. We got it working. It obviously wasn't 60 frames per second, but we kept it as high as we could. And I remember, I believe it was somewhere in the high 40s. It stayed while all this was happening, which if you think about the problem, not a bad solution to it. So yeah, that's the one I want to talk about because it was very challenging. The

Robin Heinze:

Most manufactured performance problem. Yes.

Mazen Chami:

Yes.

Robin Heinze:

Did React Native surprise you in how far you could push it?

Mazen Chami:

Totally, totally. I

Robin Heinze:

Mean,

Mazen Chami:

The fact that I was able to do this outlandish experiment and get React Native, it broke of course in certain scenarios, but at the same time -

Robin Heinze:

But we have no idea if native would've broken. We need to recreate the experiment now and actually do it with native doing the exact same thing and see.

Mazen Chami:

Totally agree with you. Yes, totally agree with you. But no app would ever want to do such a thing. I

Robin Heinze:

Think

Mazen Chami:

It was a terrible user experience

Robin Heinze:

Probably. I feel like that would give someone a seizure just from all the spinning.

Mazen Chami:

Yeah. So what surprised me about React Native was it held its own. And as we started bringing in, again, to answer the first question, what are the strengths of React Native? The community bringing in these community

Robin Heinze:

Third

Mazen Chami:

Party packages, it succeeded. It went very far and we were able to get it to work. And in my opinion, again, when we demoed it to the client, they were surprised by the numbers and they were almost calling, almost being like, "You're bluffing. That's not true sort of thing." Which makes me believe they tried it out in native and it did not look good or feel good, but we were able to maybe even get the same or maybe even better. I don't know. No

Robin Heinze:

One ever told us. So they were impressed, but they didn't want to be.

Mazen Chami:

Correct. Correct.

Robin Heinze:

Right. This was them trying to make React Native look dumb. To leadership. Yeah. Yeah. And

Mazen Chami:

If anyone's

Robin Heinze:

Wondering - So yeah, that should tell you what you need to know.

Mazen Chami:

Yeah. And if anyone's wondering, that experiment was never demoed to leadership.

Robin Heinze:

Because it looked too good.

Mazen Chami:

Because it looked better than they expected it would be. Yeah. Well,

Robin Heinze:

That's fine. I think we digressed

Mazen Chami:

A lot there.

Robin Heinze:

That's fun. Thanks for the question, Josh. Let's move on. This next one is from Emmett Naughton. I hope I said that right, from Twitter. And the question is, why should I pick React Native for my next project? And I'm going to actually pull in a second question that's kind of related from Abraham McZorwey, handle Nerdgema on Twitter. I'm so sorry if I'm butchering your people's names. And their question is, I'm thinking long-term, why should I pick React Native over Flutter? So let's answer these ones together. Why should I pick React Native, Mazen? You've been doing some research related to this for your talk at Chain React, which is July 29th through the 31st, please come to Chain React. And use the coupon code. But why should people pick React Native in general? And specifically, why should they pick React Native over Flutter if they know they want to go cross-platform?

Mazen Chami:

Cross-platform. Yeah. These both are very good questions. There's a lot to say to this because, and I'll kind of keep it simple. I don't want to give a lot of off my talk at Chain React too, but one thing I would say is fingers crossed because whenever you have competition, playing and coaching soccer, competition is good. It helps you get better, helps you improve. Hopefully Flutter is just another thing that Google ends up cutting down the line as they do with all their products. And Flutter stays around for that competition to keep pushing React Native. One thing I would say is I wouldn't be able to give you a why to use it because I think everyone needs to use what works for their teams and their app and their organization. What I would recommend though is spend the time and test both of them out.

Because okay, let's keep in mind here, let's say I'm building an app. I don't know if this is true, but let's say I'm building an app that's heavy in animations and you build it both in both iOS and Android. Sorry, Kotlin, Swift, React Native and Flutter. Let's say Swift and React Native for Android work best. Then you have a business decision to make on what is it that you use. I don't know if Flutter is any good at animations. And if they're not, you did the evaluation and you figured it out why it's working. And then there's the other part of it too. Let's say there's a long list application and React Native outbeats Flutter. Well, then that helps you make that call for your app. So pick one that shines and has the strength in the platform in the type of app that you're building.

It kind of goes back to my previous question. Use the right tools for the project that you're on. And then one thing I would say is why pick React Native for your next project? To me, it always goes back to the community and having Expo and all these large organizations backing React Native. Because I know for a fact whenever I look at any issues on the Expo repo, I see a lot of engagement. I see a lot of feedback from the Expo team giving you the answers to it and all that. And as part of my Chain React project, I was in the Flutter repo for a while trying to figure things out and there was a lot of friction when I was in there. So to me, React Native outshines these platforms in more than one way. So come to Chain React to hear more about this topic.

Robin Heinze:

I mean, I think we can also point a lot back to our answer to the first question, which was the size of the community and the ability to recreate things in native. And like you just talked about with performance, React Native is incredibly powerful and can emulate the native experience better than a lot of people think. And yeah, it's just a no-brainer pick if you're trying to be able to ship quickly and maximize your team and what they're able to output. Even with agents, if you have agents building two native apps versus agents building one React Native app, the speed of everything gets faster, but React Native still wins out over native in terms of keeping things consistent and going quickly.

Mazen Chami:

Yeah. And if you're a listener and your app is built in native, please reach out. I'd love to hear what you and your organization's reason were for going with native or even for that. I really hope the editors blurred that out every time I say it. That would be hilarious. I don't know why that just came to my mind. Yeah, because I'm also genuinely interested in what the reasonings were because that helps paint a picture for the strengths of React Native and why it works and parts that need to be worked on.

Robin Heinze:

All right, let's move to another question. This one's from Andy Perlitch who is in our community Slack and submitted some questions for us. His question is, what's the general calculus you all use when deciding between React Navigation and Expo Router? Very good question. Both libraries maintained by Expo, I believe. React Navigation obviously has sort of been the standard for a long time and it's more declarative. Expo Router is more of a newcomer, but it has gotten, it's what, V4 now? It's gotten pretty mature.

Mazen Chami:

V7, I believe. Is it? Yeah, I think it's V7, but V7 was when they normalized their SDK versioning. So V7 is V56.

Robin Heinze:

Okay. So anyway, it was thought of as a newcomer for a long time. It's not really new anymore. It's gotten pretty mature, but it is newer and it's a more sort of modern web style approach to navigation. Expo Router gets you a lot of advantages out of the box like deep linking. It's file-based routing. It feels much more web-like. So if your app is cross-platform, meaning you have a web version and a native version, and it's especially important to you to have a seamless experience between the two, like users going back and forth between the app and the web, Expo Router is a great choice. It's honestly one of the things it was built for with that scenario in mind. What I will say is that in our experience, if your navigation needs and scenarios in your app are complicated, there's a lot of maybe programmatic routing, routing that happens because of programmatic things that happen in your app and that happens a lot.

If maybe you have a lot of complicated modals or just a lot going on and the file-based more URL-based routing isn't as important to you, I would probably stick with React Navigation. It just has more fine-grained, deep control over behaviors and it's much easier to do things programmatically and declaratively basically. So yeah, in our experience, the really, really complicated apps, we have a better time with React Navigation classic, but Expo Router is amazing for more straightforward cases, if that makes sense. Has that been your experience too, Maz?

Mazen Chami:

Yeah, I agree with you. That is what I've come across in the different apps that we've worked on. I do tend to lean more for Expo Router now, mainly because it almost comes by default when you use the Expo template. Both packages are built on top of React Native Screens, so they're all doing the same thing underneath the hood. It's just the APIs just look differently based on which one you're using. So use which one you're able to massage better with your application flow.

Robin Heinze:

Okay. Yep. So yeah, there's not a silver bullet for this, but generally that's our rubric. All right, Andy actually submitted several questions to us, and so we have another one that we want to feature, which is I'm sure Infinite Red has used many flavors and solutions for component libraries in React Native apps. I initially tried with Tamagui, but I found it confusing and difficult to understand. Most recently I've switched to React Native Reusables because it closely resembles shadcn, which I currently reach for in web projects. Now there's Expo UI. What are your recommendations? How do you decide on a component library?

Mazen Chami:

Great question, Andy. I'm kind of going to give a, it depends type answer, but my first recommendation is always build your own component library. Don't reach for one because I end up always without fail always having to change so much within the component library that I use where it's just easier to stand up and build my own based off of the Figma designs. And that's what I do and we do at Infinite with most, if not all of our clients. Now I will say Expo UI though does a very good job with their components. So what I would recommend is build your own component library, leveraging stuff like Unistyles for your styling and your theming and all that and reach for Expo UI where needed. Reach for Gorhom Bottom Sheet as needed sort of thing. Create your own component library with all these third-party packages that fits your application and style.

I wouldn't say there's one that nails them all.

Robin Heinze:

I would agree. I would agree. And I mean the React Native Reusables/shadcn approach probably the most easy to use in terms of component libraries because the whole component comes into your app and you can customize it at will. You're not forking a library in order to customize something. So if you really don't want to build from scratch, I think the React Native Reusables is a good way to go. But like Mazen said, every project I've ever done for a client, we build our own components. The requirements for every app are so unique and specific. It's like fitting a square peg into a round hole sometimes and it's just easier to build your own, especially now honestly with agents being able to tell an agent, okay, I need my text component to do this, this, this, this, and this. It's much easier to roll your own.

So that'll always be my recommendation, honestly. And like Mazen said, building your own but with Unistyles as base, which is basically it functions like StyleSheet, but it has more performance for various reasons. Yeah, it's a good question. I think we may be planning to do a whole episode about the state of React Native styling libraries in 2026 in the potentially nearish future. So keep an eye out for that. All right, moving to some questions from Reddit.

Reddit, it's either a scary place or a wonderful place depending on how you use it. But we went to the React Native sub and we asked for questions. So this one's from DisastrousNorth279.

Mazen Chami:

Sounds like right.

Robin Heinze:

Their question is, "This is great. I've always wondered how the consulting side goes for Infinite Red. When you get into an existing code base, React Native or otherwise, what's the first thing you look at?" What's the first thing you look at?

Mazen Chami:

Package.json file.

Robin Heinze:

That's a good one. Yeah.

Mazen Chami:

Yeah. If it's Expo -

Robin Heinze:

What's the stack? I mean, if it's a React Native project.

Mazen Chami:

Correct.

Robin Heinze:

Yeah. If it's a native project, there's no package.json obviously, but there would be an equivalent. Yeah, what's the stack? What are we working with?

Mazen Chami:

Yeah, mainly stack because for me, stack does one of two things, just shows the style and the decisions that you've made. And then after that, we're talking about looking at the code base, right?

Robin Heinze:

Right.

Mazen Chami:

After looking at the code base, I would obviously try and do some sort of just use the app, not necessarily performance test, but just use the app. What's the user experience? What are we trying to convey to the user? But if I'm talking code base, it's one, package.json. And then quite frankly, two is more of around the utilities and data layer.

Robin Heinze:

Yeah. I was going to say - What does

Mazen Chami:

Your API look

Robin Heinze:

Like? What is your data structure? What models do you have? What data types do you have? Yes.

Mazen Chami:

Are you using Protobuf? And if you are, what are those types? Because Protobuf strictly typing is very helpful when you have any API contracts there. So it's more of that. You'd almost be like, "Well, your front-end engineers, why aren't you looking at my component library?" That's all icing on the cake. At the end of the day, what is an app? It's a JSON response prettified.

Robin Heinze:

Package

Mazen Chami:

JSON and then the data layer,

Robin Heinze:

Utility

Mazen Chami:

Layer.

Robin Heinze:

Right. And then probably after that, I would look at navigation, try and figure out how the general structure of how the screens are laid out and where users are flowing. Question.

Mazen Chami:

That's a good one.

Robin Heinze:

All right. We're almost to the end of our time. So I have two more questions and they're very much related, so I'm going to ask them at the same time. So Franks2000inch... Again, welcome to Reddit. Franks2000inchTV on Reddit asks, "How do you guys see React Native in our AI crazy world? Are there still benefits to cross-platform frameworks if agents are writing all the code?" And then from Darren Wilson in our Slack community, do we still need React Native when AI is getting really good at writing Swift and Kotlin?

Mazen Chami:

This is very straightforward and I think we've kind of talked about it. The answer is

Robin Heinze:

Yes.

Mazen Chami:

So I'm talking for us, Infinite Red, React Native Radio, yes, because you still need to be able to read the code, understand the code. Unless our app is built for robots, then you probably don't need the human eye to look at it. The robots are building it. They can figure out how to use it on their own. There's a part that I do not want us to lose touch with as developers is what makes our app special is that human interaction, that human experience. Because I could tell AI to build an app all day, every day, test the app, do everything based off of prompts. But at the end of the day, if I don't put the app in my hands or even my user's hands, my tester's hands, and they give me the feedback, you're going to get bad reviews on the App Store, simply put.

Because most people only put reviews in when it's a negative thing, never when it's a good thing I feel like. So we're always going to need us as developers to be able to read the code, understand the code, make sure that the AI is doing and making the right decisions for us to keep our app top-notch.

Robin Heinze:

So what you're saying is the reason for continuing to use React Native instead of just having our agents write an iOS app and an Android app is because if you really want your app to turn out well and be robust and good quality perform at all these things, you still want humans to be reviewing extensively. And that by continuing to build React Native and cross-platform app, you're making it much easier for a human to stay in touch with it. Or you would still need a team of Android engineers and iOS engineers to thoroughly review the two apps that you're outputting. AI, you're never going to get a good outcome if you're just telling AI to spit out, "Hey, give me an iOS and an Android app from these specs." It's just not going to go well. And React Native still gives you the ability to translate specs into one app, which happens to result in two platform apps.

Mazen Chami:

There's the other side of the coin. It's like, okay, Mazen, go ahead and learn, become an expert in Swift and Kotlin, and then you don't need React Native. No, because AI is going to help increase that velocity still. So continuing to increase the velocity or like you said, one code base, one app that you're building. So continue pushing that forward. And to be quite frank with you, I don't hear of... We talked about the community and people that are using React Native. There's so many big apps out there using React Native and hopefully bringing back the Real Life React Native series can highlight all these apps for us. But I don't hear of all these companies being like, "Oh, AI is here. Let's shift to native because it can write native just as good as React Native." No, they're continuing to build their app, they're continuing to increase their velocity and they're still leveraging React Native.

So I don't think React Native is going to go anywhere. How it looks like when we're building React Native is just going to look

Robin Heinze:

Different. Right. And like you said in answers to earlier questions, React Native is amazing in its own right and it has benefits beyond just like, oh, it makes humans faster at building two apps. React Native has advantages over the year updates, you can't do that native. The entire JavaScript ecosystem and community, that's a huge benefit. Yeah, React Native is strong in its own right and it's not going anywhere.

Mazen Chami:

And quite frankly, the idea of writing one code base and having it published everywhere, iOS, Android, web, have you, is still a big sell in my opinion. There's a lot of benefit to that. Most people aren't using... I'd love to hear the statistics around web. Are users still interacting and using web as much or do people just end up downloading the app?

Robin Heinze:

I don't know. I can only speak for me. I use web all the time because I don't like downloading apps.

Mazen Chami:

Well, exactly.

Robin Heinze:

There's that side to it. You download an app, it has access to everything on your device basically. And so I'm like, I would rather just use Instagram in my browser because it feels less invasive. So I don't know if there's people like me, but

Mazen Chami:

Yeah. Yeah, no

Robin Heinze:

I

Mazen Chami:

Mean -

Robin Heinze:

Web's definitely not going anywhere.

Mazen Chami:

Exactly. Well, and at the end of the day, you want that seamless transition between both. You still want to have transition between both. The developer experience would be easier when it's all under one code base. So there's a lot of benefits.

Robin Heinze:

Tons of reasons to still use React Native, even if agents are writing your code.

Mazen Chami:

Make sure the human is reviewing the code, please.

Robin Heinze:

All right. We are so, so past time. Thank you all for sticking with us. This was really fun. Thank you for submitting your questions. Everyone who submitted questions, we really, really appreciate you. And we hope you enjoyed listening to us answer everything you threw at. I'll wrap it up for now and we will see you next time.

Mazen Chami:

Bye

Robin Heinze:

Everyone.

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.