Shopify is moving away from React Native and going back to separate Swift and Kotlin codebases. The wild part is that they aren't doing this because React Native failed, but because AI agents have made the "write once, run everywhere" advantage almost irrelevant. If an LLM can handle the translation and boilerplate between two native languages, the performance and UX gains of going pure native suddenly outweigh the cost of maintaining two repos.
Why bother with two codebases in 2026? #
Back in 2020, the goal was to stop building features twice and stop chasing parity. But that was before we had reliable coding agents. Now, the manual labor of mirroring a feature from iOS to Android is a solved problem for a lot of teams. When you have agents doing the implementation, testing, and code review, the "developer productivity" argument for cross-platform frameworks loses its teeth.
I've seen this happen in smaller projects too. You start with a cross-platform framework to save time, but you eventually hit a wall where you're writing "native bridges" just to get basic OS performance or specific API access. At that point, you're basically writing native code anyway, just wrapped in a layer of JavaScript that slows everything down.
What happens to the libraries? #
If you're using Shopify's open-source stuff, pay attention to the timelines. They've been huge contributors to the ecosystem, but they're cleaning house:
- react-native-skia andflash-list : These are currently looking for new homes. They're too useful to just kill, but Shopify isn't the primary driver anymore.
- restyle : This one is getting the axe. They've announced it will be archived by the end of 2026 because the user base is too small to justify the overhead.
The technical trade-off #
The move back to native usually comes down to a few specific pain points that React Native can't fully solve, regardless of how many libraries you add:
- Memory overhead : Native apps just handle resources better, especially with heavy lists or complex animations.
- Binary size : Removing the JS engine shrinks the app.
- Build times : Avoiding the Metro bundler and relying on native build pipelines often feels snappier for the dev loop once the CI is dialed in.
Next GPT-6 Astra is surprisingly good at ErdosBench math problems →
All Replies （4） #
Ugh, finally. My last RN project was a total nightmare with bridge errors. I wonder if they're using Cursor for this?
This burned me during my last app build. They didn't mention the 40% bloat in bundle size from the JS engine...
I want to try this tonight. Does this mean they're ditching the bridge entirely or just moving to KMP?