Migrating to React Native's New Architecture
Posted4 months agoActive3 months ago
shopify.engineeringTechstoryHigh profile
controversialmixed
Debate
80/100
React NativeMobile DevelopmentCross-Platform Frameworks
Key topics
React Native
Mobile Development
Cross-Platform Frameworks
Shopify's engineering team shares their experience migrating to React Native's new architecture, sparking a discussion about the trade-offs and challenges of using cross-platform frameworks.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4d
Peak period
58
Day 4
Avg / period
19
Comment distribution76 data points
Loading chart...
Based on 76 loaded comments
Key moments
- 01Story posted
Sep 12, 2025 at 2:41 PM EDT
4 months ago
Step 01 - 02First comment
Sep 16, 2025 at 7:51 AM EDT
4d after posting
Step 02 - 03Peak activity
58 comments in Day 4
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 23, 2025 at 9:58 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45225217Type: storyLast synced: 11/20/2025, 6:56:52 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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 learned that lesson the hard way with ExtJS 3 => 4, and now my wife claims I have commitment issues.
I still feel anger hearing its name the better part of a decade later.
The difference is only in the velocity of changes/updates.
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)
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.
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.
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.
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.
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.
It’s night and day compared to using RN directly
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.
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.
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.
FTFY (but seriously, why do so many sites do that?!?)
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.
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/
Modern windows won't even play crysis without a binary patch.
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.
I do not agree on this statement at all.
Regardless, the fragmentation you emphasize here is yet another issue why you'd probably have issue building a 10 year old project.
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
Server rendered HTML should be the default.
Src: https://github.com/react-native-community/discussions-and-pr...
I would have expected Tobi to open cursor and tell it to "migrate."
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.
[0] https://lynxjs.org/