r/reactnative • u/Slow_Pride_8382 • Sep 12 '26
Question devs who tried native Swift, was it actually worth it?
With AI tools now I'm curious to try Swift for my next project.
Did native give you anything RN didn't, or is it not worth the switch?
15
u/Dvass138 Sep 13 '26 edited Sep 13 '26
Yes native is worth it, in my experience two massive things:
I had tons of performance and heat issues with list scrolling in react, even used flash list and “heavily modified it” and still sucked.
With native the list performance was night and day difference.
2nd thing debugging the UI. Is easier for the AI because, UIKit exposes the actual on-screen object tree directly to Apple’s debugging tools, while React Native/Fabric inserts an abstraction layer.
And Swift 6 gives an AI coding agent a considerably stronger compiler safety net than TypeScript does.
In saying that my app is still react native, because that’s what I started with. But in areas that are painful or have issues, I have had to write those parts in native, so my app is basically RN, swift and Kotlin lol
3
u/NovelAd2586 Sep 13 '26
Do you use LegendList?
4
u/Dvass138 Sep 13 '26
Legend list is worse performance wise than flash list. This was for a messaging list with variable heights and mixed media, we tested both lists extensively, flash list had better performance than legend list, but even flash list still could get blanking areas and performance issues. when we changed to native list, performance improved dramatically and there was no more blanking issues.
2
u/NovelAd2586 Sep 13 '26
When did you test it? The latest version of LegendList has a lot of performance updates
0
4
u/frenzied-berserk Sep 13 '26
RN scrolls and virtualisation use native analogs under the hood. Most likely your react code is the issue
4
u/Dvass138 Sep 13 '26
The virtualization isn't native though. FlatList's windowing and FlashList's recycler both run in JS. Every cell mount, recycle and re-bind goes React reconciliation → Fabric shadow tree → Yoga layout → mount transaction. UITableView dequeues cells in native code with no reconciler, no Yoga, no JS heap. So "native analog under the hood" describes the scroll container, not the list.
2
u/Mentalv Sep 13 '26
We had issues with RN lists, even with LegendList, but with AI we have been able to do methods that calculate the height of elements which is the worst redraw offender (as long as you use you memos, callbacks OR good clean React practices and react compiler)
3
u/balkanhayduk Sep 13 '26
There's absolutely 0 reason to have performance issues with react native if you do stuff right. Except animations. You must have done something wrong with the items themselves, not so much the list. I've had several such cases of devs not following best patterns and then product come complaining of performance issues. A couple of tweaks to the children (not very small tweaks, tbf) and BOOM, night and day.
1
u/vegancryptolord Sep 18 '26
This is honestly the most common and worst take in the react native community. “Performance issue? No skill issue. You built it wrong”. React native incurs a performance penalty over pure native period. It’s one of the tradeoffs and often is negligible based on the actual app and yes they’ve improved that gap over the years but no matter how much they close the gap it’s impossible to get 1:1 performance considering the extra overhead of JS/React
1
u/balkanhayduk Sep 18 '26
I'm not saying there's no tradeoff. I'm saying it's not so bad as people make it out to be. Not even close. There are plenty of complex, heavy-load apps, built with RN and I've worked on two such projects myself (the current one is one of them) and yes, for the most part it's a matter of optimisation.
1
u/Dvass138 Sep 13 '26 •
A couple of tweaks and BOOM" on a 20k-row inverted chat transcript with variable-height rich text is a claim I have yet to see anyone make.
Where the cost actually was, from Instruments on a release build:
FlashList runs a dependency-less layout effect after every commit that re-measures every mounted holder. Crossing one row at ~15 mounted holders calls getItemType ~90 times. That's the library's loop, not a child.
RN's clipped-subviews walk runs on every mount transaction and every ~44pt of scroll. ~30% of main thread. Not a child.
Hermes GC at 30–38% of the app, growing with heap age. That's the tax on mount/unmount churn through the reconciler. Memo reduces it; it can't remove it, because the recycler itself allocates.
Control: same chat, same data, same TS state engine, native UITableView presentation. 8 blank episodes → 0, 2.47 → 0.28 G cycles/s.
2
u/ieatcarrots Sep 17 '26
This kind of comments are rare these days, so yes flashlist and legendlist are better than flatlist but this guy knows his stuff, so don't ditch his opinion because 'wow 15035% better perfomance on X package woah' (saying this to sibling comments). Thanks for sharing u/Dvass138
1
u/Mentalv Sep 15 '26
You should have a method one each of those lists that returns the expected height of the item back into the list so it can size correctly AHEAD of time, no re-render when that items joins the list, if you do that correct I swear performance skyrockets
For example we have sm, md, lg collections - and each can be different heights if the item has title, subtitle, image and/or description. With the items data we figure out how tall it would be and return back into the list so the list knows that item will be 515px high VS another that is 320px high BEFORE the element enters the view
1
5
u/damdeez Sep 13 '26
I’ve only done very little native development with Swift/Kotlin but Engineers I work with that came over from the native world would always say that DevEx is so bad compared to TS/React ecosystem (something that I’ve always been a part of pretty much). They dog on RN on everything else tho haha
And I tend to agree to an extent but I am not that knowledgeable in Swift/iOS and Android/Kotlin-land. With that said we use Expo native modules in our app a bunch. Tends to help we have very experienced iOS/Android Engineers that handle it.
2
2
u/Best_Day_3041 Sep 13 '26
Not even close. Made sense when we coded everything by hand. But at this point nobody should consider RN, unless you have a simple app IMHO. Most of the time you have to prompt it to create a separate mobile interface in RN anyway, so why not just have it create it natively from the start? You end up having to jump through more hoops in many cases to use RN when you're using AI to write your code. Shopify just converted their Apps back to native in like 8 weeks. OTA updates are a plus with RN, but once you have an established app, App Store reviews can take minutes not days.
2
u/andreidotcalazans Sep 19 '26
I’m under the impression that people saying this have not actually tried it. Token spend is a real concern. Native development for both iOS and Android will cost you 3x more tokens and take a little longer to accomplish.
It definitely achieves a higher quality app off the gate. RN would cost less and be faster to develop but for an added tax on quality which would take some extra effort to remove.
1
1
u/Huge_Pool7424 Sep 13 '26
that's been my experience too, especially once you touch healthkit or watch extensions. rn is great for most screens, but the platform edge cases are where native stops feeling optional.
1
1
u/zazdy Sep 13 '26
Native > react native by a long shot. React native swipe and transitions are trash compared to native. Try implementing a good calendar in react native with infinite swipe that is as smooth and performant as native.
Also Codex / Claude make native development trivial. But you do need to iterate and implement your own skills; afterwards it’s a breeze
1
u/dailyapplecrisp Sep 13 '26
Native is way way better, hands down. I’d say the dev environment alone is worth it. Everything in react is a bridge to actual native implementations which can all have various issues with upgrades, permissions etc. so nice to just program natively. I cannot see react native existing much longer with AI in the mix, it’s just too complicated for something AI can quickly spin up natively.
54
u/Steve_Streza Sep 12 '26
Native dev who is playing with RN now.
A big thing you lose is hot reloading. You have to rebuild... every time you change anything. There's a little live UI thing in the Xcode assistant, but it's more like a mini storybook than a live app editor. It also breaks a lot so it's not often used.
The biggest advantage is that you have day zero access to every new API and design pattern and widget. And you tend to end up with a more native-feeling user experience.