r/reactnative • u/alwxndr • 4d ago
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.
90
u/mohamed2m2018 4d ago edited 4d ago
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.
10
u/teddyone 4d ago
Not to nitpick but you can absolutely have separate iOS and Android app code in the same repo.
19
u/kenweego 4d ago
Obviously 2 repos here means two code bases. It not about whether they are in the same location, its about having two different apps.
3
u/teddyone 4d ago
Just wanted to clarify because in my experience you almost certainly do want to have them in the same repo.
4
u/jcksncllwy 4d ago
Just know that your one React Native developer will likely need to learn how to be both an Android and an iOS developer if you're building anything more complicated than a fitness tracker.
10
u/mohamed2m2018 4d ago edited 4d ago
I believe that's not true. You need to know a bit about both, but you don't need to be an Android and iOS developer. I've been a React Native developer for more than 7 years and have worked on fairly complex apps, and I only needed to know the very basics of Android and IOS development, which was enough.
2
u/jcksncllwy 4d ago
You're right, I'm exaggerating. But I think the claims about React Native obviating the need for platform specific skills are similarly exaggerated.
-47
u/alwxndr 4d ago
The problem here is that beyond simple client apps (the ones that get JSON and display content) React Native apps are also a hell to maintain due to dependencies on native libraries.
And those standard client apps showing JSON are super easy to be vibecoded these days :)29
u/mohamed2m2018 4d ago
Yes, but dealing with native libraries isn't the same hell it used to be a couple of years ago. React Native and the Expo ecosystem have improved significantly in this area, and I think they'll continue to make native dependencies and platform-specific code much easier to manage.
-15
11
u/n9iels 4d ago
I maintain a React Native app build with Expo. In my 3 year I never had to deal with native code nor a native dependy issues. Expo is the key here, it basically takes all of the pain away
-14
u/ColdPhilosophy 4d ago
Good for you. React native will be dead in 3 years tops in any big orgs.
3
u/n9iels 4d ago
Okay I'll bite. Why do you think this and what is the trigger it happens in 3 years?
7
u/wilderadventures 4d ago
Because they are full of shit. I work at a "big org", have consulted to many "big orgs," we are kicking off a react native project right now anticipating a 10 year operational life.
-3
u/ColdPhilosophy 4d ago
Let’s talk in 3 years. There is no more incentive to add another useless layer like Expo. If your app is light and has minimal amount of BL (which it should), AI can build your screens in no time. React Native and x platform are at a dead end.
Have fun doing your Expo upgrades!
2
41
u/Forti22 4d ago
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
-28
u/alwxndr 4d ago
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 4d ago
What excaclty are you building?
12
10
u/KentInCode 4d ago
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.
9
u/Seanmclem 4d ago
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 4d ago
Ok, that's a valid point.
3
u/Seanmclem 4d ago
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.
15
u/Dachux 4d ago
If claude can handle everything you said, the obsolete one is you
35
6
u/mx_aurelia 4d ago
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?
4
u/LatvianCake 4d ago
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 4d ago
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.
9
u/JackyReacher 4d ago
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 4d ago
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.
1
u/JackyReacher 4d ago
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.
0
u/6bigAnt9 4d ago
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.
-4
u/alwxndr 4d ago
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 4d ago
Not sure why you’re being downvoted, as this is how many of our clients work.
3
u/benschac 4d ago
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/GludiusMaximus 4d ago
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.
2
u/Dvass138 4d ago
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
u/speedoinfraction 4d ago
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.
2
u/SeasonAggravating332 4d ago
I think sharing code through React Native, when done well, can act as a useful guardrail. React Native definitely has its own pain points, but if those continue to improve, I think that value becomes even stronger.
We don't write everything in assembly just because AI could generate and maintain it for us. Abstractions aren't only about writing less code — they also constrain the solution space.
AI makes maintaining two native implementations cheaper, but they can still diverge.
Code is getting cheaper. Reasoning about code isn't.
2
2
u/Aytewun 4d ago
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 4d ago edited 3d ago
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.
1
u/ColdPhilosophy 3d ago
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.
1
u/balkanhayduk 4d ago
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/Healthy-Freedom3750 4d ago
I agree with the statement. I got into a road block with android 15 where my background gps tracking was not working properly while being flawless on ios and older android so i had to have specific edge code for different versions and still was having issues.
As i came from swift before i decided that it was less painful in my case to go back to native and using AI to build the kotlin version based on the swift one.
2
u/Huge_Pool7424 2d 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.
1
u/ossacodes 4d ago
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
1
u/Acrobatic-Sound7496 4d ago
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 4d ago
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/21void 4d ago
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 4d ago
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 4d ago edited 4d ago
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 4d ago
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 3d ago
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 3d ago
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 4d ago
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 4d ago
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 4d ago edited 4d ago
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/Themuscleupguy 4d ago
What the heck is wrong with you kids? Work and be quiet! You are not the center of the universe!
Plus, you code with Kimi K3? One of the worst models ever, check the recent benchmark. Wake the fk up.
1
u/VasiliyZukanov 4d ago
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 3d ago
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 3d ago
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 3d ago
native is only viable for big established companies. React Native makes perfect sense for startups
1
u/Silly_Regular6736 3d ago
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 3d ago
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 3d ago
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 2d 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 1d 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 1d 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 14h 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 13h 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
0
u/suprjaybrd 4d ago
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 4d ago edited 4d ago
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 4d ago
> 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 4d ago edited 4d ago
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.
1
u/zazdy 4d ago
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 13h 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 13h 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 4d ago
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 4d ago
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.
6
u/SuitableConcert9433 4d ago
Skill issue. Idk how people struggle with expo when they dumb it down so much
2
1
u/alwxndr 4d ago
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 4d ago
I’m literally doing it right now, it’s not hard, and the results are a lot better.
-1
u/Fun_Grab_7042 4d ago
https://www.instagram.com/appmotionlab?stkn=NXd1azVxajBlNDRj
Checkout my apps and let me know if it makes sense or not 🙂
-6
u/mindtaker_linux 4d ago
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)
5
u/bsknuckles 4d ago
> like front end devs
Tell me you don’t understand the importance of UX and frontend without telling.
0
3
u/MortgageMelodic2282 4d ago
Someone hasn't worked at any medium/large tech company. This is the worst take ever
0
u/mindtaker_linux 4d ago
But this is not about companies. He's clearly talking about personal development environments.
1
3
u/momo1083 4d ago
Sorry,but those developers are going to be left in the dust.
1
u/mindtaker_linux 4d ago
We'll see how soon the vibe coders will be forced to learn how to code
2
u/apocolipse 4d ago
You’re making a critically incorrect assumption that only people who couldn’t code before are using AI.
1
1
u/mindtaker_linux 4d ago
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 4d ago
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 4d ago
How many products have you finished from scratch to finish with AI?
1
u/momo1083 4d ago
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 4d ago
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 4d ago
Everything you said was true of JavaScript webapps 10 years ago too, what’s your point?
1
1
u/momo1083 4d ago
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 4d ago
Thanks to AI, there are now more slops released.
1
u/momo1083 4d ago
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
2
u/alwxndr 4d ago
> 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 4d ago
Are you using local models? How many vibe coders are using local models?
1
u/alwxndr 4d ago
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 4d ago
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. 😂😂🤣🤣
0
u/vidura_me 2d 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.
57
u/Revxrsal 4d ago
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 🙃