EngineeringApril 15, 20266 min read

React Native Was the Right Call. Until It Wasn't.

React Native was the right call when shipping fast meant writing less code. But with AI agents shrinking that cost, native looks much more compelling.


Look, I owe a lot to React Native. It helped me build a cross-platform mobile app with a small team that grew to 30+ employees, became profitable, and was growing rapidly before a successful exit. I genuinely don't think I could've pulled that off going iOS native and Android Kotlin. It would've been too much code, too much testing, and way too slow for a startup that needed to move fast.

What React Native really gave us was the ability to hire smart, talented developers who didn't need mobile experience. They knew JavaScript, they were great engineers, and React Native let them be productive on mobile almost immediately. That's a superpower when you're building a company.

But for me, that era has ended.

This Trade-Off Looks Different Now

AI changed the math on this pretty dramatically. For anything beyond a prototype, what matters now isn't minimizing how much code has to be written. It's whether the thing is architected well, built around the actual business problem, and easy to maintain and evolve as the product changes. That's what gives you velocity over time.

And here's the truth that React Native developers don't love hearing. Native code always feels better. The animations are never quite as smooth in RN. There's always a delay bridging new features. And then there are the leaky abstractions, especially if you're building for both iOS and Android.

I knew this intellectually. But I didn't feel it until recently.

3 Weeks to Convert a Full Production App

I recently converted a full production app from React Native to Swift.

The excitement hit early, as soon as the first screens were built and I could replicate the first real use case. It felt buttery smooth. Because I'd been living in the React Native version for months, the difference was hard to miss. The app just felt faster. Animations were smoother. Interactions felt more direct. And a lot of the weird little cross-platform compromises just disappeared.

The whole migration took about 3 weeks. What felt like the first 80% came together in maybe 2 days. After that, I spent the rest of the time on fine-tuning: edge cases, polish, and the parts where native opened up better interactions that I actually wanted to use.

That was actually the bulk of the work. Not just converting pixel-for-pixel, but taking advantage of the nicer interactions, animations, and capabilities that native gives you. It was a conversion plus an upgrade.

The Surprising Part

One thing I didn't expect: the iOS codebase ended up noticeably smaller than the React Native one.

I think a lot of that comes from SwiftUI. You can build pretty sophisticated UI without nearly as much scaffolding as I expected. It feels very different from JSX, and honestly it took a minute for my brain to adjust, but it works.

Now, if you add Kotlin for Android too, the total code probably evens out. But looking at the iOS app by itself, it felt lighter and easier to reason about.

And here's the interesting bit. I genuinely felt like the AI agents performed better with that smaller, cleaner codebase than the bigger React Native one. Maybe SwiftUI is just more idiomatic. Maybe that's my bias. But the agents seemed to have an easier time reasoning about it.

The API is a GraphQL API with subscriptions, so I used Apollo iOS Client to handle it. If you're doing a similar migration, having a well-structured API layer makes this whole process dramatically easier.

Next Up: Kotlin

Now I'm ready to tackle the Android migration. I'm an iOS user, so coding for iOS felt natural. Android has a learning curve just because I've never used it outside the emulator and don't really understand its navigation and UI patterns.

Here's my prediction. The first 80% will probably take about 3 days.

Then I'll spend the bulk of the next 3 weeks just learning Android properly: its patterns, its navigation, its UI conventions, and how native Android wants to work. That's probably the real job. Not building screens, but resisting the urge to shoehorn everything into iPhone patterns like we did in the original app.

So call it about 3 and a half weeks of nights and weekends. That's my guess.

Oh, and I've never written Kotlin. My only Android experience has been through React Native.

So if this gets done on schedule, it'll feel like a real step change for me. I've been using AI agents heavily for over a year, and they've helped me ship a lot of real production code. But up to this point, it's mostly been in stacks where I could still reason through every line, debug the hard parts myself, and step in whenever the agent got stuck.

Kotlin is different. This would be my first true zero-to-production run in a language I've never touched before. Not a prototype. Not a weekend experiment. A real production app, with real paying users on the other side of it. That changes the bar. Expectations have to be met or exceeded, and there's real risk if they aren't. As an experienced developer, that feels like a new level unlocked.

I'll check back in about a month and let you know whether Android humbled me or proved the point.

So Is React Native Dead?

No. And you should still consider it.

There's still nothing that beats the speed and efficiency of getting iOS and Android with a 95% shared codebase, plus the simplicity of JavaScript and TypeScript. React Native is still a great tool, and for a long time it was exactly the right trade-off for companies like mine.

But if you care deeply about how the app feels, I think native wins.

And now that writing all that code no longer takes the kind of time it used to, that trade-off feels a lot more practical to me than it once did. Two codebases is still a real cost. I don't want to pretend otherwise. But when the code itself becomes less of the constraint, you can move faster on the things that actually matter: better architecture, better product decisions, and taking advantage of native platform features the moment they show up instead of waiting for the abstraction layer to catch up.

If you don't care about that last 10% and your customer isn't going to notice or care, then by all means use React Native. It's still a great choice.

The One Thing I'll Miss

Over-the-air updates. That was genuinely one of React Native's best features. Push a fix without going through the app store review cycle.

This need was starting to subside with Apple reviews happening so fast. But with AI-generated apps flooding the store now, those review lines are getting longer. I do foresee missing OTA updates more in this upcoming year.

Worth the trade-off though. For me, at least.

End of article

Work with me

If you're building a product and want a thoughtful partner to help refine it, make the right tradeoffs, and get it shipped, I work with a small number of founders and teams each year.

Reach out
More from the blog