8 ms·

Migrating to React Native's new architecture

121 points by vidyesh 1y ago

mcsniff 1y ago
Still no dark mode, it's almost as embarrassing as HN not having dark mode. Yeah I said it, again. https://news.ycombinator.com/item?id=34263628 https://news.ycombinator.com/item?id=34263628 In the time it took to write this self-congratulatory post, they could have used the AI they push down everyone's throats to add dark mode to the mobile app.
- bilekas 1y ago
  I don't use Shopify so I don't know the nuances but isn't that your responsibility? Also seems a little off topic to the article ?
  - mcsniff 1y ago
    Their mobile app, that a merchant would use to manage their store, has no dark mode.
brazukadev 1y ago
A new React native architecture again?! I bet later this year we will have a new React (base) architecture change too
- HelloNurse 1y ago
  I think "TurboModules" are from the "current" new architecture (now several years old), not a new one, but I might have skipped some episodes.
- cthulberg 1y ago
  why "again"?
- frou_dh 1y ago
  Maybe it's not so new, like "modernism" in art is 100 years ago.
- sesm 1y ago
  That's why 'New Architecture' is a bad name. They should have called it 'Bridgless Architecture' or just 'V2 Architecture'. I remember how in an old ClearCase codebase we had a comment saying `New! <projectname> 4`. Version 4 was about 20 years old at that point. We kept this comment as a reminder to never use 'new' when naming or describing anything.
  - accumulator 1y ago
    Agreed. "Turbo modules" could've also been better named
- tcoff91 1y ago
  There’s literally only one time this has happened in react native and it took 8 years to finish being built and roll out completely.
mellosouls 1y ago
Perhaps it's buried in the article somewhere but I think it should highlight in the introduction what business problems were solved or improved, and what the original architecture was; essentially why this major migration was undertaken.
- kimos 1y ago
  Without knowing the answer, Shopify in general prioritizes staying on the newest version of basically everything. They deploy rails and ruby from main branch into production roughly weekly, for example. So it may just be because its current version.
  - mrbombastic 1y ago
    Can’t speak for shopify but as someone who helps maintain a fairly large react native app there is not really the option to stay on the old versions of things, react native only supports 2 major versions back, and downstream react native dependencies tend to do the same. If you don’t upgrade you are likely to find bugs when new OS versions come out that are gonna make your app close to unusable. There are benefits to the new architecture, better performance is the big one.
renegade-otter 1y ago
The problem with relying on these high-level frameworks, or heavy frameworks of any kind, is that one day they will change their entire approach to how things should be implemented, and then you have a giant pile of legacy on your hands. I learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.
- tcoff91 1y ago
  They are close to finally stabilizing the API (as much is possible given underlying platform stability). New Architecture has been in the works for 8 years. It’s such a massive upgrade over legacy architecture. Migrating our app to new architecture was not that hard tbh.
- chamomeal 1y ago
  React-router has betrayed me so many times…
  - aegypti 1y ago
    That package’s churn single handledly changed my career path during the days of react 0.x away from FE. I think it was on v2 or v3? I still feel anger hearing its name the better part of a decade later.
- sokol-alxs 1y ago
  "high-level frameworks" no different to native OS APIs. Apple/Google is constantly releasing new APIs, changing old one, deprecating, etc. The difference is only in the velocity of changes/updates.
- bokchoi 1y ago
  Ooh, I felt this one. I went through porting a webdav browser widget from ExtJS 2.1 -> 3 and then 3 -> 4. It was a nightmare. Does ExtJS still not html encode replacement values in it's templates by default?
- mardifoufs 1y ago
  So, just like regular android development? But at least with some multiplatform support? Sign me up!
xutopia 1y ago
React is a bad idea imo. I see small teams do way better with plain old HTML augmented with minimal Javascript. React itself is huge to download and slower to execute. I can't believe we're still stuck in React world.
- bnchrch 1y ago
  While you might be right. It seems like you didn't notice this was about React Native, the cross platform mobile app framework. So "just write plain html" isn't a valid alternative unless you want to write a Progressive Web App instead. Which means you: - Forego the App Store and need to ask users to bookmark your website - Loose ease of access to device features (cameras, sensors, push notifications)
  - jkmcf 1y ago
    Ruby on Rails' Hotwire Native is basically augmented "plain HTML", and requires practically zero effort for Android and iPhone support.
    - spiderice 1y ago
      How genuine are you being here? Because I've tried doing native apps using LiveView Native and it is ROUGH. The reason I ask is because I would consider using Hotwire Native for a future project if it really is good.
      - jkmcf 1y ago
        I think the devil is in the details. There are some recent Rails conference talks on YouTube about adding "native" support. https://youtube.com/watch?v=VbMt_4STWIo https://youtube.com/watch?v=VbMt_4STWIo As the other commenter said, it may not be as "native" as you'd like. I remember using the Hey app and being amazed at how well it worked (and this wasn't Hotwire Native at the time, I think) and I'm kind of sensitive to mobile apps not working as expected. I don't know anything about React Native aside from my dislike for the complexity of React and how it perverts web operability, not to mention it is epically overkill for most use cases.
afavour 1y ago
I have a lot of respect for the work the React Native folks do but at the same time the constant reinvention just highlights an inherent weakness in any framework like this: you don’t control the platform, so you’re always always at least one step behind. Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.
- sofixa 1y ago
  > Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight. But then you have double the work, in double the languages/frameworks for the two platforms.
  - JimDabell 1y ago
    It’s not double the work – native developers don’t have to do the type of work listed in the article.
  - cosmic_cheese 1y ago
    It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate. Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway. Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes. There’s also things like https://skip.tools/ https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly. All in all a lot less trouble than it might seem.
yomismoaqui 1y ago
The only constant in mobile development is churn. I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn. Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.
- wiseowise 1y ago
  [flagged]
- pjmlp 1y ago
  Unfortunely using plain HTML, CSS & vanilla JS feels like being a hipster in the age of using SPA or WebAssembly frameworks for displaying static text.
  - stronglikedan 1y ago
    > for displaying unselectable static text FTFY (but seriously, why do so many sites do that?!?)
    - wiseowise 1y ago
      Mobile experience.
      - yurishimo 1y ago
        It makes sense in some places; buttons, mostly so quickly tapping a button doesn’t zoom or whatever. I agree that a lot of people are lazy and block text selection sitewide though because it’s easy and makes the PM go away.
        ajmurmann 1y ago
        If the PM didn't even request it explicitly.
twelvedogs 1y ago
[flagged]
JimDabell 1y ago
One of the biggest arguments against using cross-platform frameworks like React Native comes from the people who use it the most. I can’t help but read articles like this and think that it’s so much unnecessary toil. It took them years to migrate to React Native, and now they have to deal with all this crap.
5cott0 1y ago
but does it still use cocoapods
- chainwax 1y ago
  Yes, but not for long. Src: https://github.com/react-native-community/discussions-and-proposals/issues/587 https://github.com/react-native-community/discussions-and-pr...
game_the0ry 1y ago
My biggest surprise is no mention of AI. I would have expected Tobi to open cursor and tell it to "migrate."
koinedad 1y ago
I’m realizing from first hand experience that there’s a lot of complexity in RN, it offers a lot of benefits but not without significant cost. Reading source code, debugging dependencies, and even working with dependency maintainers can be necessary.
tcoff91 1y ago
With the New Architecture & Expo, react native is in a great state right now and is gaining momentum. We've been able to onboard a lot of web devs onto working on our new Expo universal app at my employer and only a small subset of us need to be react-native experts. We provide a component library & other platform tools to help a bunch of web devs ship an app that works on iOS, android, and web. Over the air javascript updates are such a massive advantage over fully native apps, and expo-router now has server-driven UI via react server components.
accumulator 1y ago
Great write up. Really appreciate the work from the teams at Shopify, Expo, and countless OSS maintainers pushing the ecosystem forward. Looks like the coast is mostly clear to upgrade to the new architecture, but as a solo dev who only just made it to Expo 52 / Xcode 16, I can’t say I’m excited. With RN/Expo it often feels like a race to build features before the bottom drops out and you’re forced into another round of foundational upgrades just to keep the app building. Even with good migration tools and guides, any non-trivial app will likely hit unique challenges. I don’t think that’s on Expo or Facebook - it’s just the reality of mobile development and reflective of the way Apple and Google shape the ecosystem. Imho mobile platform churn is much worse than developing for web, and working on a mobile app makes me appreciate the web more every day.
h4ch1 1y ago
People who have used/evaluated Lynx[0], how's the DX, capabilities, etc from a developer POV; along with documentation quality? + any other thoughts? [0] https://lynxjs.org/ https://lynxjs.org/
spacebacon 1y ago
Rust is a strong pick in 2025. As a designer, I valued familiar frontend tools, but I built My Rust CMS with the RAYDT stack anyway (Rust, Axum, Yew, Diesel, Tower), which I coined. WebAssembly ensures fast performance, memory safety adds reliability, and my visual page builder streamlines editing. Still evolving, yet it’s built to last with minimal maintenance. React feels less necessary now.

121 points by vidyesh 1y ago

Still no dark mode, it's almost as embarrassing as HN not having dark mode. Yeah I said it, again. https://news.ycombinator.com/item?id=34263628 https://news.ycombinator.com/item?id=34263628 In the time it took to write this self-congratulatory post, they could have used the AI they push down everyone's throats to add dark mode to the mobile app.

bilekas 1y ago
I don't use Shopify so I don't know the nuances but isn't that your responsibility? Also seems a little off topic to the article ?
- mcsniff 1y ago
  Their mobile app, that a merchant would use to manage their store, has no dark mode.

brazukadev 1y ago

A new React native architecture again?! I bet later this year we will have a new React (base) architecture change too

HelloNurse 1y ago
I think "TurboModules" are from the "current" new architecture (now several years old), not a new one, but I might have skipped some episodes.
cthulberg 1y ago
why "again"?
frou_dh 1y ago
Maybe it's not so new, like "modernism" in art is 100 years ago.
sesm 1y ago
That's why 'New Architecture' is a bad name. They should have called it 'Bridgless Architecture' or just 'V2 Architecture'. I remember how in an old ClearCase codebase we had a comment saying `New! <projectname> 4`. Version 4 was about 20 years old at that point. We kept this comment as a reminder to never use 'new' when naming or describing anything.
- accumulator 1y ago
  Agreed. "Turbo modules" could've also been better named
tcoff91 1y ago
There’s literally only one time this has happened in react native and it took 8 years to finish being built and roll out completely.

mellosouls 1y ago

Perhaps it's buried in the article somewhere but I think it should highlight in the introduction what business problems were solved or improved, and what the original architecture was; essentially why this major migration was undertaken.

kimos 1y ago
Without knowing the answer, Shopify in general prioritizes staying on the newest version of basically everything. They deploy rails and ruby from main branch into production roughly weekly, for example. So it may just be because its current version.
- mrbombastic 1y ago
  Can’t speak for shopify but as someone who helps maintain a fairly large react native app there is not really the option to stay on the old versions of things, react native only supports 2 major versions back, and downstream react native dependencies tend to do the same. If you don’t upgrade you are likely to find bugs when new OS versions come out that are gonna make your app close to unusable. There are benefits to the new architecture, better performance is the big one.

renegade-otter 1y ago

The problem with relying on these high-level frameworks, or heavy frameworks of any kind, is that one day they will change their entire approach to how things should be implemented, and then you have a giant pile of legacy on your hands. I learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.

tcoff91 1y ago
They are close to finally stabilizing the API (as much is possible given underlying platform stability). New Architecture has been in the works for 8 years. It’s such a massive upgrade over legacy architecture. Migrating our app to new architecture was not that hard tbh.
chamomeal 1y ago
React-router has betrayed me so many times…
- aegypti 1y ago
  That package’s churn single handledly changed my career path during the days of react 0.x away from FE. I think it was on v2 or v3? I still feel anger hearing its name the better part of a decade later.
sokol-alxs 1y ago
"high-level frameworks" no different to native OS APIs. Apple/Google is constantly releasing new APIs, changing old one, deprecating, etc. The difference is only in the velocity of changes/updates.
bokchoi 1y ago
Ooh, I felt this one. I went through porting a webdav browser widget from ExtJS 2.1 -> 3 and then 3 -> 4. It was a nightmare. Does ExtJS still not html encode replacement values in it's templates by default?
mardifoufs 1y ago
So, just like regular android development? But at least with some multiplatform support? Sign me up!

xutopia 1y ago

React is a bad idea imo. I see small teams do way better with plain old HTML augmented with minimal Javascript. React itself is huge to download and slower to execute. I can't believe we're still stuck in React world.

bnchrch 1y ago
While you might be right. It seems like you didn't notice this was about React Native, the cross platform mobile app framework. So "just write plain html" isn't a valid alternative unless you want to write a Progressive Web App instead. Which means you: - Forego the App Store and need to ask users to bookmark your website - Loose ease of access to device features (cameras, sensors, push notifications)
- jkmcf 1y ago
  Ruby on Rails' Hotwire Native is basically augmented "plain HTML", and requires practically zero effort for Android and iPhone support.
  - spiderice 1y ago
    How genuine are you being here? Because I've tried doing native apps using LiveView Native and it is ROUGH. The reason I ask is because I would consider using Hotwire Native for a future project if it really is good.
    - jkmcf 1y ago
      I think the devil is in the details. There are some recent Rails conference talks on YouTube about adding "native" support. https://youtube.com/watch?v=VbMt_4STWIo https://youtube.com/watch?v=VbMt_4STWIo As the other commenter said, it may not be as "native" as you'd like. I remember using the Hey app and being amazed at how well it worked (and this wasn't Hotwire Native at the time, I think) and I'm kind of sensitive to mobile apps not working as expected. I don't know anything about React Native aside from my dislike for the complexity of React and how it perverts web operability, not to mention it is epically overkill for most use cases.

afavour 1y ago

I have a lot of respect for the work the React Native folks do but at the same time the constant reinvention just highlights an inherent weakness in any framework like this: you don’t control the platform, so you’re always always at least one step behind. Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight.

sofixa 1y ago
> Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight. But then you have double the work, in double the languages/frameworks for the two platforms.
- JimDabell 1y ago
  It’s not double the work – native developers don’t have to do the type of work listed in the article.
- cosmic_cheese 1y ago
  It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate. Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway. Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes. There’s also things like https://skip.tools/ https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly. All in all a lot less trouble than it might seem.

yomismoaqui 1y ago

The only constant in mobile development is churn. I had apps on Google Play and every year I had to upgrade libs, recompile and loose and afternoon (or two) to not win anything, just churn for the sake of churn. Compare this to plain HTML, CSS & vanilla JS. You can deploy a webapp today and if you are not using any beta JS Chrome API you will be able to use that site in 10 years without touching a line.

wiseowise 1y ago
[flagged]
pjmlp 1y ago
Unfortunely using plain HTML, CSS & vanilla JS feels like being a hipster in the age of using SPA or WebAssembly frameworks for displaying static text.
- stronglikedan 1y ago
  > for displaying unselectable static text FTFY (but seriously, why do so many sites do that?!?)
  - wiseowise 1y ago
    Mobile experience.
    - yurishimo 1y ago
      It makes sense in some places; buttons, mostly so quickly tapping a button doesn’t zoom or whatever. I agree that a lot of people are lazy and block text selection sitewide though because it’s easy and makes the PM go away.
      - ajmurmann 1y ago
        If the PM didn't even request it explicitly.

twelvedogs 1y ago

[flagged]

JimDabell 1y ago

One of the biggest arguments against using cross-platform frameworks like React Native comes from the people who use it the most. I can’t help but read articles like this and think that it’s so much unnecessary toil. It took them years to migrate to React Native, and now they have to deal with all this crap.

5cott0 1y ago

but does it still use cocoapods

chainwax 1y ago
Yes, but not for long. Src: https://github.com/react-native-community/discussions-and-proposals/issues/587 https://github.com/react-native-community/discussions-and-pr...

game_the0ry 1y ago

My biggest surprise is no mention of AI. I would have expected Tobi to open cursor and tell it to "migrate."

koinedad 1y ago

I’m realizing from first hand experience that there’s a lot of complexity in RN, it offers a lot of benefits but not without significant cost. Reading source code, debugging dependencies, and even working with dependency maintainers can be necessary.

tcoff91 1y ago

With the New Architecture & Expo, react native is in a great state right now and is gaining momentum. We've been able to onboard a lot of web devs onto working on our new Expo universal app at my employer and only a small subset of us need to be react-native experts. We provide a component library & other platform tools to help a bunch of web devs ship an app that works on iOS, android, and web. Over the air javascript updates are such a massive advantage over fully native apps, and expo-router now has server-driven UI via react server components.

accumulator 1y ago

Great write up. Really appreciate the work from the teams at Shopify, Expo, and countless OSS maintainers pushing the ecosystem forward. Looks like the coast is mostly clear to upgrade to the new architecture, but as a solo dev who only just made it to Expo 52 / Xcode 16, I can’t say I’m excited. With RN/Expo it often feels like a race to build features before the bottom drops out and you’re forced into another round of foundational upgrades just to keep the app building. Even with good migration tools and guides, any non-trivial app will likely hit unique challenges. I don’t think that’s on Expo or Facebook - it’s just the reality of mobile development and reflective of the way Apple and Google shape the ecosystem. Imho mobile platform churn is much worse than developing for web, and working on a mobile app makes me appreciate the web more every day.

h4ch1 1y ago

People who have used/evaluated Lynx[0], how's the DX, capabilities, etc from a developer POV; along with documentation quality? + any other thoughts? [0] https://lynxjs.org/ https://lynxjs.org/

spacebacon 1y ago

Rust is a strong pick in 2025. As a designer, I valued familiar frontend tools, but I built My Rust CMS with the RAYDT stack anyway (Rust, Axum, Yew, Diesel, Tower), which I coined. WebAssembly ensures fast performance, memory safety adds reliability, and my visual page builder streamlines editing. Still evolving, yet it’s built to last with minimal maintenance. React feels less necessary now.