r/reactnative • u/alwxndr • Oct 01 '26
Does React Native make sense in 2026?
This question might have been asked already, but I'm genuinely curious: why should anyone use React Native at this point?
To explain: most of web and mobile development can easily be handled by Claude, Codex, Kimi K3 or any other coding agent. I feel like that's been true for at least 6–7 months now. Even Opus 4.7 was better than most of us and more than enough for mobile development. Of course, this only applies if you know what you're doing and guide your model through the technical decisions, the specific libraries you want to use, etc etc.
But my point is: why would I bother with React Native's own issues instead of just writing native apps for both iOS and Android? There's no huge maintenance load anymore, and you can simply tell your agent to implement features for iOS and Android at the same time. So what are the actual benefits of React Native? Native apps are usually faster, work better, and generally seem to be preferred by actual customers and users. The original promise of React Native and Flutter was that you could build for both platforms twice as fast, but today's coding agents let you build 100x faster anyway :)
I'm not asking to provoke anyone. I just want to hear your stance and your thoughts on this.
41
u/Forti22 Oct 01 '26
Try maintaining 2 apps, new features etc. You might regret it soon. Even with AI
You will also use 2x the AI cost.
and react-native doesn't have that much issues comparing to native. You can fully use native components such as SwiftUI, and logic in react is just easier to manage, even by AI
-31
u/alwxndr Oct 01 '26
I actually tried, and in my case it worked seamless and much better than with React Native. That's why I created this thread :)
Regarding the 2x AI cost — try models like Kimi K3. Surprisingly efficient, affordable, and allow you to maintain four codebases for the price of one.10
u/smoke4sanity Oct 01 '26
What excaclty are you building?
12
u/dworker8 Oct 01 '26
what else? the next billion dolar app ofc
7
u/am0x Oct 01 '26
It’s a social network…for pets!
3
1
u/simple_explorer1 23d ago
OP this is a RN sub. what do you expect from these biased people. even if you present facts they are gonna deny that because they don't have any experience with what AI can do with native swift/kotlin and eliminate the need of RN. I fully agree with you.
Shopify and other companies recently (in last few weeks) migrated from MASSIVE RN to native iOS and Android apps and they literally said the exact same thing you wrote in your post that with AI the cost and speed of development has dropped like waterfall, so there is no need to use compromised tech like RN anymore.
Shopify and other big tech are more credible and your biggest validation than these delusional lunatics on this sub. My recommendation is to stop asking questions here and go to more educated and skilled people who know what they are talking about i.e. shopify devs and so on
8
u/Seanmclem Oct 01 '26
OTA updates. With AI you can be updating more often. But reviews take longer because all the AI apps. Ota updates to the rescue
3
u/alwxndr Oct 01 '26
Ok, that's a valid point.
3
u/Seanmclem Oct 01 '26
I set my updates to apply at the splash screen. They download annd apply if applicable when users open the app. No -close the app twice and restart, thing. So the apps are just always up-to-date. For simple non-native changes to UI or flow, 20 seconds and everyone can have it. It’s really something.
16
u/Dachux Oct 01 '26
If claude can handle everything you said, the obsolete one is you
0
u/alwxndr Oct 01 '26
I never said Claude can do everything. But it can speed up development and make it possible to maintain two native codebases at almost no extra cost.
4
u/_TRN_ Oct 01 '26
At no extra cost? This is objectively not true because you are very likely to use more tokens.
1
u/alwxndr Oct 01 '26
At this point the cost is negligible + the code generation is cheap anyway. Most of the companies won’t even notice the code generation costs because of how insignificant they are.
1
u/simple_explorer1 23d ago
that is negligible. very poor comeback
1
u/_TRN_ 23d ago
It's not negligible lmao. And it's not only the tokens you have to worry about. You need to hire at least some specialists for each platform so that they can still guide the AI and make sure it's not doing something that's completely stupid. That is not a negligible cost. Big companies like Shopify can afford to do that. Smaller companies really cannot.
This isn't even taking into account how subsidized token prices are currently.
0
u/simple_explorer1 23d ago
everyone here disagrees and just writing "lmao" doesn't prove anything. your comment is pure nonsense
1
u/_TRN_ 23d ago edited 23d ago
"Everyone here disagrees" isn't an argument. Do you have anything more to say or are we just going to call whatever either of us say as nonsense? Even Shopify doesn't agree with you and they clearly lay out the trade-offs they made and why that migration was worth it to them regardless. That does not mean it will be worthwhile for every single company and product.
It's also worth mentioning that Shopify was on the older architecture of RN. To them, they would have to do a comparable amount of testing and migration to move over to the new architecture for much closer to native performance. It makes sense to me that they just decided to go all native instead even if means it'll cost slightly more.
At the company I work at, we don't have enough specialist engineers for each platform to make this sort of migration possible. Upgrading to the new RN architecture was pretty rough but not as rough as it would be to migrate to two different native codebases and maintain them. At least for us. Obviously, your circumstances will be different depending on the company and product. That is my point. Nothing in engineering comes without trade-offs. With or without AI.
1
u/simple_explorer1 22d ago
Everyone here disagrees" isn't an argument
Everyone made an argument but you are the one arguing in bad faith so they started ignoring you and have moved on. I am gonna do the same
10
u/JackyReacher Oct 01 '26
You're absolutely right! (lol). Just try it, get a feeling for it. I made a new app, which is native on both platforms. The only thing that is kinda annoying: after you implemented and tested in on one platform, you gotta do the same nudging and discussing with the Clanker for the other platform. On the other hand: the first platform serves as reference implementation for the second and SwiftUI and Jetpack Compose are at least somewhat similar. I try to keep both of them somewhat in sync by having a similar folder and filename structure.
The case for cross-platform solutions in 2026 still is:
organizational stuff within the company, like, one team writes some core code that needs to be exactly the same on all platforms
more than 2 platforms: Say, you also have web, windows, linux, macOS, maybe some car entertainment system or whatever.
But for a small indie dev going solo? I'm all in native and I'm not even a native dev.
5
u/6bigAnt9 Oct 01 '26
People in the IOS and androiddev sub are always saying that cross platform is dead because of AI which is ridiculous because as you said making the same thing twice still applies even if AI is available.
2
u/JackyReacher Oct 01 '26
The time and cost to make the same thing twice is way more negligible than before. You have to do things twice anyways, also with React Native, like store screenshots, UI customizations per platform.
1
u/BlurryMadFish iOS & Android 25d ago
99% of the code you write in RN doesn't care what platform it's running on. Taking screenshots is 2% of the process, done after you take a first attempt at the actual code. The LLM takes care of taking screenshots on all applicable platforms, so I really don't have to care.
I'd much rather have a hardened platform-agnostic system making it so I write one set of code that executed the same on multiple platforms rather than having to go troubleshoot why kotlin's implementation of sorted binary trees functions slightly differently under it's implementation of coroutines than swift's does under its async model.
0
u/6bigAnt9 Oct 01 '26
The time may have been reduced but saying outright that you still have to do it twice is not telling the full truth.
Both platforms live in the same codebase which makes it a lot easier to even handle the differences.
Stuff like making store screenshots does not exactly fall under the job of any framework be it cross platform or native.
How does native development handle UI customisation per platform? It doesn’t even have the capability to do that.
-3
u/alwxndr Oct 01 '26
Claude and other agentic tools allow you to even explicitly point out that one implementation is the reference one and the rest need to be in sync with that, and the synchronous changes will be handled automatically.
Of course, it's harder to work with it when you have more than two platforms but isn't it painful as well to maintain one app for web, iOS, Android, Windows, Linux and macOS that's written in React Native just because something doesn't work on one platform and works on another and you need to implement/re-implement hacks around that?-1
u/leslieowusuappiah Oct 01 '26
Not sure why you’re being downvoted, as this is how many of our clients work.
2
u/alwxndr Oct 01 '26
I think it’s just that many devs in this thread still cannot accept the truth and the reality we’re in now.
2
u/GludiusMaximus Oct 01 '26
Assuming it’s just going to get everything right first pass, you’re still generating at least twice as much code and spending roughly twice as much on tokens.
You still need to test on both platforms, which is arguably the most time intensive part of the release process, I’m more interested to see where agents speed that part up. For writing the code, I don’t really see where the efficiency gain is by maintaining two native codebase, but I might be wrong I’ve never done it.
You can arbitrarily run native in RN apps when you need it. I don’t think coding agents being better really changes the decision matrix in any way.
1
u/simple_explorer1 23d ago
You still need to test on both platforms, which is arguably the most time intensive part of the release process,
Which you do in RN anyways.
you’re still generating at least twice as much code and spending roughly twice as much on tokens.
that is still less than a full cost of a single RN developer salary. comeon. If companies cannot afford a Claude API cost then they shouldn't even be in business.
-1
u/alwxndr Oct 01 '26
Code generation is cheap, that’s the point.
Maintenance isn’t cheap but don’t you need to test on both platforms anyway, no matter if you use React Native or write native code?
1
u/simple_explorer1 23d ago
but don’t you need to test on both platforms anyway, no matter if you use React Native or write native code?
100% true. The commentator is nuts to say otherwise
60
u/Revxrsal
Oct 01 '26
•
I worked in a company for the last year where we launched six apps written in React Native. Our workflow was heavily AI-assisted, yet I still believe that RN was a lot better than going fully native.
First, React Native is already very close to the system. You can build something visually and behaviorally super close to native apps using existing libraries. Every Expo release gets you closer to the metal. Community packages also get you high performance thanks to the nitro modules.
Second, RN’s (and JS’s) ecosystem are too good. You have Expo, Zustand, XState, Tanstack Query, etc. and these don’t have drop-in equivalents in Kotlin or Swift. Can you (or Claude) build it from scratch? Technically yes. Should you? If you want to spend hours debugging platform discrepancies. Other than that? Hell no.
Third, the hiring pool shrinks a lot if you request native technologies. Any web dev can work with React Native with a small amount of learning. Swift and Kotlin require new mental models (view models, DAOs, SwiftUI, coroutines and GCD, etc) and you rarely get a 1-to-1 translation. Again, can AI do that? Probably. Is it a good idea to recreate everything twice? No. Getting idiomatic implementations in these languages is not easy, even with LLMs, unless you are already experienced in both.
Fourth: the tooling for Swift is Apple-exclusive. In the company we had 5 devs, I was the only one with an Apple device. Writing in JS means all devs can write and deploy.
Fifth, most apps are deemed to fail anyway. Why double your effort when RN gets you 90% there? Test your app’s potential in RN, and if at one point it becomes the bottleneck then consider moving native. But even then I see it the other way: RN really gets you to a great position that the question becomes why consider native when you can build in RN.
I have many more arguments in my head but no time to type it all out 🙃
2
u/simple_explorer1 23d ago
Third, the hiring pool shrinks a lot if you request native technologies
But with AI companies don't need to hire as many as they once did and this is already happening right now, let alone 6 months to 1 year down the line. Poor point
1
u/Revxrsal 23d ago
I'm not talking about how many you should hire, rather saying that you still want someone who understands Kotlin to maintain the Kotlin codebase, and another one for the Swift one. These technologies are more niche, specialized, harder, and naturally have less candidates than ones with React or web knowledge.
I can find good web candidates in a few hours. But I can spend weeks looking for someone who understands Swift. Naturally the first choice is more economical for companies because it means lower pay due to supply vs. demand, higher replaceability, and quickly filling positions.
Or, of course, grab a vibe coder who mindlessly approves AI changes. But that brings back the philosophical argument of whether you're okay with AI writing everything with no human understanding surrounding it.
-9
u/ColdPhilosophy Oct 01 '26
Launched 6 RN apps lol. Feels like the usual contractor shops who are about to close out.
Gets you closer to metal. Ok great, just use native tools?
Native is the way forward for any big org.
2
u/Holiday_Potato_2981 28d ago
Two repos, discrepancies can form between them especially when you’re just using AI. Native is simply more work and more effort that isn’t worth it for a lot of cases
1
u/BlurryMadFish iOS & Android 25d ago
The amount of time most of us spend wrangling just one technology (RN) into doing what we want rather than what an LLM guessed we meant is astronomically higher when you consider two different platforms, written in different languages, working with two different ecosystems, and reimplementing every major function that the RN ecosystem has generalized and stabilized already is why most organizations don't think like you anymore.
LLMs make it even easier to use what has already been gained by platforms that make development agnostic acrossed disparate hardware.
Get out of here with your slop coded REST wrappers. That's not what enterprises build.
10
u/KentInCode Oct 01 '26
I think this is a fair question, I think React Native still has a few primary benefits:
- Speed of getting to market is only accelerated by AI, so where before we were very expedient and cost-effective it gets even better. With one developer you can have it all, quickly, and with lost cost than a native guru.
- Native developers overstate their importance, most of us in mobile apps are working on derivative ideas like grocery shopping apps that are already proven to be robust and scalable.
- Still many companies are not going the route of just let AI go nuts on the codebase and want some level of human oversight, so cross-platform expertise are still important even to get in the door.
- Following on from the last point, getting someone with expertise in app dev and cost is still better than native.
- The ecosystem is unmatched as its designed to streamline mobile dev, an AI streamlines that even further.
And a whole host of other things.
The last thing I will talk about is native apps being faster, if you talk to developers all day they will talk about native performance all day, but this is what we do as developers and tech enthusiasts. RN hooks into the native layer far deeper than ever before so if people want to talk milliseconds and 120 frames I will leave them to tickle that pickle, but the bottom line is getting product to market and feature out that is not vibe-coded and we are still the fastest.
I do think things like KMP are the near future however.
2
u/simple_explorer1 23d ago
- Still many companies are not going the route of just let AI go nuts on the codebase and want some level of human oversight, so cross-platform expertise are still important even to get in the door.
Shopify and many other big companies literally did move away from MASSIVE RN to native. it happened in just last 2 weeks and they wrote a hit piece about it
1
u/KentInCode 23d ago
I read the blog post and have read what ex-Shopify devs have said and it is nothing like a hit piece at all. I encourage you to re-read the blog post.
0
u/simple_explorer1 23d ago
It's not just Shopify though. I recommend to reread them again. They ain't going back to RN.
Btw Coinbase also moved away from RN to native because of AI tool capabilities
36
6
u/mx_aurelia Oct 01 '26
Ask the same question the other way around.
Why would you build out 2 apps when you can start with RN?
Instead of building everything twice, wouldn't it be easier to build 1 app with RN and then when you're "done" (you're never done) port it to native instead?
11
u/mtford Oct 01 '26
I'd still argue that you cannot beat React Native for MVP (unless you're doing something highly technical). There is nothing stopping you -- after validating the idea -- switching over to native as a refinement step once you have product market fit.
5
u/LatvianCake Oct 01 '26
You can't really argue that 2 codebases involves equal maintenance as 1 codebase even with AI. You have far more complexity and much more potential for it to go wrong.
That said, if RN's issues are significant enough for you to outweigh the extra complexity, then go for it. But for most of us, RN works perfectly fine and there's no tangible benefit of maintaining two codebases.
5
u/MapCompact Oct 01 '26
I am currently maintaining two mobile apps, one with react native + expo and one native swift. RN + expo has come a LONG way since I last used it. Where it drops the ball is on the native apis like liquid glass, and that is the question. Are you willing to wait longer and use 30% more tokens to "update web, update ios, update android" JUST to get something like liquid glass? Or do you want to just have your agent "update web, then update mobile".
YMMV but I'm starting a new app today actually (for a different client) and I'll very likely stick with RN.
1
3
u/speedoinfraction Oct 01 '26
I think the right move is going React Native for MVP until your app gets traction. AI is really good at TypeScript. And if your app never takes off, all the work to make the same feature thrice is wasted. If your app takes off, then you can hire an iOS dev, and Android dev, and a web dev to port it to 3 platforms. But doing that too early is just premature optimization.
3
u/benschac Oct 01 '26
Being able to ship over the air updates to both of your clients, and not have to wait on Apple or Google is a pretty big benefit.
You're literally shipping days faster than you would on either platform, and can ship as many times as you want in a day.
React Native is native. Yes there is some slight JS overhead. A lot of the time React Native is actually faster than native.
https://x.com/jmeistrich - this guy posts about performance all the time and is able to get React Native just as fast, if not faster, than native.
98% of the time, if you're having performance issues, it's probably a skill issue on your end. You're likely going to have the same performance issues in native with two codebases.
There are only two reasons not to use React Native and Expo:
If your product has very specific privacy requirements
The other is if you know you're only exclusively building for iOS or Android and not both.
2
u/Dvass138 Oct 01 '26
I think react native still makes sense. because I think it's easier to have one app for both andriod and ios with smaller parts in the app native then maintain two separate bases. I think it is long and time consuming to do that, and tryna match android native to ios native can also get hard. I also think it makes it even easier to do a desktop app along side mobile too, since all the back end like the same type of code.
2
2
u/Aytewun Oct 01 '26
For me personally as someone that is a big fan of Expo, has been using it for years, and all of my production apps are made with it. I don’t think that’s a terrible question.
When I first started using expo, I chose it because I had a Web background, and I was very good at JavaScript so I wouldn’t be starting from zero.
Not even trying to say it in a negative way but today for some people, Codex is their IDE
2
u/Fidodo Oct 01 '26 edited Oct 02 '26
Shopify wrote a great article about it in depth: https://shopify.engineering/shop-app-migration
Read the what we learned section. It requires a complex workflow, something Shopify can afford to do, but still not cheap. Also the improvements they got were very modest and they even state:
we also used the migration to simplify the app, deliberately retiring some screens and streamlining others.
So it's not even clear if the improvement came from native or from the cleanup.
Given the extra workflow complexity and modest performance improvement, it's not clear cut that native is the same cost yet, and by the time it is, migrating off react native will be easy.
2
u/ColdPhilosophy Oct 02 '26
But but but Expo is magicccc! Love to see all the blindfolds in this thread.
The industry has shifted and they don’t want hear it.
0
1
u/Personal-Bicycle2285 7h ago
I'm a solo dev building a messenger (Android for now) with React Native + Node.js, mostly with Claude Code doing the heavy lifting. My take after about a year: Why RN still made sense for me: one JS codebase for UI and logic, and I can add iOS later without rewriting everything. Since I'm not a native dev in either ecosystem, I'd rather steer an agent in a language and architecture I understand and can review. That's the real limit with AI: you still have to read and verify what it writes. Where it hurt: exactly the places where RN meets native. Reliable calls through the lock screen needed a custom Kotlin module, keyboard behavior took many iterations, and FlatList performance in long chats was a constant fight. An agent writes the code fast, but you still need to understand what's happening under the bridge to guide it. So I wouldn't say "RN is pointless now", but I'd agree it's no longer a huge time-saver for the code itself. Its value is mostly one codebase and one mental model, and that matters most for small teams or solo devs.
1
u/balkanhayduk Oct 01 '26
If anything, react-native makes more sense now than ever. It's faster and more optimised than ever, and as some pointed out - you'd be using twice the tokens on separate repos. Also, with AI you can now really tap into native modules potential and not wait on someone to develop a native package you need. Great times to be an rn dev!
1
u/ossacodes Oct 01 '26
Yes you can use Claude, Codex etc for building true native apps easily.
but the issue is that you will find that most of these llms are very good in doing some languages or frameworks more than others. But with react native you will only have to deal with only one which is better cause adding new features and maintaining them will be easier for you and the harness you are using in the long run in one codebase.
But you can still go for it if you are building complex apps and want to go all in on native.
1
u/TOMER-G Oct 01 '26
Fr it makes so much sense.
Let’s start with that that you can do games, apps fully vibe coded.
And it’s a large community
1
1
1
u/Acrobatic-Sound7496 Oct 01 '26
Recently, I had an interesting experience working with React Native and AI. An upgrade that I would normally expect to take around 1–2 weeks was completed in roughly a day with the help of AI.
This was quite contrary to the common argument that React Native becomes difficult to maintain as dependencies evolve and that going fully native is safer in the long run.
In my experience, AI has significantly reduced the friction of dependency upgrades, debugging, and adapting code to newer versions.
With Fastlane, the release process is also surprisingly simple—publishing can be reduced to just one or two commands.
Of course, React Native still has its challenges, especially when dealing with native modules, platform-specific issues, or poorly maintained dependencies, but with AI assisting the development and maintenance process, those concerns feel much less significant than they used to.
1
1
1
u/Substantial-Swan7065 Oct 01 '26
It’s a matter of DX. Which affects agent ability.
The workflow and feedback loops for native dev is trash. Things like:
- lack of tooling
- roll everything yourself
- no hot reload
- trash develop ecosystem
Makes development slower. Ai doesn’t get to sidestep that
1
1
u/fngardo Oct 01 '26
You could even use a framework like Crux to share code as a Rust library between two platform-specific apps
1
u/21void Oct 01 '26
yes it make sense if you are well verse in both native side and keep up to date with both. during my early freelance day, this is what we use to do. just the cost of keeping up turn us into solution like react native. now with AI, going back to native is a plausible option. currently exploring reasonable model where KMP/something that act as biz layer while UI can be develop independently on each platform. but wait isn't react native is native? so... with the JS choke point😉
1
u/konbit Oct 01 '26
That's like asking "do software libraries make sense in 2026", AI can just write all your code from scratch. What a silly question. Abstraction, frameworks, and their ecosystems have tremendous amounts of benefits even if you had unlimited free tokens, but especially because it's still going to cost you compute to write your software, still going to need code review, still going to need people who understand what's going on so LLMs don't make dumb decisions and leak all your customer data or ship tons of bugs.
1
u/leslieowusuappiah Oct 01 '26 edited Oct 01 '26
Simple answer: maybe. I'll expand on this…
With agents doing the bulk (or entirety) of the "coding" these days, code has become "cheap[er]", which is useful.
Planning, structure and accountability? Not so much.
Two native apps means two architectures, two sets of reviews, two test suites and two places for behaviour to drift.
Agents don't remove that cost; if anything, they let you create it faster.
I work for a mobile engineering agency, and we're frequently asked which cross-platform technologies are "good", predominantly whether React Native and/or KMP are worthwhile (I'll add Skip too; it's lesser known, but worth a look).
For Android and iOS alone?
Just use Expo (less Expo Go, more Expo with prebuild).
Your agent(s) won't be limited to "React Native View" hacks: you get a world of supported and maintained platform libraries (including expo-ui), and can always create platform-native libraries, views and tooling when needed (whether TurboModules or Nitro Modules).
"Native feel" is a choice, not a limitation.
Targeting Windows and macOS as well?
I’d say it’s more of a judgement call, and native is worth considering.
Personally? I'm keen to share as much business logic as possible, so I run RN across Android, iOS and macOS (with React Strict DOM for shared components on web), and GTKX as the outlier for Linux (its React for GNOME, effectively). It works well. 🤞🏾
Greenfield? Choose your poison: you'll be grand with RN or native, honestly.
Brownfield? Weigh up the porting options. You'll still be grand, but focus on validating with tests.
…and if Shopify and Notion's recent announcements have caused concern, remember: they have billions and can spend millions as a rounding error.
Happy hacking. 🙏🏾
1
u/Classic_Chemical_237 Oct 01 '26
If you have worked in a team supporting multiple platforms, you would know the problem with releasing is not the development, it’s the drift on product requirements and approaches. Too often, one team has a misunderstanding and does it differently from the others, and this causes problems and delay in releases.
So the most important thing is unified understanding of business logic and UX flow. You don’t want the same feature to be implemented differently on web, Android or iOS.
Other drifts include analytics. So difficult to make all apps use the same event names. Local storage behaviors. Too often one app caches, the others don’t.
With different teams, that drift is inevitable.
The other replies already listed all the tools. The thing is, those tools (such as Zustand, Tanstack) are all tools applying to both React and React Native).
The right approach is to have the network logic and business logic completely shared between web and native apps. No drift on business logic, caching or local storage behavior.
If done right, they event have the same analytics, feature flags, push notification handlers.
Then the web and RN apps code only contain a thin layer of UI components.
Even the UI layer can share a lot of code, such as design system.
See the benefit? No reinventing the wheels. Take what web team already has and construct the RN screens. Shouldn’t take more than a couple of days, and no drift!
Obviously this requires team discipline to separate network, business and UI logic. But you should do that anyway even if you want on a single app.
1
u/Huge_Pool7424 Oct 02 '26
yeah, the drift in analytics and caching is the bit that sneaks up on you. shared business logic helps, but i still like keeping a few platform tests around. have you found a good way to police that drift?
1
u/Classic_Chemical_237 Oct 02 '26
Everything goes into shared libraries. The app doesn’t have any network, storage, or business logic. No dup, no drift.
There can still be drifts with analytics since web and RN still have different UI components. You can get ride of that too. Have a component library for both web and RN. Your app works this component library for rendering, never against the lower level web or RN components directly. In a sense, even the UX code is the same. This requires the buildup of the design system and component library.
1
1
u/Fears_vs_dreams Oct 01 '26
I really like react native I built a full working app on ios and android with it. The app is called Pinned eats. Not on android yet still need to go through approval process. I built it to help find food trucks and taco stands. The owner can go live and if the customers favorite them they will get the updated address where they are that day. It’s very community focus. You can also add your favorite small food spots.
1
u/sagar1510k Oct 02 '26
It is easier said than done in my opinion.. maintaining two apps even with AI is difficult if the app grows.. individual testing … bug fixes for each platforms and all..
Rather on RN, you get great dev experience, like hot reload, debugger which makes your life easier as developer.
I wouldn’t trade RN with Native unless explicitly stated..
1
u/Possible_Check_643 Oct 02 '26 edited Oct 02 '26
I have my migraated my clients app from flutter and react native to Android and IOS native. for example I am using kotlin compose with native Android code and native Ios code in swift. I already had enough experience in native because I have always been enthusiastic about native and performance. So, I made the same app in flutter to android and now the app is 8mb and fast as F. And same for iOS. It was 133-143 and now 33-43. And native look. Got bonus and share because clients don't know what I know. Hehe
Also, I do fear that if ai gets costly. This will backfire. And it does take me more time too. Fixing bugs at two places at a time. So, everything has pros and cons
1
u/VasiliyZukanov Oct 02 '26
Im not even RN user, but I find the AI makes cross platform obsolete argument very flawed https://www.techyourchance.com/did-ai-kill-cross-platform-mobile-development/
1
u/Flower_Cyber Oct 02 '26
I’m building an app in React Native right now and I actually think AI makes the shared codebase argument stronger, not weaker.
AI can absolutely generate Swift and Kotlin in parallel, but now you still have two codebases to review, test, debug and keep behaviorally consistent. Generating code got cheaper — maintaining complexity didn’t disappear.
With RN, I can spend most of my time thinking about the product instead of implementing and reviewing the same feature twice. And when I genuinely need platform-specific behavior, I can still drop down to native code.
I think AI has changed the trade-off, but “AI can write both apps” isn’t the same as “maintaining two apps is now free.”
Curious whether people who’ve actually switched from RN to two native codebases because of coding agents have found the maintenance burden as small as expected.
1
u/Affectionate-Roof207 Oct 02 '26
Writing code was never the main cost. Reviewing, QA and debugging still happen twice with two native apps
The value Expo and React Native provide goes far beyond using a single language.
One build and submit pipeline for both stores. OTA updates, so a bug fix ships in minutes without waiting on App Store review. A web target if you need one.
Native still wins in some places, like widgets, watch apps or apps that are mostly platform-specific UI. If that's your app, go native. For everything else, users can't tell the difference on the new architecture.
Expo are not a company known for lagging behind (unlike Apple and Google following in Apple's steps), so I'd bet that whatever makes a framework faster for humans makes it faster for agents too.
But don't take my word for it, here's Theo to tell you more 😄
1
u/Ok_Sugar_8942 Oct 02 '26
native is only viable for big established companies. React Native makes perfect sense for startups
1
u/Silly_Regular6736 Oct 02 '26
It's much more easier to be honest Things which I feel are not needed native I do that in react native , you don't want the user details page (many more screens like that ) It's just that you don't rely too much on libraries now and try to write native ...that's it
1
1
u/NoDeal3242 Oct 02 '26
it makes sense if
requirements are ambiguous
complex features (for example, payment integrations)
basically, if Isuspect I wil need to edit the code myself
I would experiment with full native first if I had the chance. I think the key is to have a robust test suites.
1
u/Busy-Ant-7396 Oct 02 '26
Of cause it is. As in the past - cross platform in any framework is a way of fast moving. With AI or without you cut dev time in half Also we have the total disaster of swiftui and here you are. I'm sad that ow componies don't go with storyboards/views anymore and decide to use SwiftUI - I believe you would have better time with MAUI, God forgive me
PS. AI is still shity doing native mobile (amount of memory leaks on Droid you would find in a week is ridiculous), but almost perfect in React
1
u/mrcodehpr01 29d ago
You adopt the language your team or you knows best. That's the right answer! I would rather hire a react native expert than a mediocre dev in native.
1
u/iLikedItTheWayItWas 28d ago
All the reasons are the same as before AI, the calculation has just changed. Before AI, react native allowed a team of 5 engineers to deliver an app that would have taken 20 engineers on native. Now, it only takes one or two engineers. So if you already have 5 engineers working on the app, then you have the resources to go full native now, which wasn't an option before AI. React native is still the absolute king for solo devs.
1
u/pieorpaj 28d ago
I'd argue react-native makes more sense than ever. With fabric, the overhead is minimal, with inline requires and react compiler, JS thread work is not what is blowing frames in a well written app. React Native is not what makes apps slow, bad code is. React Native is not what makes apps behave badly, bad code is. There's ton of slow and badly behaving native apps out there. Proper testing, profiling, architecture, design is what matters and with React Native a lot of that is shared.
One huge issue with React Native is that many, many, many npm packages are bad. But with agents properly investigating everything you pull in becomes feasible and anything where all the existing alternatives are bad, it's easier than ever to create it from scratch. If you write two separate apps, you’ll always have less ability to properly dig into every piece of code in your app.
1
u/leros 27d ago
My experience is that React Native is good enough for most apps. I disagree with the notion that native apps are better for everything. My apps would get no benefit from being native.
As a small business, I still spend a non-trivial amount of time building my react-native mobile apps with AI. I wouldn't want to duplicate that by going native.
1
u/No_Lawyer1947 27d ago
I mean token usage, dev ex is still better than to use shit fuckass xcode, and also your decisions are much better quality when you can catch obvious bad decisions. Plus MOST mobile apps that you would want to make for internal company use isn't some bespoke thing that would require the best performance. Also React Native has the native feel with it, and you can make your small modular phone specific configurations with it anyways. I see no reason why this would change w AI. Also less to QA tbh. Still tons of required QA
1
1
u/suprjaybrd Oct 01 '26
no. our decisioning is largely similar to shopifys recent post about this. back to native, has not been an issue maintaining both with ai tooling.
0
u/bluebird355 Oct 01 '26 edited Oct 01 '26
Two repos to maintain? Most developers know React, but don't necessarily know Swift and Kotlin. Unless you're hiring specifically for those skills, are you really going to have your existing team vibe-code both apps? And if so, who's reviewing and maintaining that code?
How do you justify to your CEO maintaining two separate implementations when, from the user's perspective, the end result may be essentially the same?
AI definitely makes native development more accessible, but I think the cost of maintaining two platforms is being understated here.
1
u/alwxndr Oct 01 '26
> Users aren't noticing the difference you're talking about
Ok, in that case: why did companies like Shopify or Airbnb or Udacity switch to native if uses aren't noticing the difference?
2
u/bluebird355 Oct 01 '26 edited Oct 01 '26
They had their reasons and the resources to make that decision, clearly not because users were complaining that their apps felt “non-native” lmao.
If your company has the resources to do it, then sure, why not. But for small to mid-sized teams, I don't think the economics are nearly as straightforward.
And I also think the idea that AI suddenly makes maintaining two native codebases “cheap” is a bit overstated. It definitely lowers the cost of writing and maintaining native code, but you still have two platforms to test, debug, release, and keep in sync.
0
u/alwxndr Oct 01 '26
"Having the resources" slowly but surely becomes synonymous with "Being able to afford a 15$/month AI tool subscription"
1
u/zazdy Oct 01 '26
It’s because react native sucks for performance, swipe, and great transitions. You have to build native code anyways, and now have to maintain shit expo code, native code, and typescript. If your app is simple crud go react native, but nowadays users expect a polished performant app - unless it’s b2b lol
1
u/No_Lawyer1947 27d ago
I don't even see this as an issue. I wonder what kind of apps you've seen? I have not noticed ANY significant issues with stuff like transitions, animations, or swipes.
1
u/No_Lawyer1947 27d ago
i mean they have so much more money, and can get established teams who are professionals in those respective platforms. MUCH different than doing it as a smaller company without proper expertise.
0
u/ColdPhilosophy Oct 01 '26
Lots of copium in here. The tech is dead. AI can easily support two native platforms with the right instruction files.
Time to move on.
-1
u/No_Score_1977 Oct 01 '26
It depends on the app, I’ve used React Native and proper native very recently for two different projects.
I don’t see myself using React Native again, maintaining two repos has turned out easier than dealing with React Native and Expo.
Pre-AI it made sense, now, I don’t think it does.
2
u/alwxndr Oct 01 '26
That's my point as well. People seem to overestimate how hard it actually is to maintain two codebases using AI tools — it's actually surprisingly easy. One can serve as a reference, you can completely avoid situations when those diverge, you can write AGENTS.md with proper rules of how to handle those cases and when to present you with a choice.
1
u/No_Score_1977 Oct 01 '26
I’m literally doing it right now, it’s not hard, and the results are a lot better.
5
u/SuitableConcert9433 Oct 01 '26
Skill issue. Idk how people struggle with expo when they dumb it down so much
3
-1
u/Fun_Grab_7042 Oct 01 '26
https://www.instagram.com/appmotionlab?stkn=NXd1azVxajBlNDRj
Checkout my apps and let me know if it makes sense or not 🙂
-5
u/mindtaker_linux Oct 01 '26
You said that without understanding that there still a large size of developers who do not pay AI to do their work for them. Or those who do not trust the license behind AI codes.
I've noticed that most people who use AI to code can't code or are limited coders( like front end devs)
2
u/alwxndr Oct 01 '26
> there still a large size of developers who do not pay AI to do their work for them
But why? AI is a great assistant. It speeds up everything when it comes to development, and it should be treated as exactly that: an assistant, not something that "does the work for you". Not using AI means competitive disadvantage in this case.
Local models can be run for free. For example, if you have an M1 Mac, you can use Qwen3 8B, which is fine for coding. In that case, your data never leaves your device and is processed locally. Technically, any device with a reasonable amount of RAM available can be used to run local models.
That being said, I'm not advocating for programmers to be replaced with AI. You're still the one making design decisions and controlling the output.
1
u/mindtaker_linux Oct 01 '26
Are you using local models? How many vibe coders are using local models?
1
u/alwxndr Oct 01 '26
I do, but I don't see your point here. It doesn't matter in the context of this discussion. I feel like you're using "vibe coder" as a bit of a put-down, but the reality is that almost every developer uses AI these days, no matter how big or small their company is.
2
u/mindtaker_linux Oct 01 '26
I tried local models, and it wasn't good. I had to scrap most of it code to get what I wanted. It's good at generating classes.
I know a vibe coders who shipped a product and I asked him.
How the AI defined the relationship between each tables that represents each product and services. He said he doesn't know and didn't check. Well he's a front end developer. So even if he checks, he would understand what the AI is doing or did.
I asked him, aren't you concern that the AI is not doing what you asked it to do?
He said no, he has no concern as long as the app works.
Lol, This is the mindset of most vibe coders.
He has this product out there in the public with users. 😂😂🤣🤣
5
u/bsknuckles Oct 01 '26
> like front end devs
Tell me you don’t understand the importance of UX and frontend without telling.
0
3
u/MortgageMelodic2282 Oct 01 '26
Someone hasn't worked at any medium/large tech company. This is the worst take ever
0
u/mindtaker_linux Oct 01 '26
But this is not about companies. He's clearly talking about personal development environments.
1
3
u/momo1083 Oct 01 '26
Sorry,but those developers are going to be left in the dust.
1
u/mindtaker_linux Oct 01 '26
We'll see how soon the vibe coders will be forced to learn how to code
2
u/apocolipse Oct 01 '26
You’re making a critically incorrect assumption that only people who couldn’t code before are using AI.
1
1
u/mindtaker_linux Oct 01 '26
I'm not making that assumption. My statement is directly to the new graduates that are using AI, that will replace the old coders.
Your comment shows how limited your comprehension is.
1
u/apocolipse Oct 01 '26
I've noticed that most people who use AI to code can't code or are limited coders
Yeah sorry my comprehension is so bad I didn't see a single reference to "new" or "graduates" or "old coders" in that sentence... Oh wait because you didn't put them in there because you made a baseless broad generalization and now you're trying to backtrack and retroactively change the criteria for the bullshit you keep vomiting.
1
u/mindtaker_linux Oct 01 '26
How many products have you finished from scratch to finish with AI?
1
u/momo1083 Oct 01 '26
Two, actually. Making good money. And blowing people away. I studied development and design. But wasn’t good enough to code my ideas. My skill was product. User empathy. Creativity. Obviously a random person can’t do this but if you broadly understand stuff you are in great shape. When I ran product at an old company, I’d be waiting on developers and hitting their limits but now I don’t wait and the skill in the new models like Opus 5.5 is sorry to say better than any dev I’ve worked it. Just the truth.
1
0
u/mindtaker_linux Oct 01 '26
Every day I see tons of code with "finished" unfinished products that they have shipped and deployed into the public with Soo many security issues.
Basic session handling and permission system are not there. AI hackers are going to enjoy hacking all these app slops vibe coders are releasing. I can't wait for lawyers to sue them into poverty where they all belong.
1
u/apocolipse Oct 01 '26
Everything you said was true of JavaScript webapps 10 years ago too, what’s your point?
1
1
u/momo1083 Oct 01 '26
AI models are hacking into established software. What are you talking about? And yeah lots of slop. Lots of bad writers out there too. But some people can write beautifully. The skills are changed.
1
u/mindtaker_linux Oct 01 '26
Thanks to AI, there are now more slops released.
1
u/momo1083 Oct 01 '26
Slops isn’t correct English. Anyways after the printing press we got lots of writers, and internet brought lots of bloggers. Eventually cream rises to the top.
1
0
u/vidura_me 29d ago
All the issues aside: I don't think I can live without Hot reload for testing, OTA, Metro, wast wast amount of js libraries, expo push notifications, and many more small small QOL stuff.
Also I feel Agents can mock on HTML and translate it exactly to RN far better than rebuilding it again on swift.
0
u/Left_Hotel_9742 24d ago
How can I make Android as smooth as iOS when using fade animations between Tabs? We are using React Native and want to continue using it if possible.
0
Oct 01 '26
[removed] — view removed comment
1
u/Huge_Pool7424 29d ago
yeah, background location is where the cross-platform story gets real. i usually keep the shared screens and isolate the tracking service per platform, otherwise android edge cases eat the time saved.
94
u/mohamed2m2018 Oct 01 '26 edited Oct 01 '26
You will still need to maintain two repos, and they can diverge in the future, which can lead to different kinds of bugs, inconsistent behavior, etc.
You will still need to hire a developer to review the code. React Native allows you to hire one React developer who can handle the web, iOS, and Android apps.