Migrating to React Native's new architecture(shopify.engineering)
shopify.engineering
Migrating to React Native's new architecture
https://shopify.engineering/react-native-new-architecture
78 comments
Oh yeah there is nothing "better" than needing to upgrade apps a few weeks before Google Play stops accepting updates because no one thought about it or it gets postponed to the "next sprint". Google is also very bad at communicating about these changes - for example, apps now need to support 16 KB page sizes or they will stop accepting updates on 1st November but the only warning I got about this was the one on 1st September (I'm sure they talked about this sometimes in the past in some blog posts but it's impossible to read and memorize everything). But they will send an email for every little tax-related change happening in some remote island even when you don't have any paid apps! Don't forget updating React Native and all dependencies, too (there will be a lot because RN has literally no batteries included) and you will waste weeks with this because things WILL break and you WILL have to replace some dependencies. Don't get me started on Xcode and iOS.
Now compare this to Windows. You can run a Win32 program built in the 1990s, and it would work fine.
I wish that were true.
Modern windows won't even play crysis without a binary patch.
Modern windows won't even play crysis without a binary patch.
Half the 90s was DOS and Win16 which got dropped a while back. Still, I salute them for supporting backward compatibly much longer than most.
My java apps from uni days still work on windows and non-arm macs. With a little tweaking for opengl links, arm works too.
My old uni android apps still work on android last i checked. With a recompilation my ios apps work on ios too.
However, with absolutely zero work, ALL of my web stuff across all time works just like it used to even the angular 1 stuff.
It is why i love web so much. It is the ultimate distribution platform with so little needless churn.
My old uni android apps still work on android last i checked. With a recompilation my ios apps work on ios too.
However, with absolutely zero work, ALL of my web stuff across all time works just like it used to even the angular 1 stuff.
It is why i love web so much. It is the ultimate distribution platform with so little needless churn.
Can you still build your old projects? The ones developed using node6?
I do not agree on this statement at all.
I do not agree on this statement at all.
NVM is great, as long as the packages still exists, you can just switch to node6 for this one build.
Node6? You know js doesnt need node to build right? First stuff primary non-node based bundlers and script tags to libraries. I know old school.
And yet some bundles did / do run on node.
Regardless, the fragmentation you emphasize here is yet another issue why you'd probably have issue building a 10 year old project.
Regardless, the fragmentation you emphasize here is yet another issue why you'd probably have issue building a 10 year old project.
Weird, i just ran an old gulp based bundled project using bun without issues. I think there are problems with web tooling fragmentation but this argument sounds contrived as an attack the web platform. Js code from 10+ years ago runs without modification today which was the point. Tooling changes over time ofc.
Oh boy, do inhave a lot of projects I want your magic fingers to build for me since you will never have any issue just doing it on bun!
This hits too close to home.
I built an app for micro-journaling [0] in 2013. I think the iOS version stopped working in 2016, the Android version maybe a year or two after (I switched to iPhone so don't know for sure).
The interactive demo site I built in JS?
Still works exactly the same.
And I tried to make the apps as backwards compatible as possible.
Maybe AI could help make OS upgrade maintenance easier?
[0]: www.ifeelio.com
I built an app for micro-journaling [0] in 2013. I think the iOS version stopped working in 2016, the Android version maybe a year or two after (I switched to iPhone so don't know for sure).
The interactive demo site I built in JS?
Still works exactly the same.
And I tried to make the apps as backwards compatible as possible.
Maybe AI could help make OS upgrade maintenance easier?
[0]: www.ifeelio.com
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.
> for displaying unselectable static text
FTFY (but seriously, why do so many sites do that?!?)
FTFY (but seriously, why do so many sites do that?!?)
Unselectable static text is so last year. The cool new thing is these funny blue bits of text with click handlers that, when all the stars align, navigate to a different URL. Somewhere on the road map is context menu support, and the ability to open in a new tab is on the will-never-happen wishlist because no one can figure out how to do it in a cross-platform manner. Showing the target URL in a status bar didn’t even make the wish list.
The <a> tag is only for retro fanatics.
Seriously, I was peeking at the docs for Qwik, one of the cool new supposedly-lighter-weight frameworks the other day, and I was delighted to discover that, in what is obviously intended to resemble ordinary multi-page HTML, the links aren’t links. The long press behavior is utterly, comically wrong. This isn’t even unusual any more. I guess Qwik is proud that the JavaScript needed to emulate links is only 1kb minified and doesn’t add time-to-interactive overhead that scales poorly with page size, but literally every browser has had complete, native, no-script needed support for <a> even if the entire browser was a terminal app! Check it out:
https://qwik.dev/docs/getting-started/
The <a> tag is only for retro fanatics.
Seriously, I was peeking at the docs for Qwik, one of the cool new supposedly-lighter-weight frameworks the other day, and I was delighted to discover that, in what is obviously intended to resemble ordinary multi-page HTML, the links aren’t links. The long press behavior is utterly, comically wrong. This isn’t even unusual any more. I guess Qwik is proud that the JavaScript needed to emulate links is only 1kb minified and doesn’t add time-to-interactive overhead that scales poorly with page size, but literally every browser has had complete, native, no-script needed support for <a> even if the entire browser was a terminal app! Check it out:
https://qwik.dev/docs/getting-started/
Fake <a> tags are so yesterday. Everybody knows you should actually render all text on a canvas using a custom WebGL renderer for the best UX.
Wow. That is insane.
That is crazy.
Mobile experience.
SVG is the future /s
The more relevant comparison is ASP.NET where maintenance is only required to keep up with changing internet standards such as httpOnly cookies or whatever.
Server rendered HTML should be the default.
Server rendered HTML should be the default.
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.
I learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.
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.
"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.
The difference is only in the velocity of changes/updates.
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?
So, just like regular android development? But at least with some multiplatform support? Sign me up!
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.
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.
This used to be the case when the platforms were much younger and new features were introduced every year. But I would say it’s mostly stabilized now. React native had day 1 support for Liquid Glass and new AI APIs introduced on iOS 26.
> 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.
But then you have double the work, in double the languages/frameworks for the two platforms.
For a real world datapoint - my team at a FAANG invested heavily into RN over the course of years, the promoters kept touting the "only write code once!" line, and after years and years of effort in the end we managed to share only ~10% of code for any given new feature. For any given RN feature we also had to write so many APIs/hooks/setup in native code to support it that the 10% code share didn't even save us any time.
In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall.
I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.
In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall.
I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.
We're looking at moving to Expo from RN precisely to reduce the pain & risk of RN+dependency upgrades just to stay compatible.
Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
At my company we have been using react-native for years without Expo, and aside from some performance issues here or there it has mostly been great (we also use Android auto so that's my reference to "native-ish mobile").
Recently we've been trialling Expo again, and I think it has much approved from where it was a few years ago (when we went in the opposite direction). It mostly saves you time on the build side and gives you some known to work 'good' libraries to depend on, and if you want it, a file based router (we just kept using react-navigation directly, on which the router is built).
The biggest pain in react-native are the major version updates which are regularly breaking (and the lack of css grid , you'll have to make do with flex)
With Expo, that's not necessarily gone, but the updates are usually smaller compared to respective Android updates (but you still need to comply with new rules for app stores), and usually less painful because with Expo (unlike react-native directly) there's less to manually update within the platform native files which is error prone, even when you use Microsoft's upgrade tool. When you are some versions behind it was sometimes easier to bootstrap from scratch and copy over your own code.
One thing to say about Expo is that, here too, it's easier to start with a newly created app than to add expo later on, partly because Expo's docs assumed you did that.
Recently we've been trialling Expo again, and I think it has much approved from where it was a few years ago (when we went in the opposite direction). It mostly saves you time on the build side and gives you some known to work 'good' libraries to depend on, and if you want it, a file based router (we just kept using react-navigation directly, on which the router is built).
The biggest pain in react-native are the major version updates which are regularly breaking (and the lack of css grid , you'll have to make do with flex)
With Expo, that's not necessarily gone, but the updates are usually smaller compared to respective Android updates (but you still need to comply with new rules for app stores), and usually less painful because with Expo (unlike react-native directly) there's less to manually update within the platform native files which is error prone, even when you use Microsoft's upgrade tool. When you are some versions behind it was sometimes easier to bootstrap from scratch and copy over your own code.
One thing to say about Expo is that, here too, it's easier to start with a newly created app than to add expo later on, partly because Expo's docs assumed you did that.
Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
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/ 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.
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/ 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.
Double the code, but not necessarily double the work. And look at this blog post: these "write once" solutions often have the surprise of a bunch of extra work you weren't expecting.
It’s not double the work – native developers don’t have to do the type of work listed in the article.
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.
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.
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.
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.
My biggest surprise is no mention of AI.
I would have expected Tobi to open cursor and tell it to "migrate."
I would have expected Tobi to open cursor and tell it to "migrate."
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.
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.
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.
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.
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/
[0] https://lynxjs.org/
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.
A new React native architecture again?! I bet later this year we will have a new React (base) architecture change too
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.
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.
Agreed. "Turbo modules" could've also been better named
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.
Maybe it's not so new, like "modernism" in art is 100 years 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.
why "again"?
but does it still use cocoapods
Yes, but not for long.
Src: https://github.com/react-native-community/discussions-and-pr...
Src: https://github.com/react-native-community/discussions-and-pr...
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
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.
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.
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.
React's core concept was excellent. It solved many of the issues with previous view libraries. What React turned into over the years is problematic, accumulating bad design decisions until it became the monster that it is.
The way React Native works is an example of how good the original React concept still is. It has nothing to do with HTML, it's made of cross-platform view components. It has similar ergonomics as the web version, like one-way data flow, immediate-mode rendering, view as function of state.
It's true that React has passed its peak usefulness (relative to the problems it brings), in a long tail of decline for the next decade. Newer better view libraries are being created and adopted by the community. Some of them will eventually overtake React as the next standard tool. But they all learned from React's lessons, because it really did push forward the evolution of web development.
The way React Native works is an example of how good the original React concept still is. It has nothing to do with HTML, it's made of cross-platform view components. It has similar ergonomics as the web version, like one-way data flow, immediate-mode rendering, view as function of state.
It's true that React has passed its peak usefulness (relative to the problems it brings), in a long tail of decline for the next decade. Newer better view libraries are being created and adopted by the community. Some of them will eventually overtake React as the next standard tool. But they all learned from React's lessons, because it really did push forward the evolution of web development.
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)
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)
Ruby on Rails' Hotwire Native is basically augmented "plain HTML", and requires practically zero effort for Android and iPhone support.
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.
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
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.
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.
Yeah but the UI is webviews. It's not as native as React Native.
You likely mean "small projects". No way you see teams do better with plain old HTML + minimal JS on anything of substantial complexity. It was hell to organize code for a web app without a framework using nothing or jQuery.
When I use React / Next.js on Web projects, is not because I personaly like them, but because I have been part of projects using SaaS products whose SDKs are only available alongside those stacks.
Its easy to say now, if react creators knew everything that we know they would've made different choices, but at its time it was a breakthrough compared to other approaches.
I don't really see that, aside from the 1 to 2 jump, angular has been very steady and stable in their approach and and upgrades.
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.