Numbers from GPT Astra
- Shopify has 3000 engineers as of 2026
- Google Chrome when released in 2008 conservatively had ~ 60 engineers.
- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
sashank_1509
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.
2021-11-08: https://shopify.engineering/high-performance-hydrogen-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and creative storefronts powered by Shopify’s platform and APIs.")
2025-01-13: https://shopify.engineering/five-years-of-react-native-at-sh... ("React Native has come a long way in the last 5 years and a lot of limitations that led people to not adopt it simply don’t exist anymore. If you haven’t tried using RN in a while, now would be a good time to revisit it.")
2026-09-10: https://shopify.engineering/back-to-native ("React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.")
^ to show the timeline of things.
vietthan
I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.
I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.
For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.
All to say that this decision is worth considering without even taking LLM assistance into account.
netshade
As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
hectdev
We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.
What we found led us back to native.
fnthawar2
That Shopify employs 3,000 engineers is astounding.
I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.
I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist.
So maybe that tells you something.
keithcarolus
Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
tonic_note
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.
ernsheong
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.
comments (10)
- Google Chrome when released in 2008 conservatively had ~ 60 engineers.
- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
sashank_1509
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.
atonse
2021-11-08: https://shopify.engineering/high-performance-hydrogen-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and creative storefronts powered by Shopify’s platform and APIs.")
2025-01-13: https://shopify.engineering/five-years-of-react-native-at-sh... ("React Native has come a long way in the last 5 years and a lot of limitations that led people to not adopt it simply don’t exist anymore. If you haven’t tried using RN in a while, now would be a good time to revisit it.")
2025-09-05: https://shopify.engineering/react-native-new-architecture ("We successfully migrated two of our largest apps, Shopify Mobile and Shopify Point of Sale (POS) to React Native's New Architecture")
2026-09-10: https://shopify.engineering/back-to-native ("React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.")
^ to show the timeline of things.
vietthan
I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.
For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.
All to say that this decision is worth considering without even taking LLM assistance into account.
netshade
hectdev
What we found led us back to native.
fnthawar2
I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.
I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist.
So maybe that tells you something.
keithcarolus
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
tonic_note
ernsheong
underdeserver