Did AI kill React Native? Transcript, AI Summary & Key Points

This video is going to be quite a throwback. I almost feel like I should bust out the blonde hair and the mustache again for it because we're really going back here because we're talking about React Native. This is going to be a fun one because a lot has changed since we really went in depth on React Native stuff in the past. And as I'm sure many of y'all know, I am quite a defender.

One of my first big like impactful so to speak videos was when I covered the old Airbnb article about why they moved off of React Native and showcased how some of the arguments just didn't really hold up especially five plus years later. They ended up updating the article saying as much and I think they even linked my video at the top which was just unbelievable because this specific article had held me back so much when I was trying to get React Native adopted places it made sense.

Specifically, when I was at Twitch, I had such a hell of a time trying to get React Native to be taken seriously on a platform where it would actually benefit us. And that article from Airbnb made it nearly impossible. There was one thing that helped a lot though. Shopify. They made the move to React Native and showed some crazy wins. Not only was it performing better than you would have expected being React Native, it was actually often outperforming the native versions in particular with the Android app for their

point of sale systems, which was so so cool. It ended up being a huge moment for React Native and Shopify's investment in the platform has helped a ton with the growth and success of React Native, which is why this sucks. For those who are listening instead of watching, Shopify has just announced their plans to move off of React Native and go back to native code.

They put out an article, a bunch of additional comms, and let's be real, everyone's exploded since. And I have a lot of my own thoughts here, too, because I've been building more React Native than ever recently. And more so, I've been building native, too. I have more thoughts than I think I ever have about the role of React Native in the future, as well as the future of React Native itself due to some changes going on at Meta right now.

It's going to be a lot of layers for this one, and I can't wait to unravel all of them with you. But since my Shopify store isn't doing particularly well, we're going to have to make some money with a quick sponsor break. Remember back when coding with AI was just trying to stuff all of the code into the context window of your agents and hoping they could figure out what to change.

We've made a ton of progress since then. Turns out when you give agents things like the browser in the terminal, they can get a lot more done and be much more effective. Which leads me to an interesting question. Why are our code review bots still using things the way we used to? Why are they still trying to stuff all of the code into their context window and just check the grammar to make sure it's syntactically correct?

Wouldn't it be way better if our code review agents could actually run the code and test it in a real sandbox? Turns out it is. And Gretile just introduced T-Rex to prove it. There's a lot of bugs that can only be caught when you run the code, not just when you look at the code. And that's what T-Rex is here to solve for you. I realized this was obviously better when I started asking my agents to test code locally on my machine and saw them finding things that other code review bots couldn't.

But it was still just my one machine that was testing things and I was using my agents that I probably also used to write the code. So all the benefits of a cloud-based reviewer just weren't there. T-Rex goes so much further than just running the code on a random server. Though the core reptile agent still does what it always did before, looking at the code and making decisions, but now it can spin up separate sub aents in separate sandboxes to test different theories, get images and videos of what change, what works,

what doesn't, and give you all the context you need to fix the code before it hits users. If you're tired of your code review agents passing broken code or hallucinating things that don't work and you'd prefer them to actually be able to click buttons in your app and make sure it works as it's expected to, get that today at sid.link/graptile. Let's dive in where it matters.

We need to talk about why Shopify is making this move. We'll start with what they said, then I will go into some conspiracy theories about where the market is moving, what I've been doing, and then try to wrap it all into a nice package of how software dev is changing. I've done such a good job not mentioning AI yet and I will do my best to not until I have to, but it is important here.

So, we'll get there. Native is now the future of mobile at Shopify. Coding agents change what it costs to build mobile apps twice. Here's why Shopify is moving from React Native back to Swift and Cotlin. It is my understanding that they were not too heavily on Swift when they made the React Native move initially that it was still Objective C era, but I could be wrong there.

We decided to go allin on React Native back in 2020 and that bet has been extremely successful. We saved a ton of time building features just once. We enabled developers with no mobile background to contribute to our apps and we freed ourselves from constantly chasing feature par. They are missing some additional really big wins here. The I would argue the biggest by far is OTAA updating.

We'll talk about what that is and why it matters in a little bit, but we will get there. Thank you, Jamon, who for those who aren't familiar is here from Infinite Red, one of the legendary OG React Native people, called it the same thing I did as I was saying it. In January of 2025, the author of this article, who is Mustafa Ali at our who of course works at Shopify, wrote an article summarizing and reflecting on the 5 years of using React Native at Shopify.

He wrote the future of React Native was bright and that Shopify planned to keep investing in it. That was true based on what we knew then. React Native was working well for us and it remains an excellent framework. But since then coding models have gotten dramatically better and for our apps and our team building the same features in Swift and Cotlin no longer carries the cost that it used to.

This is leaning way too heavily into the multiplatform aspect of React Native. And I don't think that is the biggest strength of React Native. I've never thought that was the biggest strength of React Native. We'll talk about that planning in a bit. But back to the reading. We don't hold on to a decision just because it was successful at the time. When a core assumption changes, we're willing to go back and ask whether it's still the right call.

LMS changed one of the core assumptions behind our 2020 decision. So, we've re-evaluated our mobile stack from first principles. What we found led us back to native. So, why are they switching back to native? They decided to switch to React Native in 2020 because they wanted to stop building the same feature twice. They wanted devs to work across the stack and they wanted to spend less time chasing feature par and more time shipping value.

Sure, there are other layers to it that this does not cover properly in my opinion, but fine. React Native consistently delivered these benefits. We found ourselves spending a significant amount of time and resources on optimizing performance, improving key foundational areas in React Native, and keeping up with framework updates and external dependencies.

But these were acceptable trade-offs. The benefits of using React Native far outweighed the investments that we had made in these areas. Shopify has been using LMS to build software since 2021, a year before even chat GPT. Initially, they used them to implement features, investigate and fix bugs, and review code. As models improved, so did the complexity of the work that they trusted them to take on.

By late 2025, they were no longer just helping write code faster. They were capable of making them question whether building software twice still meant doing twice the work. Jamon just pointed out that he finds it funny. He agrees with so much of the article, but switching to native from React Native is a nuance topic and also does not think that Shopify ever fully adopted Expo.

If you have React Native apps and you're not using Expo, you end up spending your time rebuilding Expo. Yep. Yep. So, this is why Shopify decided to experiment. They decided to reevaluate their mobile tech stack and prototype whether their technology choice still held up. They rebuilt several core parts of their biggest apps in Swift and Cotlin using LMS and they were surprised at how well it worked.

agents could implement features on Android using the iOS version as a reference and vice versa. They help devs ramp up and contribute effectively outside their primary stack. They dramatically reduce the cost of maintaining parody between platforms through shared specs, tests, and review checkpoints. Oh god, I'm going to have so many things to say once I'm through this.

Native still means building and maintaining software on two platforms, and that cost has not disappeared. What's changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer a deciding factor like it was in 2020. React native apps can be fast and the ones at Shopify are. They're making the change because agents have reduced the advantages of sharing implementation while the advantages of building from each for each platform specifically do remain.

Native keeps them closer to platform capabilities and first party tooling with fewer frameworks and dependency layers between their code in the platform kind of. So what's the future of all their open source libraries for React Native? Because as I mentioned they've been really big contributors to the React Native ecosystem for a while now. They call they want to make the transition cleanly from the beginning.

They wanted to contribute back to React Native to make it better. They have a handful of open source libraries that have become the top choice in their respective categories. They're grateful for the incredible reception and they're committed to making sure the transition is smooth with no surprises. They start with React Native Skia which allows you to use the Skia engine which is from Flutter.

Funny if Flutter is moving off it, but it's the animation engine that lets you do cool graphic stuff without using just native elements and layers. So you can have fancy animations and crazy buttons that do things that you would normally do in like a game engine. I know Ski is actually technically from Android and Chrome, but in this case it is largely associated with Flutter.

Whatever. We don't need to go that deep in the weeds, guys. Come on. Let me make this easy for the people who aren't as familiar. They built React Native Skia so you can get those benefits in React Native for the specific screens and experiences that benefit from it. things like if you're building the Instagram stories like where you can layer things on top of a photo.

Skiia is way better for that than doing it with React Native or even natively. So this library was really cool for those types of cases. That's why Shopify made it and that's why they are going to continue allowing William who is an employee there if I recall to keep working on it. They'll fork it in the coming months and start publishing the library under a new name.

The original repo will be archived when the transition is complete. They'll post updates along the way so that everyone has ample time to migrate it. If you're approval in the library, consider sponsoring it. William, if you guys aren't familiar, is an awesome React Native YouTuber. One of my favorites. So, that is cool to have like a YouTube community person taking over for this.

Also, building this in his tech is super cool. Like, he's great. It's in good hands, but definitely sponsor it. Okay, he is at Shopify. Cool. I'm not misremembering. Thank you, chat. Next, we have Flash List. This one, I would argue, is still really, really important. It has become the default list for most projects in React Native. I will say that legend list has worked out better for us and has less native implications.

Another thing we'll be talking about in a bit. Given how important this library is for the ecosystem, Shopify will continue to fix critical issues that break compatibility. They're in discussion with several companies about taking on long-term stewardship for flash. Then there's restyle. It's smaller than their other libraries in terms of its usage.

So they're archiving the repo. So how about their migration? What are they doing here? They have several large apps. They've been debating between gradually moving to native or rebuilding from scratch immediately. In the past when they migrated to React Native, they picked the brownfield approach for some of their biggest apps as it'd take years to rewrite them and they'd have to stop shipping new features when the rewrite was in progress.

But LLMs and the clean state benefits and their prototype showing promise here with agents means they could probably do green field and that's what they concluded. They're doing green field clearly emerged the real winner. Makes a lot of sense. This is actually really cool to see because I've been waiting for more companies that are like big wellestablished like Fortune 500 businesses to come out and say outright like, "Hey guys, LM are good enough.

We can use these things to do big [ __ ] We can actually rewrite our stuff." Because there are so many big companies that have kid themselves into thinking like, "Oh yeah, those LM are cool for like quick feature ads or Jira tickets, but they're never going to be able to work on a codebase our size." You think your codebase is harder to work in just cuz it's huge?

Come on. Watch my video about understanding large code bases. Ideally, you don't have to understand it at all to contribute because that's how a good codebase should work. Anyways, the shop app, which is regularly at the top of the list in the shopping category in the app store. Nice humble brag there. It's the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt built app published in the app store in just 12 weeks.

They've written about the migration in depth already. Migration of the Shopify app, which has 300 screens, home and lock screen widgets, Apple Watch app, complication, Siri Shortcuts, etc. is also underway and will ship later this year. So, how do they prevent slop? It's tempting to just point an LLM to the React Native codebase, and try to oneshot the same feature in native, but it doesn't work.

Even if you ask it to gather as much info as it can up front, freeze it into a spec, task files, and then implement it, you'll end up with a huge amount of unmaintainable code that can't be shipped. To solve the problem, they built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct. Instead, it builds a loop where an imperfect attempt can simply cannot move forward until it becomes a good result.

They point Helix at a screen. Helix reads React Native code and proposes a sequence of checkpoints that can be reviewed in minutes. Then they checkpoint by checkpoint go through and build it. Each one must prove its behavior with tests that match the running app in a visual review, survive two adversarial code reviews, and get a human's nod before it's committed and the next one starts.

I don't love this approach. This screams to me, we think our current implementation is more novel than it actually is. People worship their existing codebases a little too hard and this feels like OG codebase warship. like this is the only way they could get the existing devs to be okay with it by making them feel like their code mattered more than it does.

The section here about enabling fast feedback loops because agent control of simulators has been a bottleneck for them. They found themselves constantly babysitting them as they couldn't reliably build, test, and iterate. They built their own tooling to allow agents to reproduce bugs, fix them, and verify them uh the fixes autonomously, but it was slow and brittle.

React Native's hot module reloading helped the situation, but it didn't solve it due to the situ due to the simulator controls being slow. Primarily due to the reliance on the accessibility tree or screenshots to get the state of the app, take actions, verify results, yada yada yada. Simulators are extremely slow and manual to work with with agents.

It doesn't matter how good the model is if it can't test its work quickly, which is especially difficult for mobile. Yep, mobile is killing mobile so aggressively. Like these things have always sucked and they're always why I've hated mobile. But now they hurt a h 100red times more because the agents are struggling to work through it. They are designing their own app architecture in order to make this work better for humans and agents.

The core principles, the business logic should be completely decoupled from the UI and be able to run headlessly on desktop. They then make it available to agents via a CLI that allows them to iterate on it in milliseconds instead of minutes without involving simulators. My [ __ ] god, they'll overengineer anything. These are CRUD apps. The thing they are talking about making headless so they can test it and let the agents do it is the API and data layer.

I'm sure that makes Gemini 25 Pro more effective. Yeah, to Jamon's comment earlier about Expo, they clearly did not adopt Expo. It solves most of this. The CLI allows agents to inspect the state of the app, navigate between sections, and perform actions, all without needing to touch the UI. I'm going insane. When simulator interactions needed, the CLI can connect to them via remote mode, and drive the UI via commands without having to inspect the layout or the accessibility tree.

Oh man, this is criminally overengineered. They have a section doing thanks at the end here. They start with meta for their work and with the react native team for being such excellent stewards of the framework, listening to feedback and working closely with them over the years. React Native is React Native is substantially better today because of your investments in the architecture performance tooling and community.

This will be one of the most important parts of this video when we get there. William the YouTuber who created React Native Skia and has been maintaining it and works at Shopify and will continue maintaining it. Software mansion who is a firm that helps with React Native integrations for various companies. They also helped build reanimated which or they also built reanimated which was a core library for doing animations in react native that is very very popular and of course Shopify engineers and the react native

community. Cool. Where do I start? Oh man, here are the core things I want to make sure we get through now. There's a lot of layers to them, but we'll start with the real benefits of React Native that I feel like were missed. Then we'll go to the weirdness of Shopify and how that is a meaningful thing to care about here. Then we'll go to what moving off of React Native actually looks like as someone who has been doing it and the state of the React Native team.

What is actually happening to React Native itself. Let's go through the things I don't feel like got the proper care that I think they should have when talking about React Native here. I would argue there are three letters that make it really hard to not use React Native. if you can justify it. Those letters are OTAA stands for overthe-air update. This is a hairy topic for various reasons, mostly because our friends over at Apple and Google with the management of the App Store and Google Play Store don't want you to be

able to do updates without doing them through the official App Store. So, let me walk you through a few realworld things that can happen here. Let's say you're a dev on a small team, maybe two or three people, and you're working on an app update that adds a new button to a menu. You all test it on your phones. It all looks good. You put it up in early access through test flight.

Everybody's fine with it. You ship it and then you get a message from one of your most important customers that that customer is actually one of the few in the proud iPhone mini users and the change you made doesn't show up on their screen because it gets cut off by their tiny viewport. If you had built this in native code, your options are revert so the change doesn't go out or gets cancelled and now you have a bunch of users who are on the newer broken version that would have to uninstall and reinstall the app.

You can leave the broken one out there as is and eat the support cost of people downloading it and having the thing not work on their phone. Or you can make a new update that fixes it and now you have to wait for Apple to approve it and get it out there. And when I saw the real world numbers at Twitch, at any given time, half or more of the users were on a version of the app that was at least two versions old or older because people don't update their phone apps all the time.

I'm pretty good about this. I'll manually go and trigger updates. Let's see how many apps I have available to update right now on my phone. And I don't even have that many apps installed. Let's see. Scrolling down to check. It says none right now, but now that I scrolled, 54. My phone showed me there are no app updates available. And then I did the little pull down thing.

There's actually 54 app updates available. That means I have 54 apps on my phone that are out of date. That is insane. And that makes it so much harder to build apps. Both because you have to worry about forwards and backwards compatibility always. And so do your servers and so does your support team. Everyone has to care about all these different versions.

And if you do accidentally ship a bug and you fix it an hour later, you'll be getting reports about that bug for months, if not years, because it takes so long for people to get updates on their devices. Apple doesn't push out the update as soon as they approve it. They slowly roll it out, sometimes over weeks. What this means is you don't really have one app on iOS and Android.

You have all the versions anyone has installed that you don't have some system built in to deprecate. And if you ever had the problem where you open an app and it has a big warning pop up saying, "Hey, you need to go to the app store and install the latest version, you should feel bad for those devs that they have to do that because there's no other option."

Well, there wasn't if they weren't using React Native because the abstraction React Native represents is so good for this type of thing because React Native isn't web. It's not some alternative to native. React Native is a command layer to control what native elements are rendered. Imagine there's an incredibly skilled chef in a kitchen. You tell him what to cook and he can cook it really fast.

Imagine that every hour or two the recipes change a bit and the chef now has to go memorize all the new recipes or learn all of them up front before they even get in the kitchen. Or crazy idea, you have two chefs, two expert chefs. One is doing all the cooking and the other does all the researching, all the planning, and tells the other chef how to cook the thing when the order comes in.

Have you sold out the kitchen when you did that? No. It's still the same kitchen. It's even still the same chef. You just have another chef telling them what to do. That's kind of how React Native works. It's not an alternative to your own kitchen. It's still the same kitchen. It's still the same iPhone. Still the same native everything. It is still swift code doing the things in the platform.

You just have the JavaScript layer telling that layer where to put things and what to do. So now imagine 2 hours pass and the recipes have changed entirely. You have a whole new menu at the restaurant, but you don't want to take the chef out of the kitchen cuz he's in that kitchen. He's not going anywhere anytime soon cuz Apple won't let him out. You can swap out the chef that tells him what to do and it's like you have a whole new chef, but you just have somebody else sending different orders in and giving him good

enough instructions to do his job. That is how React Native effectively works. You have the JavaScript layer that tells the native layer what to go do. And let's be real, it's a lot less work to hand the recipe to a chef and say, "Make sure you do these things this way." than it is to go in the kitchen and do it yourself. And that's what makes React Native so magical is the JavaScript layer is doing the easy boring part, but that easy boring part is what you're actually [ __ ] cooking.

And that's why it's so cool. The actual layer that makes the app function, the native components don't have to change. You don't have to sh You don't have to swap the chef every time a new recipe comes in. You just need to give them the new recipe. And that's what React Native is. It is a recipe distribution system. It is a way to give different recipes to that native layer to make it look and behave differently.

And over the air means you can swap out that external kitchen, that external source of recipes without having to change anything in the kitchen. And that lets you do lots of cool things. And to be very clear here, both Apple and Google really don't want you using this to ship new features because they want all features to go through their review process.

But it's pretty well established at this point. If you have a bug or an issue or a thing you want to turn on and off, like I don't know, maybe you have a fancy background on a specific holiday on your homepage and you want to have that in the app for a day and then out the next. In order to do that natively, you would have had to plan way ahead to include it.

You would have had to plan possibly months ahead and hope all your users are on the latest version by the time that date hits and then have it hardcoded to turn on at the start of the day and off at the end. And if anything goes wrong with this, you're screwed. you didn't have the code in in time. With React Native, you can push up the OTAA for it at the start of the day and you can push up the OTAA to get rid of it at the end.

And if something goes wrong during, you can push up a new OTAA with that. And since the JavaScript bundle can be redownloaded and that JavaScript bundle tells Native how to behave differently, you can get around the whole long painful review cycle with small fixes, changes, and things that don't really need that review cycle. And now that there are so many more apps shipping, so many more updates, I like to think Apple's a little thankful here because they don't have to review changes and new app builds, if nothing

meaningful changed. And also to be very clear here, one of the things that makes this viable, which is also one of the things I think Shopify did wrong, is Expo. Expo is kind of the Nex.js/verell of the React Native world. They have built a lot of the tooling that is necessary to make React Native a good experience to work with. And they handle all the builds on their servers if you would like.

They handle the OTAA and pushing out those updates if you like. They handle a ton of different things. And they also make it easy to get a good dev client, which I think is one of the biggest benefits of React Native now that I am in the utter hell that is building a native app. Fun fact, if I was to clone my repo for T3 Code, specifically the branch I have with a native fork, which we'll talk about plenty, don't worry, and I was to plug it in to my phone with my Apple account and say build, it would fail because

there's a bunch of weird permissions I have to get through a bunch of weird signing [ __ ] just to have the ability to have a share screen. It's obnoxious. I now maintain two different configs for the native build so that I can do an easy dev build without having to go through Apple's crazy process per machine just to test out small UI changes that don't need all those deep features.

But my dev build on my phone is currently missing three or four features because Apple needs to give you a special check box that you hit and go through their whole process before you're even allowed to install the app that you own on the computer you own onto the phone you own. It's insane. But with React Native and Expo, you only need one dev to go through that process, and they can make a dev version of the app.

And once you have that, you scan a QR code, you change out the React Native code, and now you're working on the app. Can you make changes to the share screen code? No. But I never [ __ ] do anyways. But if I want to test how my new feature works with the share feature, I can't unless I go deal with all the signing [ __ ] It's obnoxious. And Expo solves the dev loop massively here.

They make it way easier to do the updates for users, too. It's just it's better. It's just so much better than any other mobile dev experience. And it still has its rough edges. I'm not going to sit here and pretend it doesn't. But mobile's just is so annoying. It's so pathetic. I have like an hour plus long crash at Apple and Google's not better. The reason the other reason I bring up Expo isn't just cuz it makes React Native go from eh that's kind of cool to holy [ __ ] why would I build any other way?

The other reason I bring it up is because Shopify wasn't using it heavily. They were not getting a lot of the benefits of Expo. And as Jamon pointed out earlier, if you're using React Native without Expo, you're probably rebuilding Expo because you need all of this tooling anyways, Expo is very helpful. Also, on the note of Expo, they have really good simulator support as well as web support, which means you can let your agents do a lot of the iteration without ever needing the native build in the first place.

So, if you think a CLI is a good way to approximate how your app works, wait till you have the whole app compiled for web, cuz I have a feeling that'll be a slightly better way to test your logic. just guessing there. There are negatives though and I want to make sure we talk about them. So, what are these negatives? The first one, and I'll just be real here, library bloat.

And I want to be clear about a few things there. The pain point with the libraries in React Native have in my opinion very little to do with JavaScript and React Native and much more to do with the utter shitow that is trying to manage packaging inside of Xcode whether it's Objective C and Coco Pods or Swift and Cocoa Pods. It's just not pleasant. And the way that they all have to be built and linked and break in ways that make no sense is [ __ ] obnoxious.

I am very frustrated with it. Usually when people talk about this, I see another very quick follow-up, which is the app size. People love to say, "Oh, React Native is so bloated. Your app's going to be huge and slow." Yeah, it's so much worse. Let's look at the move that the Shopify team did to shop for their mobile apps. They moved again from native or from React Native to native, and they saw some improvements we'll talk about later.

Let's look at the app size. They shaved a whopping 1 megabyte by moving to native. Wait, what? It's bigger? Yeah. Turns out the React Native runtime is not particularly large. A default Expo React Native app is in the like 20 to 30 meg range. I find that most bloated apps are more so bloated with things like a bunch of localization and translations as well as with just disgusting amounts of assets and media.

Like it only takes a few PGs to quadruple your app size. And I see this a lot. So yeah, app size is not what we're talking about here. As you can see, any differences here have less to do with React Native and much much more to do with second system benefits where like they're building the new thing. So the new thing has a lot of learnings. But yeah, this is not a real argument.

Size does not have a meaningful thing in React Native versus native. You're not going to have an app that's way bigger because it's React Native. And if you do see a huge difference going from React Native to native, that's because you rewrote, not because React Native is so [ __ ] The other real big negative, and I'll be real with y'all here, foot guns.

React Native is not light on them. The things that make n the things that made React and web tough for less capable teams are even worse on mobile because one bad use effect can just destroy the experience you have on mobile. And I see a lot of these cases in React Native because I'll be frank, a lot of React Native devs aren't picking React Native because they know it's the right technology and they made a really thoughtful decision.

A lot of them are picking React Native because they found native too hard and they heard React Native is easier, so they go and do that. And the fact that React Native is accessible to newer devs, super cool, awesome. We love that. But it means that foot guns become much more visible. And this is going to be one of the most horrible things I say in this video.

I'll just write it down because I want you guys to know I mean it. The average React Native dev is worse than the average native dev. This is a fact. I will not be arguing. And this isn't because of one being better or worse than the other. This is because I I guess it's because native dev is harder and React Native is easier. Which means React Native becomes the default for the bad devs.

or I've argued in the past and I'll probably continue to that most bad devs picking a technology does not mean the technology is bad. It's the default case when you win. When a piece of tech is so good, everyone defaults to it. You're going to get way more bad devs, but that doesn't mean the thing is bad. I've talked about this a lot in terms of React on Web.

I don't care to do it more here, but you get the idea. The average React Native dev is worse than the average native dev, which means these foot guns hurt a lot. The other thing that I've noticed can be tough in React Native, and this one does seem to have hurt Shopify, is the chaotic nature of the moving target that React Native represents. In particular, they've done some huge rearchitectures that have fundamentally changed how React Native works underneath that make a lot of your native code you may have written

harder to interface with or at least different to interface with. This also sucks for things like version upgrades. And I'm at the point now where when I have to do a big version bump on React Native or Expo, I delete the package JSON. I delete the package lock and I reinstall and then hope for the best. And when things don't work, I usually delete and rewrite cuz that tends to be much faster.

Like I I've never successfully bumped the version for Expo and React Native, and had it just work. And that's crazy because almost every time I do that for other things, especially in web, it does absolutely just work. And the last big one I'll put in here is the dependency on meta. To be clear here, I'm not saying meta, evil, bad, terrible, and you can't trust them at all anymore, and that's why you shouldn't use React Native.

I'm more saying that when Apple puts out a new feature, it'd be nice if you could just use it immediately and not have to like build it in yourself into some crappy React Native shim or wait for Meta to decide to support it. It' be nice if you could just use it. And when you're native, you can just use it. Yeah, you might have to wait a month for the app to ship out, but you can just use the new thing.

These are the biggest issues I perceive right now. Notice what isn't in this list though. Notice that I didn't put performance in here. Notice I didn't put things like fluidity here or data loading or all that. There are some cases there that are worth talking about. Like it is harder to get good background data updates in a React Native app because when you leave the app and it sleeps on iOS, that JavaScript layer is dead dead.

So you're going to have to write some native code to maintain things like connections to process data when they come in. And even those will probably die even in the Swift layer. So yeah, your ability to do those things is slightly lower if you never leave the JavaScript, but when you're writing React Native, you can still just write native because it is native.

I feel like people miss the word native in React Native a lot. So yeah, just wanted to call that out. So those are some real world positives and negatives that I feel like didn't get covered properly that will help ground us for the next section, which is the weirdness of Shopify. First thing I want to talk about here is in their article about their migration for the shop app.

Their exploration of native coincided with the next major React Native investment, which was the new architecture. If you're not familiar, React Native did a huge overhaul of their core architecture so that things would be way faster when bridging between the native code and the JavaScript layer. And it was way faster for a ton of realworld work. This ended up being introduced as a new experimental opt-in with React Native 0.6.

68. I think it's the default now. It might not be yet, but it is really, really good and is a huge improvement. Not only does it make it easier to get things in and out of the native layer. There's also a bunch of improvements to like core functionality in React Native itself for layout stuff like synchronizing layouts and effects using the new architecture.

Doesn't you no longer have to like call on layout manually. Instead, when you use callbacks or set targets, it will update much faster because the refs are now effectively native when before they had to go through a bunch of layers. There's a lot of these little things and chat just confirmed it is indeed the default now which is huge. Thank you guys.

Very nice. This new architecture is a massive improvement to how much performance you can squeeze out of React Native. And it's also powering all of the production apps at Meta. As far as I know, it's good stuff. And the team at Shopify was trying to decide, do they take all their native work they've done already for normal React Native from before the new architecture and port it to adopt this new architecture, or should they just go rewrite it natively?

This means that the comparisons they have here for things like startup times aren't as useful as I think they would be if they had the new architecture because from what I've seen, new architecture does massively improve a lot of the performance issues. So that was weird part one. Weird part two is the nature of Expo and its involvement here. Fact they weren't using Expo means they're losing a lot of the benefit of the React Native ecosystem does make the move away hurt less because they had invested more in cloning

that than most companies have in their app in the first place. To be very clear with the amount of native stuff they have written, the port to the new architecture would not have been trivial for them. But with agents, it wouldn't have been too too bad either. And it would have been nice to see React Native old architecture versus new architecture versus native because I bet the gap would be even smaller.

Also worth noting that the T3 code mobile app in React Native and in Swift loads way faster than the shop app does. Just saying. Those were the technical things I wanted to dive into with the Shopify case. One last piece that I think is important to dive into with the nature of Shopify is not super technical. It's more personal. It's about Toby, the founder and CEO of Shopify.

If you've ever worked at Shopify, you know decisions like this are made directly by Toby abruptly over a weekend and they are forced on the entire company without any input from the people actually working on the apps. For a few weeks, Toby was convinced React is slow and there was a companywide decision to move from React to Ruby on Rails for all new projects and to migrate some existing things to Ruby on Rails.

Then two weeks later, he learned about server components and then removed all of the internal articles bashing React and cancelled the migration decision. Even have an emoji for when this happens because it happens so commonly that he drops in some Slack channel and demands things to be immediately changed without allowing any conversation with the team members.

This is a thing he has historically been known for allegedly, but he did respond. So I will read his response out of courtesy. Yes, except one. The example here was about important internal tools. The team was stuck at some architecture nightmare of their own doing. It was written in Rails but headless with GraphQL APIs and a Spa React app constantly needing front-end engineers for changes.

I mean, if the thing is changing the app, then the front end engineer should probably be involved, but sure. Although, I do love his phrasing here cuz I use this too. He refers to this as cosplaying an enterprise production app. Yeah. Oh god. So, internal tools were using GraphQL, Rails, and SPAS for like 50 users. No, that's [ __ ] stupid. I'm on his side here.

That needs to have been rethought and rewritten immediately. should have been a full stack TypeScript thing, not a full stack Rails thing. But yeah, I agree with him there. The complexity was in the way and using straight rails was perfect in that case. I will say at Twitch, I was maintaining an internal Rails app that was similar to what he's describing here and that codebase was even more of a [ __ ] show and we wanted to make it easy for the engineers who worked on the public platform and the internal platforms to

move between them more easily. So we moved to a go backend graphql layer and react front end for this internal tooling for the purpose of shifting between platforms more easily as an employee that was like multi-service at the company had bits and negatives but it also worked out as a really good place to green field new things before we brought them to the public Twitch site and I got to spend a lot of time with the people running the core Twitch project experimenting with things we weren't sure about on the internal

projects before I would bring them to the core website and it was really fun and we got to learn a lot that way. So there is a balance to be struck here. But if they were having a lot of issues using headless Rails with GraphQL and SPAS for internal tools with small numbers of users, yeah, I'm more on Toby's side for that. He says he does make calls like this all the time.

Usually someone on the team asks him to. They see what needs to happen, but they don't want to be the bad guy. He's happy to come in and make the call if he agrees with the premise. It saves enormous amounts of meetings and change management, etc. Sometimes it's jokingly referred to with as founder mode as a service here. Okay, that flipped me. I as someone who only somewhat recently discovered this path for things, who has been telling their team more like, "Hey, if there's a hard decision to make here and you're

scared to be the one to say it, just tell me what to send and I'll send it." This is that and I have respect for that. I hope this isn't him putting off blame for things he had chosen. But if this is actually the case, which I do trust him there, I'm on his team. Next, he says that for 10 years, he ran an internal podcast called context where he revisits decisions like these and explains the reasoning so everyone can learn from them.

It's helpful to give people all the variables that were considered and why it was the choice made given the information available at the time. He wants to teach how to make such decisions effectively without needing him with some cost fallacy specifically cited as a problem. Next, he says that any notion that Shopify is successful despite him doing this instead of because will have a hard time making their argument come together.

This sounds like me being a little cocky on Twitter, so I won't talk too much [ __ ] The part of the original post that said, "Two weeks later, Toby learns about a thing is nonsense." In the pivot of that project up there happens to be one of the most successful examples of interventions. Getting the company to work effectively with great architecture and low technical debt baggage is the right direction and is literally the job.

So, he is guilty as charged. There's always cope stories floating around like this because they're more fun. yada yada yada. Yeah. Okay, this one flipped me. Cool. Yep. Less [ __ ] talking on Toby after that, which means it's time for section three. What moving actually looks like. This is one that has surprised me quite a bit. I'm going to go straight into my real world experience rather than trying to dance around this one by like setting it up properly.

And I'll just say what happened when the weirdness with government bans of new models was going on and we lost Fable and Soul was being taken from the early access testers as they were ramping up for the release. We had a time where we knew we would probably lose access to Soul. And in the early access, we had a lot of tokens to burn. I still had a lot of tokens.

I did not have a lot of time. So I decided to just throw out some Hail Mary ideas. I knew React Native was the right call for T3 Code. We were already very deep in the building of the React Native version of the T3 Code mobile app. Julius had been putting so much time in, but I had all these tokens and I had soul and I was curious. So, I took my Mac Mini, I installed Xcode on it, which took way longer than it probably should have.

Xcode being Xcode. Make sure you download from the CDN directly. By the way, don't install from the app store. It will be hell. Really stupid that you have to know to not use Apple store to download Apple's dev software on Apple's computers. But yeah, that aside, decided to just throw soul at the problem. I told it to build the Swift and app kit and it did and it finished in like two hours and I was really confused.

I assumed it got stuck or something or the model was being dumb and then I opened the app and it worked and I was very confused. But I was also in the middle of porting three other things to Rust before my timer ran out. So I didn't go back and explore it very much. More time passes. I start using the React Native app for T3 Code a lot more because I'm using T3 Code a lot more.

I was starting to code again, which was great. And I start having lots of subtle issues with like very specific bespoke navigation [ __ ] And a lot of it's getting fixed, especially like the scroll view stuff. To this day, the scroll view in the React Native version is still probably the best scroll view we have for any of the services for T3 Code. But I'm bored.

Not really bored. I have tokens and things I can run in the background. And I also want to like polish up my DX for agents working on mobile apps on my computer. So I decided as a attempt to like test the efficiency and efficacy of ultra with soul cuz I didn't have ultra during my testing. That was something that came out when the new model officially dropped.

So I tried ultra with soul using the new computer use stuff with codecs on a Mac mini to again do a full port of the react native app to swift and appit. But it got confused along the way and ended up using swift UI. And swift UI sucks in a lot of ways. I'll be real. There's a lot of all the rough edges you have in React Native. There is an equivalent rough edge in Swift UI almost certainly.

And chat is catching on to an important detail. UI kit. You mean AppKit is Mac OS only. Correct. So the first time I told Soul to use AppKit, it realized I meant UI Kit and did the right thing. The second time I said AppKit, it decided I didn't mean either AppKit or UIKit and it went with Swift UI instead. So that is how I ended up with a UI kit version and a Swift UI version of the same app that we already had in React Native.

Every one of these builds took under 3 hours automated by the agent running itself in a loop with computer use. Went way better than I ever would have expected and both immediately felt better for some navigation stuff as well as some data loading stuff in particular because it could maintain the data in the background a little better because that was written in native code instead of the JavaScript engine that gets sunset as soon as the app sleeps.

So, the performance wins weren't like the whole thing feels way faster. In fact, scrolling felt way worse because lists in Swift UI are hell. It is actually hilarious how bad lists are in Swift UI to the point where it started my crash out with Arc back in the day because they use Swift UI for their native UI in Arc and the download button would crash and slow down the browser when you clicked it if you had more than a few hundred files in your download folder because it would try to index all of them.

But there were some subtle things in the Swift UI version that I did really like. In particular, the way that swiping in and out felt when you went to a thread and went back. It had a how to describe it. It was like a very subtle difference where it felt like it traced your finger a little bit better. And I learned later what the real cause was. This I I could do a whole video about swipe gestures and navigation in mobile.

I already have done parts of this in my mobile isn't web video I did forever ago. So let's say this is your mobile app and you have your home screen and then you open something and the thing you opened is the second layer and you want to swipe back. Usually the way I swipe back is I touch somewhere on this left third or fourth of the phone. I have a section here.

I'll touch and I drag to the right from the left. And this action causes you to navigate down the stack back a layer. This is how I use my phone. This is how I've used my phone for a while. I'm not an Android person who likes a back button. And I think all the Android people who still use the old school menu bar are wasting screen real estate because they're scared of change and they should get over themselves because the gestures on Android are way better than the original native UI.

So, all of that said, this is how I go back on my phone. Turns out a lot of people do the same, but they start from the middle of the phone because they don't like reaching all the way to the left edge. This drove me [ __ ] insane. I got in like a heated argument with Julius about this because everyone else on my team was like, "Yeah, we we put your thumb on the left and you slide to the right."

A lot of people start in the middle and go to the right. The reason I crashed out is because at some point in the React Native app, there was a swap drawer added and the drawer was registering a really really far section. It was like eight pixels on the left. So if you actually touched all the way on the left, it wouldn't swipe back because it was activating a drawer that no longer existed.

So Julius never once encountered the bug bed and I were every day and we were going mad. And we dug in and found it and killed it. God, that was so annoying though. And this is when I learned Julius swipes from the middle and I swipe from the left. And I will be real, I did a thing I almost never do. I concluded that Julius was wrong. And as always, I regret that because I was showing my version of the Swift UI app to people at Defcon when I was there.

And one of the people who I handed it to first was an Android user. And I intentionally didn't tell him anything. I just wanted to be sure I was right about the swipe thing. So I handed him it with a thread and said, "Go back where I was before." and I watched carefully as he touched the middle of the screen and swiped to the right and it failed because of and this is my favorite part the the twist you didn't expect.

Swift UI includes native navigation in their stack which is awesome. It means that there's an official Apple way to do navigation. The twist is that it only lets you use this left fourth for the back gesture and you cannot change the size of the gutter. If you use the native navigation stack in Swift UI, you cannot use the native gesture if you want to support touching anywhere other than that left fourth.

Which makes for the funniest part of all of this. If you're on an iPhone right now, I would like for you to open it and go to settings on your iPhone and then go literally anywhere from there. I'm going to go to the battery tab on my phone. If I swipe from the left, it works fine. But ready for this? If you swipe from the middle, it does too. They're not using the native stack on [ __ ] iOS.

the platform itself and the built-in apps aren't using the native navigation for the native stack because they want to support all of the ways to go back. So, this is one of nine infinite examples of the native platform that is provided to be the best and most reliable solution hurting your users. So, I had to rebuild the navigation layer in order to make sure the natural places that your thumb might land when you go back all work.

Because if you use iMessage in back works one way and you use settings in the back works this way and then you go use Twitter in the back works that way and then you use my app built on the latest and greatest swift UI and it doesn't work that way. You're going to blame my app and not app pull. So tell me again about how Apple's developer experience makes better feeling apps than the people who are fixing all the [ __ ] themselves.

Sorry, I've been waiting for an opportunity to crash out of this one for a while. This was a this was like a twoe journey for me. To anybody who says Vibe Coding makes everything easy, the only thing it made easy was the implementation after two weeks of crashing out. We're going to have to do another quick sponsor break so I can pay for my therapy and then we'll get to the real important detail here, which is what's about to happen to React Native itself.

PreAI, I had a lot of strong opinions that have turned out don't matter too much in the era of AI. That said, there's a few that matter more than ever. things like a database that actually works in your application, full stack type safety to make errors easy to identify and fix, sync engines to reduce different classes of bugs to make everything come together well, and ideally a type- safe system that makes it trivial to define all of the things your systems need.

This is why I built the T3 stack, but you might have noticed I don't talk about T3 stack a whole lot anymore. It's because both I and my agents prefer using Convex, today's sponsor. It's crazy how defining everything as code makes humans and agents more effective. It's so easy to change how your systems work when it's just a folder in your project named Convex full of TypeScript files that your agents already know how to use.

I could say this so confidently because they actually benchmark how well LLMs understand Convex and it turns out they use it very well. I almost get tripped up when I use Convex for projects because things just spin up immediately. I ask an agent to add this feature and it finishes in 45 seconds. I get confused. I check it works and it's all because Convex made it trivial to define.

Convex was my secret that I used to build fast before AI. Now they are empowering all the stuff I build with it. Figure out why at slative.link/convex. Okay, I did promise we'd go to what's happening to the React Native team, but I want to finish up my story about these ports. Because I have found, unlike what Shopify experienced, that if you give an agent a simulator, some source code, and a clear existing implementation of how this thing should work, it usually can get a pretty close to perfect rendition.

And if it fails and you tell it what it got wrong, it will fix it first try almost always. My honest guess here is that they were using claude models too heavily and OpenAI models not enough because I have found that Soul's ability to navigate an existing React Native codebase and port things over in spirit to the like actual native build is almost seamless.

The reason I so strongly believe that this feature porting works well is because the app I'm using every day for doing my code on my phone is a Swift UI port of the React Native app that I built 95% with Soul and like fiveish to maybe 10 now with Astra that I built in a single thread, one thread for almost the whole app. And I still have this PR open.

We're now on like PR 12,000. This is PR 5000. We've shipped so much in the past few months and I don't know if I'll ever convince Julius to merge it. as it benefits and negatives. I would honestly say there's a lot of things the React Native app is faster with than this, especially the list, which we'll get to, don't worry. But here, I want to just show you guys what my prompts look like because you probably think they're really complex to do this, right?

Here's me polishing up like the settings page and things, but the part I want you guys to see is here. Any other changes on main that are worth pulling in? make sure we keep the app up to date with any improvements that we make to the React Native app in the wire protocol for how we actually get data to the client. An hour passes updated and pushed.

Latest main is merged without rewriting history ported to Swift UI. We added batch inbox updates to reduce UI work. provider account badges on thread rows, existing branch selection for new tasks, async question dismissal, question attachments, saved attachment drafts, and answer history, hub reset credits, and usage label privacy. It did all of this itself in a loop for an hour with no goal set.

It probably had to compact multiple times throughout. Yeah, there's like two compactions at least. The Here's where it shut down the sim, but it did test things in the sim to be sure. So by the time it said it was ready. Yeah. This time I just trusted it. And that's unique because prior times I told it build it on my phone so I can test it myself and tell me what things I need to check so I'm sure it's good.

Now I just trust it and say go do the public test flight. Whatever. A thousandish people are on this public test flight. You can find the link on my Twitter if you're clever enough. And I don't even [ __ ] I've not read a line of the code for this app to be very clear. And it runs great. It's what I use for coding every day. It is a faithful port of the React Native version that is ported by taking what Julius does, looking at his commits and just rewriting them in Swift and it works great.

It's been awesome. So, I don't know what went wrong at Shopify. It might be they were using old models. It might be they were using anthropic models or [ __ ] computer use. I can kind of just tell the agent to go do the thing and it usually does the thing. I'm not going to pretend my app is as complex as shop. But if I can do this as one engineer working on it part-time for fun with a loop and a model, then a company that has dedicated engineers on this should be able to do it fine.

I'm just saying. One last thing on my native experience in the performance. I need to site Jay quick. Jay is the creator of Legend State as well as Legend List, which are two phenomenal performance focused libraries in the React ecosystem. They are largely react native focused, but they have both found their way to web recently. and Legend List was such a nice solution for all of our rendering problems on mobile that we ended up being very early adopters of the web version too.

And that's why our scroll areas in the Electron app as well as the web app for T3 Code are as incredible as they are and don't have all the weird bugs that I see when I use things like I don't know codecs and also of course cloud code. Jay is obsessed with performance. And what's even crazier is that Jay's legend list implementation could be ported to web because the whole thing is JavaScript.

It is not a native library. All the other list libraries that made it way nicer to have long list in React Native are native code with a little bit of JS. His is JS only because he built the virtualizer in the JS layer so performantly that it kind of just flies no matter what, which is why porting it to web was not too difficult either. This guy knows his performance.

So when he comes up and says in my experience in benchmark comparisons, React Native is faster than native, there's a reason, and that's what we're about to get into because his belief that React Native is strictly better than native comes from a really solid foundation. That foundation is here. The state of the React Native team and also more importantly the history of the React Native team.

One of my favorite questions to ask people in the ecosystem is to guess roughly at the peak of the React and React Native teams. If you split them to React, like the core library and web stuff against React Native, the ones building the different platform integrations for React Native, how many engineers do you think Meta had on both? Do you think they had 50 on both, 500 on both?

Do you think it was a 50-50 split? Do you think more of them were on the React core version? Cuz like React and React Web are so important, right? How do you think that split looked? It's my understanding that the nonreact native side of React, so core if you call it that, web, everything else, was under 30 people and React Native has had over 300 at points, 10 to one in favor of React Native.

Do you know why? It's actually pretty easy to know why if you look at the repos. React Native is a much much harder thing to build than React because React needs to give you DOM access with a better way to update it. React Native needs to expose all of the native functionality for iOS and Android and all the crazy things they did with the Quest line all in a single codebase that allows you to access all of it in the JavaScript layer.

Imagine if React had to custom expose every single thing you can do in Chromium and you couldn't just call window. Like imagine if window couldn't be accessed in React and DOM couldn't be accessed in React and nothing could be accessed in React directly in the browser. So you had to reimplement all of it to do it in React. It would be insane. But that is what React Native did.

And that's what makes React Native so impressive. That's why there isn't a good solid JS native or a spelt native. Because to do it, the best bet is to take the hundreds of millions if not billions of dollars that Meta has spent making React Native great, which by the way, what do you think were the types of engineers that were on this React Native team?

You think those were JavaScript devs? because I would guess most React Native haters would say that it was. And this is the thing. I have met a lot of devs who work at Apple and Google directly. I've met a lot of devs who are hardcore loyalists that will defend Xcode to this day. The best native devs I have ever met, I have ever worked with, I've ever collaborated with were on the React Native team because they loved Native so goddamn much that they wanted the worst JavaScript dev on the ads team that is fresh out of

college and has no idea what he's doing to not make their app worse by writing shitty React code. They wanted their beautiful native platform to be used everywhere it could be, regardless of the experience and the competence of the dev. So they wrote the best possible native bindings to allow for less capable devs to write native code that is better than they would have.

So the question you have to ask yourself when you are writing an app is who has better native devs? Do you and your team have better native devs or does meta? And I would guess for pretty much everyone watching this video, Meta has hired and employs better native engineers than you do. And as such, you get a lot of benefit from writing the coattales of their work.

But things have changed a bit because do you know who else is really good at native code? I'll give you a hint. It's codecs. Yeah, agents make the gap way way smaller. Previously, you basically needed to use React Native if your team wasn't like the type that go to WWDC or your app would be worse. Now you're just asking your agent anyways. So that gap doesn't matter anywhere near as much as it used to.

And that one is the one that's hardest for me to swallow. I will still miss OTAAS if I go native. I will still miss lists that work if I go native. I will still crash out of Apple all the time, but I have less workarounds. But the skill gap that made me feel like I had to use React Native because I know how much better those devs are than me. 56 Soul and Astra are close enough that it matters less.

It just does. And please, for the love of God, don't make me talk about Electron right now because that is not the case in Electron. I'll do a quick Electron crash out after. So, uh, yeah, subscribe if you haven't on YouTube and you like things like this. If I see a huge spike in subs from this video, I'll know you actually want me to talk about tech again.

And then I'll do an Electron video again. I swear I never would, but I will if I have to. And the way I'll know I have to is if a thousand of you guys subscribe watching this. So, yeah. Hit that red button if you haven't yet. Half of y'all have. make me talk about God, I'll have to talk about the T-word, won't I, Tori? [ __ ] No, don't make me do this, guys.

Or do I help the channel? Anyways, I did not put this item here as why the React Native team is exceptional. I put it as the state of the React Native team because we aren't the only ones thinking this way. Meta has been disbanding the React and React Native teams. That's why we're seeing all these awesome people, folks like Potato, Lauren, who was one of the lead engineers working on the React compiler, suddenly ending up at Cursor and reinventing rock bottom, becoming a famous engineer on Twitter, which has been

awesome to see. Like genuinely really, really cool. I've loved her forever. I think she's one of the funniest and like most locked in devs of all time. So, her finally getting noticed within like 3 months of quitting meta because she couldn't get as much investment in working in React stuff anymore. And now she's like a worldclass legend. And the speed that that happened was hilarious because that was the quality of engineer that was on the React team that is now bored and going around the industry.

And there's a handful of these too. I know a lot of people who were on that type of thing at Meta that didn't want their job to become data labeling. So now they're doing other things other places. As such, the quality that we were relying on from the React Native team is just not there as much because they're gone. It's almost like a bit of a swan song.

They got the new architecture out right as things got as chaotic as they have. Rest in peace. What React team was before. Things are very different now. Everything is different now. The talent density is not where it was anymore. Not because the talent got less talented or they hired a bunch of dumb ass. It's just cuz the team is smaller, not being invested in as much.

So, the competence of teams outside of meta have gone up, especially with agents. And the quality of what we get out of the React Native team has kind of plateaued because they're not maintaining it as actively as they did before. And that should be real cause for concern. I don't think it's going anywhere. There will always be things that rely on it.

And even at meta, like the difference is instead of having humans maintaining React Native, they'll just have agents doing it and it will not be moving as fast as it did before. It will not be as thorough as it was before. It will not be cared about in the way that it was. It just won't. The people who poured their blood, sweat, and tears into React Native have lost so many of their close friends and co-workers that even if there are some still there, they are demoralized and not feeling great.

And it's hard to make great software when you feel like [ __ ] and you see your co-workers who you've worked with for a decade vanishing left and right. So I want to be clear that I'm not saying like React Native team's horrible now. It's actually the opposite. I think they are so heartbroken that the quality of things that they did will not be as revolutionary as it has been historically.

So, how do we summarize all of this chaos? I think it's an interesting experiment, and I'm excited to see how it goes. We need more big companies to make these types of big bets because that's what React Native was in the first place. A massive bet made by a handful of really talented people that had watched the React bet out way better than expected.

The idea of what if we just nuke everything in the UI when a change happens was so stupid that it almost had to work. And it did, and it was great. And then when they went to native land, they wanted similar. They wanted something simple enough that the web team for ads could contribute to the mobile Instagram apps ad platform. And they got it. And they got it working incredibly by overinvesting in it, bringing in incredible engineers who do super difficult [ __ ] And they did it and they won.

And now it doesn't matter as much. But that type of bold move to say this JavaScript thing we built for the web is working so well, we should reinvent how mobile platforms work to see if it works there, too. That is a similar bet to what Shopify is doing here, saying, "Hey, these agents are really cool. They seem pretty good at porting software. What if they can port us to native again?"

Notice how I never said anything about multiplatform. Notice how I never sold that as a huge benefit here. Notice how I never said anything about how native is obviously better and everybody should be striving for it and React Native is for lazy people. None of that's true. None of that matters. It was never write once, run everywhere. It was learn once understand everywhere.

Once you learned React, you could learn the platform and combine them. You didn't have to learn a new language. You just had to understand mobile. You had to understand how it felt to use an app and have it feel good. And if you understood that and you understood React, you could make a good React Native app. Especially now that agents are involved.

But whether you're using React Native or the native platforms, you should be testing the mobile apps on both platforms when you build to make sure they work as expected. Which means somebody in your team's got to suffer with an Android phone. For that, I am sorry. I'm honestly more sorry for that than anything else I've said here. You want your Android app to be good, the solution isn't React Native or Cotlin or some other library or jetack compose.

The solution is to make someone daily drive Android on your team. Actually, if you do have an Android person on your team already, you should make them daily drive an iPhone so they can know how a phone's supposed to work and then make them go back to Android and then they'll fix your app. I think I've said all I have to here. Can you tell I've been through it with mobile?

This was a fun one for me. I don't think this video is going to perform well, so please prove me wrong. If you liked it, subscribe, give it a like, leave a comment, and send it to a friend. Give me the singles that you guys want videos that aren't me just talking about agents the whole time, and I'll make more of them. But if this video bombs, then you're going to get what you ask for.

So, for once, I'm asking you engage. I hate doing this, but I'm asking because if you do like this and want more like this, I need to see it in the systems pages and on the studio on YouTube, or I'm going to assume what those numbers say, which is that y'all don't care. So, show me that you care so I can justify doing this. Otherwise, I'm going to have to do what people actually care about.

Not because I am following the money, but because I want the things we talk about to have impact and to matter and for the conversation to be had and heard. And if people aren't listening and they aren't watching, then it's a waste of all of our time. So, please try to prove me wrong here because then I can go do the Electron video that I really don't want to do. Thank you as always and until next time, peace nerds.