Five Years of React Native at Shopify

I agree with most of the other comments here, and it sounds like Shopify made sound tradeoffs for their business. I'm sure the people who use Shopify's apps are able to accomplish the tasks they need to.

But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.

Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.

I thought the section on the importance of native devs and how they're staffing mobile was really interesting:

"Native devs are crucial

Mobile engineers who specialize in iOS and Android are essential to building great mobile apps. There is no replacing experience and taste that comes from having built many mobile products and deeply understanding conventions and usability. Being able to drop down to the platform layer, write bindings, master build & release, distribution, etc requires native expertise.

They also play a vital role in optimizing app performance across the myriad of device models, ensuring a consistent user experience for all users. Additionally, native expertise is essential for managing React Native version updates, as well as adopting new features, APIs, and tooling changes that accompany new iOS and Android releases. You can't build a good product without these experts.

We invested in training our native mobile developers in React Native through a self-serve course that covered everything they needed to know to ship production-ready code. Additionally, we set up office hours with developers who were already proficient in React Native to provide support through Q&A sessions, pair programming, and code reviews.

We also supplemented our mobile teams with some web developers for their Javascript, Typescript, and React expertise. This ensured we had strong expertise in both native and React Native, and over time, it levelled up the entire team.

Having a good mix of native and web developers is the key to building great mobile apps using React Native in our experience. "

Blazing fast is a bold claim. I use this app nearly every day on a brand new Pixel 9 Pro and, while much improved from a few years ago, it is far from "blazing fast".

For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful. UX studies indicate 0.1s as a number where an application no longer feels instantaneous. (https://www.nngroup.com/articles/response-times-3-important-...)

Contrast this against something like the Slack app where the screen is navigating even before the pressed animation has appeared. Or for an app with probably not as much engineering focus, Fastmail, which begins the screen transition within 100ms of the pressed animation state appearance.

Which tools do they use to measure performance?

I'm surprised that there was no mention of Expo. In the past, I would say bare-metal is better than Expo-managed React Native projects because of the limitations when it came to native modules. Fast forward to today, and anything you can do in a bare metal RN app can be done with Expo.

The biggest game-changer recently is Expo's Continuous Native Generation[0]. You can configure all of your native modules and ios/android files with a simple config file (which has its limits, whereby you'll need to write an Expo Config Plugin[1]). You will no longer commit the ios/android native code to your repository, and instead let it be procedurally built.

This resolved a lot of environment issues developers would often run into, and greatly simplified onboarding new devs. You can build your iOS/Android apps through the CI with ease. And you'll no longer be afraid of upgrading React Native, as Expo will handle all of the breaking changes in the native code for you.

My guess is that Shopify started with bare metal React Native apps (which I would have done the same 5 years ago), and now migrating back to Expo-managed projects is nontrivial. At my work we only manage one app, and it was well worth migrating back.

[0] https://docs.expo.dev/workflow/continuous-native-generation/

[1] https://docs.expo.dev/config-plugins/introduction/

> Our apps are blazing fast (<500ms screen loads)

I’m not sure I would consider 0.5 seconds to be blazing fast.

I wish the article went into detail on what these screens do and what a screen load means exactly.

This strikes me as curiously defensive, in that Canadian way of praising things that are obviously problematic to draw attention to them.

The wider noise around React Native is seemingly that it works, especially while iterating on things, but it makes the final 20% of work much harder than it already was. As one person put it to me recently “with RN you just have to face the fact you won’t be winning any design awards”.

What really amazes me is how far React Native and web React have separated, to the point using the web one is a complete non event.

Glad they spent some times discussing the downsides. I’m 4 months in to a Hotwire Native replacement for an unmaintained React Native app. The differences are stark and I could definitely see myself picking up Hotwire again for another project if given the same constraints, but I’ve had good experiences with React Native in the past too. Ultimately though I just do not like all the work that has to go into maintaining a large scale React codebase.

So basically, as long as you are large enough to have direct contact with the upstream team, have a separate team to manage React Native itself, and have two separate teams for iOS and Android to manage stuff that needs native access, you are good.

> We care very deeply about performance at Shopify

> We’ve achieved sub-500ms (P75) screen loads in the Shopify app

Pick 1.

Also interesting that this deep care about performance extends to blogs, where a simple animated image showing how awesome hot reload is causing a noticeable delay in scrolling

By the way, is it Shopify’s open source policy to ignore outside PRs, or are they simply understaffed? My PR which addresses a major issue in one of Shopify’s big React Native libraries has received zero acknowledgement from Shopify for almost a year.

Heh. Still no dark mode, it's almost as embarrassing as HN not having a dark mode -- yeah I said it.

https://news.ycombinator.com/item?id=34263628

Will another 10 years go by and there still won't be a dark mode for the app?

As someone who uses the mobile app basically every day, it is absolutely one of the things that bothers me, every single time I use it. That's not a good thing.

The quality standards are so low… half a second to switch screens is ok? Jesus!

Apple just keeps making billions and billions by focusing on UX, when other ”tech” companies are satisfied with this garbage.

What would be amazing is if Swift and/or Kotlin could just be the 'native' language across both platforms and work at native speeds on both platforms.

There's also the question of the amount of footgun you give to developers. While iOS is more performant than Android, Google gives Android developers much more guidance in best practices and patterns that help developers avoid issues around architecture, injection, state and threading.

I've seen many iOS projects overwhelmed by tech debt while its Android counterpart was still OK-ish. I don't believe this is coincidence.

So how hard is it to apply React Native the correct way? Having a dedicated team of dozens of engineers including native experts for each platform is different than your average 4-8 people dev (web, API, iOS, Android) team. Let alone if you only have people experienced in web doing the work.

When I build Swift applications the fact they have sub 500ms loads is not an achievement, they're simply already doing that without me trying. But I have found the right way to build iOS apps myself over the years, very little help from Apple.

>>React is legacy technology

https://infrequently.org/2024/11/if-not-react-then-what/#fn-...

Has anyone had a success with using "React Native for Web" for a Web-first consumer site (for desktop and mobile, including heavy plain text entry at times), but also being able to use the same React Native code to go to the iOS and Android app stores (when you reluctantly also satisfy those consumers who really-really want to install native apps)?

I really wanted to work with native SwiftUI, but the lack of hot reload and long waiting times for the preview to refreshes is just painful. React Native on the contrary, delivers good enough live feedback experience. I don’t enjoy React, but compared to waiting 10 seconds for preview changes and occasional “expressions too complex, break it down to smaller one” - I’d choose React. I do still trying to code natively on every XCode updates; just with the hope of it getting better somehow.

> We’ve achieved sub-500ms (P75) screen loads

That's a difficult to interpret metric. If it's only being met 75% of the time, I'd tend to assume most features are much better than that, but some are never meeting the target, and there's no indication by how much.

I’ve noticed the app has gotten a lot slower and buggier on iOS in the last few years. Kind of wondered what they were writing it with.

I really think aside from games, media editing, and other such heavy activities, 90% of apps are, or should be, web views. What they are doing makes a lot of sense.

> Our apps are blazing fast (<500ms screen loads)

Hahaha we are absolutely cooked.

Not sure at shopify size, but I highly encourage startups to use cross platform for mobile distribution. React native's OTA update alone is already worth for fast movers.

Cannot recommend RN enough. One code base gives you three apps. Web, Android and iOS. With NativeWind, you have full Tailwind available to you and I had great success to the point where I have been thinking that I should be building customer facing web apps in RN (React Native Web + Tailwind) which at any time can be exported as native apps while already being a great web app.

Two words: Hotwire Native

They could have written a MacOS and Windows app to go along with their web app with React Native but didn't. Such a missed opportunity

Had high hopes for Shopify at beginning of pandemic but it was all hype. Online shopping is still pretty much the same and in some ways regressed.

Why is the Slashdot logo on this article? I'm so confused. What's the relationship between Shopify and Slashdot?

Personally I miss the old QT interface with plugins capabilities

> Our apps are blazing fast (<500ms screen loads)

I frequently encounter Shopify e-commerce in the wild, and it’s my most disliked experience. From browsing the stores to checkout, it always feels clunky.

I always shrugged it off as iOS bullshit but now I know the real reason. It’s just slow enough to make you doubt yourself - it’s not the website, it’s probably my shitty {phone|poor internet|computer}

So many of you are yapping about how the performance is not good enough. Yet none of you are talking about how Shopify literally could not develop their mobile app without it. The 3 minutes to compile the app just to do a trivial change makes it near impossible for devs to be productive. Hot reloading is what got me hooked to react native, I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change.