Hacker News new | past | comments | ask | show | jobs | submit

Shopify is moving from React Native back to Swift and Kotlin

https://shopify.engineering/back-to-native
loading story #49653269
We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.

Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept.

The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin.

And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.

loading story #49644807
loading story #49645135
loading story #49644571
loading story #49655560
loading story #49646151
loading story #49652697
loading story #49649566
loading story #49644616
loading story #49645459
loading story #49644576
loading story #49645136
loading story #49644829
React Native and Flutter as cross platform frameworks are best for Startups which can't handle 2 mobile developers. They can create MVPs in short time then start to looking for investors.

After the app mature enough company should decide to move native.

loading story #49653638
loading story #49645618
loading story #49651594
loading story #49643983
It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.
loading story #49651654
loading story #49652922
loading story #49654050
loading story #49651619
loading story #49646473
loading story #49651193
loading story #49644476
And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.
loading story #49646831
loading story #49653113
loading story #49655066
loading story #49655402
loading story #49644335
loading story #49655791
loading story #49648932
loading story #49647663
loading story #49655782
loading story #49644617
Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and ObjC/Java are still approachable IDK why people act like native is a big ask. I see people are in their feels already but I'm so glad so see Shopify stop carrying the RN banner, this makes giving the right advice to my clients easier.
Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead.

For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.

loading story #49650602
loading story #49647982
I was excited to hear some details about how LLMs are changing big companies' workflows. This is a fairly straightforward problem and good on them for discussing it. My first gut reaction is that there is no way I would let LLMs write a significant amount of my codebase. And then I remembered that not invented here (NIH) is a problem I have. If I let it decide what code I ship, I am making the same mistake as writing all my code from scratch. When I find myself worrying about alignment, that is what rigorous computer security policy is for. If it's not catching serious bugs written by LLMs it's not catching bugs written by people. Treating my own code as if it was written by someone else is just another part of computer programming.
loading story #49644664
loading story #49652340
loading story #49644740
loading story #49654756
loading story #49646712
loading story #49653286
loading story #49644759
loading story #49654030
loading story #49644281
loading story #49646051
loading story #49652139
loading story #49644489
loading story #49653183
loading story #49647987
loading story #49645091
loading story #49644910
loading story #49654282
I agree with this but not just React, React-Native. There's many libraries I no longer have a need for. I've made several JS 3d apps just asking the LLM to write the 3D code from scratch. AFAICT they usually shed 2meg of library and run 1.5x to 3x faster as the LLM will do the optimal thing for the situation.
loading story #49645527
loading story #49654849
loading story #49645156
loading story #49655512
loading story #49646906
loading story #49653122
loading story #49653264
loading story #49651998
> Shopify has been using LLMs to build software since 2021

Odd banter. So did anybody using GitHub copilot which was in technical preview back then?

loading story #49653478
loading story #49646825
I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
An Android developer since 2010 here.

I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.

But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?

I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.

loading story #49647648
loading story #49651570
loading story #49653146
loading story #49653020
loading story #49654196
loading story #49646793
loading story #49653536
loading story #49645099
loading story #49653609
loading story #49645104
loading story #49652988
loading story #49645348
loading story #49651029
loading story #49645433
loading story #49645495
loading story #49647708
Technology historians will pin 2026 as the year frameworks died.
loading story #49653123
loading story #49655002
It is the "why use python" for mobile.

The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.

loading story #49647174
loading story #49647128
When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.
With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams. This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.
loading story #49648033
when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.
loading story #49647634
React Native is slow.

Hermes VM doesn't even have JIT.

If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you.

Look at V8 vs. Hermes performance.

We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free

loading story #49646334
The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.

The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.

In the history books, this'll be the post indicating the end of writing code as a professional occupation.
loading story #49647488
loading story #49646477
loading story #49651585
loading story #49645944
loading story #49644860
loading story #49646951
loading story #49646537
loading story #49644362
loading story #49644369
loading story #49645632
loading story #49645948
I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.
I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?
loading story #49650573
this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).
As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move.

I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.

[1]: https://nativephp.com/blog/why-not-write-it-twice

loading story #49647600
loading story #49644301
Hey what about Flutter
Finally some common sense. Time to put electron to rest.
What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now
This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.
using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly
loading story #49644853
“We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons”

“To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.”

If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it.

“…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.”

If this was written using AI and human-edited, you missed a spot.

loading story #49645112
loading story #49644524
loading story #49645085
loading story #49646663
loading story #49654152
loading story #49650624
Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant.

React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it.

AI writes very buggy, sloppy code.

They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of.

I look forward to the 2027 version of this where they've gone back

loading story #49647667
loading story #49650035
loading story #49645855
loading story #49654268
loading story #49650449
loading story #49652435
I develop iOS and Android apps and all the apps I have in App/Play Store are native. I did try React Native a few years ago but I just didn’t like how much extra bloat I had to include as third party dependencies.

Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.

They are admitting React was a shtty choice for a mobile app if they have a choice.
loading story #49647656
loading story #49646527
If you build with electron in the age of LLMs, you should change career
I mean it sounds nice but they never say _why_. "AI removes a lot of the burden" is not a _why_. I was hoping to read about some of the shortcomings of React Native, but it seems like they're doing it just because they can. I remember Airbnb had a post about switching off of React Native years ago that actually had some solid reasoning behind it.
loading story #49652717
loading story #49645752
loading story #49645691
loading story #49646642
loading story #49644782
loading story #49650203
loading story #49644370
loading story #49645765
loading story #49645083
loading story #49650603
loading story #49653133
loading story #49647803
I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.
Can’t wait for the blog post mentioning move back to react native or other cross platform framework.
Let’s see their app size (and heap)
I guess expect no new features on mobile until their token budget gets through all the screens?
loading story #49644589
loading story #49645055
loading story #49644350
loading story #49651667
loading story #49644378
loading story #49644309
loading story #49645565
loading story #49646320
loading story #49646848
loading story #49647335
loading story #49645093
loading story #49644450
loading story #49644354
loading story #49644903
loading story #49644256
I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.
IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI
loading story #49645008
loading story #49644708
Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!
loading story #49647671
this AI stuff is goin crazy
Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?
loading story #49653265
{"deleted":true,"id":49644461,"parent":49643982,"time":1789051013,"type":"comment"}
I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it.

Talk to me in a year.

The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part.

The hard part is keeping them the same.

Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking.

Agents can write code fast but they aren't a panacea.

The load-bearing sentence in the whole post is this:

"Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity."

Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer?

You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0.

The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase?

If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two.

The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI.

That's a good idea! Do that!

But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps.

Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates.

So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible.

Maybe it is! For Shopify.

That's a much narrower claim than "AI changes the economics of cross-platform development."

And where are the numbers?

For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything?

They even say RN performance isn't the problem. "React Native apps can be fast. Ours are."

So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants.

And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes.

But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too.

Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit.

Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence.

The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc.

Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility

But it's not new, and it has very little to do with LLMs.

And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control.

None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious.

But that's exactly the point.

Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned.

Right now they've shown that AI makes rewrites cheaper.

Whoopty do.

loading story #49645444
loading story #49648808
"Native is now the future of mobile at Shopify" is a rather unfortunate title for a writeup of why you're leaving a product with "Native" in the name.
loading story #49650671
loading story #49655392
loading story #49649072
loading story #49645273
loading story #49652273
loading story #49644277
loading story #49651491
loading story #49646264
loading story #49647345
loading story #49653315
loading story #49651783
loading story #49645040
It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.
the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify
loading story #49646311