14 ms·

Five years of React Native at Shopify

324 points by onnnon 2y ago

nadis 2y ago
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. "
- sdflhasjd 2y ago
  Probably the first "we adopted x" blog post that I can find relatable and spot-on. I think it's one of the big misconceptions that React Native is _the_ path to get your web devs or even existing code onto mobiles. That's how you get the criticism that RN builds bad, mouldy apps. Between our clients that have had this issue with quality and shops in the same space as us that haven't (one who boasts a review on one of their apps being "an example on how to build a proper fully native app"), having a good portion of native devs on the team is a big differentiator. Unfortunately this means a RN Team isn't as cheap as some hope.
  - wiseowise 2y ago
    I was listening to a podcast around 2017 (?) with AirBnb (?) devs when they were using RN and I remember they said “RN is a tool for mobile devs to not write the same app twice, not a shortcut for web devs to not learn native”.
    - JimDabell 2y ago
      Airbnb gave up on React Native just after that and wrote a series of articles about their experience: — https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
- dkkergoog 2y ago
  [dead]
- DanielHB 2y ago
  As someone who works with React Native this is definitely true. Imagine a venn diagram: Full Navive: 2 very big bubbles React Native: 2 small bubbles and one big bubble It doesn't happen very often but it can be quite annoying to implement features that need native controls on both platforms. In my case I only know native android (no ios) so when implementing native things I need to bring in an ios native dev and agree on the communication API and any platform-specific edge case before implementing stuff. It is a lot easier when I can do it all by myself and it is even harder for team members who have no native experience at all.
breckenedge 2y ago
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.
- mattgreenrocks 2y ago
  Curious what you meant by the last sentence there. Does React uniquely complicate maintenance as a codebase grows?
  - breckenedge 2y ago
    Theres a constant churn of a bunch of dependencies. Devs add minuscule libraries all the time. And I think some of the best React libraries have been abandoned, which is kinda sad, but nice from a maintenance perspective. React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve. It’s been a few years since I’ve used React Native so maybe things are better now?
    - tensor 2y ago
      This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
      - endlessvoid94 2y ago
        This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community? Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor. A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!
fidotron 2y ago
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.
- bloomingkales 2y ago
  I just kinda looked around the Shopify app to get a feel for it. There are a few frameworks that tap into native view switching (transitioning between pages and tabs), which creates most of the native feeling (along with native view components like lists/menus/switches). I don’t know why the quality of the app feels cheap, but it just feels so (the web views load in with zero ease, they just jank onto the screen. So while you have native screen transitioning, you still have this low quality feeling of a bad nypost article shitting out an ad popup on you. Hard to explain, but that’s my my general feeling). Regardless, while not impressive, it’s in this non-impressiveness that informs my unwillingness to invest into native or something like Flutter. These apps are too simple to go through the hoops. Shopify RN app is a good example of a mundane non-sexy tech decision. Overall nothing beats CSS and JavaScript for UI, but even in 2025 we cannot reliably push 60fps.
  - fidotron 2y ago
    I disagree with you on a few specifics, but I think the more general question does become what should the Shopify app be like? Non sexy is, as you say, probably the right call. For mobile apps generally I cannot recall the last time I was actually impressed by one. The reverse is often true, such as with Sonos. Individual features (again Sonos, the calibration it can do) can be neat but experiences as a whole have gone off a cliff, React Native or not.
    - deleted 2y ago
      [deleted]
treksis 2y ago
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.
zffr 2y ago
> 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.
- canucker2016 2y ago
  You'd hope they benchmarked the old native iOS app and the RN app. Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason). Looking at a previous blog post, the first hunch seems to be correct - the second may also be true. From 2024 March, https://shopify.engineering/improving-shopify-app-s-performance https://shopify.engineering/improving-shopify-app-s-performa... talks about how their RN-ified app was loading screens in 1400ms (P75) and the steps they took to reduce that to 500ms. I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
- buzzerbetrayed 2y ago
  That was my initial thought as well. Anyone know what native screen loads typically are? I’m sure it varies wildly between apps, but 500ms seems like it would be on the slower end of a “fast” app.
  - zffr 2y ago
    It really depends on what a "screen load" means exactly. If its just rendering the screen from some client-side data then I would expect something <16ms. To support 120fps displays, it would need to be <8ms. If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
  - cellularmitosis 2y ago
    For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.) Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
irskep 2y ago
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.
- fxtentacle 2y ago
  I would read the <500ms screen loads as follows: When the user clicks a button, we start a server round-trip and fetch the data and do client-side parsing, layout, formatting and rendering and then less than 500ms later, the user can see the result on his/her screen. With a worst-case ping of 200ms for a round-trip, that leaves about 200ms for DB queries and then 100ms for the GUI rendering, which is roughly what you'd expect.
  - fidotron 2y ago
    If you are good those numbers are an order of magnitude off. In truth it is probably mostly auth or something. If you simply avoid json you can radically attack these things fast. RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that), your DB calls should not be anything like 200ms (and in the event they are you need to show something else first), and 10-20ms is what you should assume for rendering budget of something very big. 60hz means 16ms per frame after all.
    - x0x0 2y ago
      > RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that) over a mobile network? My best rtt to azure or aws over tmobile or verizon is 113ms vs 13ms over my fiber conection.
tempfile 2y ago
> Our apps are blazing fast (<500ms screen loads) Hahaha we are absolutely cooked.
- verdverm 2y ago
  literally b/c the thermal effect on our phones?
- bigfatkitten 2y ago
  Load times I would've considered unsatisfactory in 2010 are "blazing fast" in 2025.
seemack 2y ago
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-limits/ 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.
- no_wizard 2y ago
  I wonder a little bit why this is slower on Android than iOS. On iOS I've never experienced this, and my phone is a couple years old now. Not saying I have the answer, but it is a curiosity
  - seemack 2y ago
    It's a good question! I've been hearing the joke for years that RN architects don't have any android devices to test on.
    - qt31415926 2y ago
      On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
    - ksec 2y ago
      Pixel 9 Pro, or virtually all android phones apart from the recent snapdragon Elite and coming ARM Cortex X5 all have much slower single threaded performance comparing to iPhone. The Google Tensor G4 in single thread and integer only is roughly in between iPhone 11 and iPhone 12. That is the performance between 2019 and 2020 on iPhone. And Tensor G4 is already on the high end Android Phones. You can quickly see how all previous and lower end android phone are much slower.
humptybumpty 2y ago
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.
- negative10xer 2y ago
  I was just showing my team this article. We'd start getting warning alerts if our P75 page load times reached 500ms. I wonder if we're measuring load times differently.
  - gf000 2y ago
    It's also their P75 target load time.
- Twirrim 2y ago
  Agreed. The web driven enshittification of everything continues. It doesn't have to be this way. It really doesn't. If what you're using makes it this way, maybe stop using it? Stop drinking the kool-aid, get over your sunk cost fallacy and start thinking about what your end user experience should be, and work backwards from there, making decisions that guarantee you hit it. Don't choose the language or tool first and leave yourself constrained to only what is possible in it.
  - eviks 2y ago
    The sunk cost fallacy in this case would've prevented the switch from native. And what's worse is they've thought about user experience, "just" set the bar for it too low
- JimDabell 2y ago
  > The quality standards are so low… Every so often they write an article talking about how great their several-years-long effort to switch to React Native is going, and every time I read it and come away with an even more negative opinion of React Native. https://news.ycombinator.com/item?id=34263896 https://news.ycombinator.com/item?id=34263896 https://www.reddit.com/r/swift/comments/1bxogd1/have_you_considered_moving_to_react_native_or/kyhfz9t/ https://www.reddit.com/r/swift/comments/1bxogd1/have_you_con...
calvinmorrison 2y ago
Personally I miss the old QT interface with plugins capabilities
prophesi 2y ago
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/ https://docs.expo.dev/workflow/continuous-native-generation/ [1] https://docs.expo.dev/config-plugins/introduction/ https://docs.expo.dev/config-plugins/introduction/
- gunian 2y ago
  What are your thoughts on Flutter vs Expo vs React Native for someone that wants to build a native app for fun?
  - EddieRingle 2y ago
    None of those will get you a "native" app, but they might get you most of the way to a cross-platform app.
    - gunian 2y ago
      fair point but coin toss it is what I'm getting they are all equally good/bad?
      - 2y ago
methods21 2y ago
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.
- te_chris 2y ago
  https://skip.tools/ https://skip.tools/ Swift can be! Saw this the other day and looks interesting
  - OccamsMirror 2y ago
    Looks interesting! Thanks for the link. Not sure I agree with this though: > first-class development environment (Xcode)
  - bsaul 2y ago
    skip is definitely what i'll be developing my next app with. I just wish swift had a better story for their wasm target.
- nyantaro1 2y ago
  I have not dived deep into it, but that seems to be the purpose of kotlin multiplatform https://www.jetbrains.com/kotlin-multiplatform/ https://www.jetbrains.com/kotlin-multiplatform/
- wiseowise 2y ago
  World of subpar development experience. Truly amazing! Shitty native toolchains that constantly need to be updated (looking at you, Xcode), dumpster fire IDEs (both Android Studio, still don’t understand how Google managed to butcher IntelliJ like that, and Xcode), half completed libraries that are either deprecated or in alpha and, for some reason, in need of constant changes. Compile times in double digits for large projects. Stay up to date with shitty Gradle if you want to have semi sane development experience on Android (maybe they’ll finally roll out declarative version this year, but they said they’re still committed to original DSLs, so good luck to poor sob who will encounter mix of Groovy and Kotlin DSL). Wonderful world of single vendor languages where only interests of vendor dictate how language evolves (just how much resources and time were wasted on horrible KMP, because JetBrains wants to grab mobile market fully). Let’s gooo!
justinko 2y ago
Two words: Hotwire Native
- grounder 2y ago
  I'll look this up later tonight. Is Hotwire using the same approach as Capacitor / Ionic?
hsavit1 2y ago
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.
- sgarland 2y ago
  And yet somehow, devs dealt with this tragedy for decades before us, cranking out software that was 100x smaller and 100x faster. Weird.
  - wiseowise 2y ago
    In what imaginary world you’re living, where basic Android app or iOS app are 100x smaller and 100x faster than RN?
    - sgarland 2y ago
      I was referring to PC programs, long before the term DX had become a thing.
- eviks 2y ago
  How did they manage to achieve the literally impossible thing for many years before this transition? > I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change. You can literally think about/edit other things while your simple border radius is being updated. No rot involved
  - hsavit1 2y ago
    this is an unserious reply. and if you are serious then you're likely not a frontend developer. often you want to test if a certain kind of hack fix works. your mind becomes glued to thinking about "does that fix it?" - hence why it's not easy to branch into a new line of thought then just come back to the change you pushed minutes ago. You're pretty much suggesting that the developer context changes into another thing for anywhere between 1 and 4 minutes and then context switches back to see if the build worked. The task that you'd be context switching into for 1-4 minutes will be interrupted by another thing and you'll likely make no progress doing it
morelish 2y ago
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.
sirjaz 2y ago
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
lvl155 2y ago
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.
nitwit005 2y ago
> 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.
mcsniff 2y ago
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 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.
- danpalmer 2y ago
  It's constantly surprising to me that this one aspect of software appearance is a hill that the industry has collectively decided to die on. We can't agree to use colours that are unambiguous for colourblind folks, we can't agree to use sufficient contrast in our UIs, we can't agree to use big enough touch targets, most companies are truly awful at accessibility... and yet everyone wants dark mode, and most companies implement it. How much time have we lost as an industry making interfaces harder to read?
  - consumer451 2y ago
    Dark mode is an accessibility feature for myself, and many others I would imagine. Calling it dark mode might not be ideal though. We should probably call it something like system theme awareness, or anything that doesn’t make the reader to think “gee, that’s not the theme I like.” Prefers-color-scheme exists. It’s not that hard. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
  - wiseowise 2y ago
    Before installing Noir on iOS, I always appreciated opening HN, or any website without dark mode, and feeling my eyes melting even on lowest brightness setting. Great and easy to read! Thanks for keeping my eyes I check!
assimpleaspossi 2y ago
>>React is legacy technology https://infrequently.org/2024/11/if-not-react-then-what/#fn-why-not-1 https://infrequently.org/2024/11/if-not-react-then-what/#fn-...
- iammrpayments 2y ago
  Thanks, I’ve been thinking about ditching react in favor of Svelte for a long time now, and this post cites enough reasons to justify it
  - wg0 2y ago
    I started with Svelte but ecosystem that React has is giant. Plus React Compiler is already being used in Instagram and Facebook so within this year, the virtual dom diffing would be a thing of past.
    - iammrpayments 2y ago
      The virtual dom is just part of the performance problem, the biggest problem in my opinion is the huge complexity that React adds, they solved part of it with useReducer and useSyncExternalStore, but I don’t think it will eventually be solved.
griomnib 2y ago
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.
neilv 2y ago
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)?
- Signez 2y ago
  Bluesky. They use Expo on top of React Native, use React Native for Web (with a desktop and mobile), and for mobile native apps. Let's note that because the clients are fully open-source and on GitHub, people from Expo and React Native are helping the little team behind the clients improve performance over time: it's not their final form!
- nwienert 2y ago
  Uniswap does this successfully. They share quite a lot of code between web and native, and their apps are open source. I made Tamagui, the library they use for sharing UI code, which goes much further than RNW in making this possible.
echelon 2y ago
Why is the Slashdot logo on this article? I'm so confused. What's the relationship between Shopify and Slashdot?
- jsheard 2y ago
  That's Shopify Balance, which also has a /. logo for some reason. No relation to Slashdot.
  - echelon 2y ago
    Ah, thanks! It's wild that they picked the same logo and the same color!
    - deleted 2y ago
      [deleted]
    - jsheard 2y ago
      Oh it's meant to be a balance board / seesaw. Duh.
qazxcvbnm 2y ago
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.
- byroot 2y ago
  There’s no policy. The person or team owning an open source repo does what they want. Some are very closely watched, some were mostly just meant as extraction and not really expecting outside contributions.
xyst 2y ago
> 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}
grandinj 2y ago
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.
wg0 2y ago
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.
dep_b 2y ago
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.
- faizmokh 2y ago
  > Google gives Android developers much more guidance in best practices and patterns that help developers avoid issues around architecture, injection, state and threading Honestly I love this. I wish Apple put some effort into this in their documentations.
adityapurwa 2y ago
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.
eviks 2y ago
> 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
rationalfaith 2y ago
[dead]
sumedh 2y ago
Which tools do they use to measure performance?
Woodi 2y ago
Nice someone from new Web circless officially confirmed that multi-langual infra is a must. And that qualified workforce is valuable too! I think "qualified" as in "works here some time and know company code base" :)
deleted 2y ago
[deleted]

324 points by onnnon 2y ago

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. "

sdflhasjd 2y ago
Probably the first "we adopted x" blog post that I can find relatable and spot-on. I think it's one of the big misconceptions that React Native is _the_ path to get your web devs or even existing code onto mobiles. That's how you get the criticism that RN builds bad, mouldy apps. Between our clients that have had this issue with quality and shops in the same space as us that haven't (one who boasts a review on one of their apps being "an example on how to build a proper fully native app"), having a good portion of native devs on the team is a big differentiator. Unfortunately this means a RN Team isn't as cheap as some hope.
- wiseowise 2y ago
  I was listening to a podcast around 2017 (?) with AirBnb (?) devs when they were using RN and I remember they said “RN is a tool for mobile devs to not write the same app twice, not a shortcut for web devs to not learn native”.
  - JimDabell 2y ago
    Airbnb gave up on React Native just after that and wrote a series of articles about their experience: — https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
dkkergoog 2y ago
[dead]
DanielHB 2y ago
As someone who works with React Native this is definitely true. Imagine a venn diagram: Full Navive: 2 very big bubbles React Native: 2 small bubbles and one big bubble It doesn't happen very often but it can be quite annoying to implement features that need native controls on both platforms. In my case I only know native android (no ios) so when implementing native things I need to bring in an ios native dev and agree on the communication API and any platform-specific edge case before implementing stuff. It is a lot easier when I can do it all by myself and it is even harder for team members who have no native experience at all.

breckenedge 2y ago

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.

mattgreenrocks 2y ago
Curious what you meant by the last sentence there. Does React uniquely complicate maintenance as a codebase grows?
- breckenedge 2y ago
  Theres a constant churn of a bunch of dependencies. Devs add minuscule libraries all the time. And I think some of the best React libraries have been abandoned, which is kinda sad, but nice from a maintenance perspective. React very much feels like programming using only side-effects and that’s not really a fun experience IMHO. Performance issues are also somewhat difficult to spot in review and not very elegant to solve. It’s been a few years since I’ve used React Native so maybe things are better now?
  - tensor 2y ago
    This is my experience with all javascript stuff these days. If you leave the codebase even for a few months now you're spending days updating it to all the new breaking library changes. Worse, if your tooling is out of date you're probably spending a week just fighting to fix/change/update the tooling. It's the most brittle tech stack I've ever had to work with.
    - endlessvoid94 2y ago
      This is the missing criteria in the technical decision making, IMO. How reliant is the team on the recruiting/retention of the current size and structure of the talent, both on the team and in the wider community? Small teams trying to keep burn ultra low vs. giant companies might have similar technical goals but opposite staff capabilities. This is a crucial factor. A second-order effect is how much time/energy/money you have to throw at maintenance. Can you afford to spend X% of your time on maintenance? Which technologies offer comparative advantages on maintenance cost? These are surprisingly often easy to answer, and nearly never explicitly considered!

fidotron 2y ago

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.

bloomingkales 2y ago
I just kinda looked around the Shopify app to get a feel for it. There are a few frameworks that tap into native view switching (transitioning between pages and tabs), which creates most of the native feeling (along with native view components like lists/menus/switches). I don’t know why the quality of the app feels cheap, but it just feels so (the web views load in with zero ease, they just jank onto the screen. So while you have native screen transitioning, you still have this low quality feeling of a bad nypost article shitting out an ad popup on you. Hard to explain, but that’s my my general feeling). Regardless, while not impressive, it’s in this non-impressiveness that informs my unwillingness to invest into native or something like Flutter. These apps are too simple to go through the hoops. Shopify RN app is a good example of a mundane non-sexy tech decision. Overall nothing beats CSS and JavaScript for UI, but even in 2025 we cannot reliably push 60fps.
- fidotron 2y ago
  I disagree with you on a few specifics, but I think the more general question does become what should the Shopify app be like? Non sexy is, as you say, probably the right call. For mobile apps generally I cannot recall the last time I was actually impressed by one. The reverse is often true, such as with Sonos. Individual features (again Sonos, the calibration it can do) can be neat but experiences as a whole have gone off a cliff, React Native or not.
  - deleted 2y ago
    [deleted]

treksis 2y ago

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.

zffr 2y ago

> 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.

canucker2016 2y ago
You'd hope they benchmarked the old native iOS app and the RN app. Since the blog post doesn't mention previous native-only perf, I'd assume they didn't compare or the RN version isn't close to native-only perf (leaning heavily towards the second reason). Looking at a previous blog post, the first hunch seems to be correct - the second may also be true. From 2024 March, https://shopify.engineering/improving-shopify-app-s-performance https://shopify.engineering/improving-shopify-app-s-performa... talks about how their RN-ified app was loading screens in 1400ms (P75) and the steps they took to reduce that to 500ms. I hope they benchmark their load-screen time with every release/CD to stay on top of any regressions, otherwise, there'll be more mad scrambles when the perf debt piles up too high.
buzzerbetrayed 2y ago
That was my initial thought as well. Anyone know what native screen loads typically are? I’m sure it varies wildly between apps, but 500ms seems like it would be on the slower end of a “fast” app.
- zffr 2y ago
  It really depends on what a "screen load" means exactly. If its just rendering the screen from some client-side data then I would expect something <16ms. To support 120fps displays, it would need to be <8ms. If a "screen load" includes making a network request to fetch data, then this is a very weird metric to include in a post about React Native. Most of that time budget should just be waiting for the request to complete. Just as before, it should take <16ms to render the screen once the data arrives.
- cellularmitosis 2y ago
  For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.) Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).

irskep 2y ago

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.

fxtentacle 2y ago
I would read the <500ms screen loads as follows: When the user clicks a button, we start a server round-trip and fetch the data and do client-side parsing, layout, formatting and rendering and then less than 500ms later, the user can see the result on his/her screen. With a worst-case ping of 200ms for a round-trip, that leaves about 200ms for DB queries and then 100ms for the GUI rendering, which is roughly what you'd expect.
- fidotron 2y ago
  If you are good those numbers are an order of magnitude off. In truth it is probably mostly auth or something. If you simply avoid json you can radically attack these things fast. RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that), your DB calls should not be anything like 200ms (and in the event they are you need to show something else first), and 10-20ms is what you should assume for rendering budget of something very big. 60hz means 16ms per frame after all.
  - x0x0 2y ago
    > RTT to nearest major metro DC should be up to 20ms (where I am it is less than half that) over a mobile network? My best rtt to azure or aws over tmobile or verizon is 113ms vs 13ms over my fiber conection.

tempfile 2y ago

> Our apps are blazing fast (<500ms screen loads) Hahaha we are absolutely cooked.

verdverm 2y ago
literally b/c the thermal effect on our phones?
bigfatkitten 2y ago
Load times I would've considered unsatisfactory in 2010 are "blazing fast" in 2025.

seemack 2y ago

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-limits/ 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.

no_wizard 2y ago
I wonder a little bit why this is slower on Android than iOS. On iOS I've never experienced this, and my phone is a couple years old now. Not saying I have the answer, but it is a curiosity
- seemack 2y ago
  It's a good question! I've been hearing the joke for years that RN architects don't have any android devices to test on.
  - qt31415926 2y ago
    On our apps we consistently see a p50 3-4x speed difference between iOS and Android (though there are more lower end android devices). Hard to fathom if it's all due to variability in android devices vs RN being less performant on Android.
  - ksec 2y ago
    Pixel 9 Pro, or virtually all android phones apart from the recent snapdragon Elite and coming ARM Cortex X5 all have much slower single threaded performance comparing to iPhone. The Google Tensor G4 in single thread and integer only is roughly in between iPhone 11 and iPhone 12. That is the performance between 2019 and 2020 on iPhone. And Tensor G4 is already on the high end Android Phones. You can quickly see how all previous and lower end android phone are much slower.

humptybumpty 2y ago

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.

negative10xer 2y ago
I was just showing my team this article. We'd start getting warning alerts if our P75 page load times reached 500ms. I wonder if we're measuring load times differently.
- gf000 2y ago
  It's also their P75 target load time.
Twirrim 2y ago
Agreed. The web driven enshittification of everything continues. It doesn't have to be this way. It really doesn't. If what you're using makes it this way, maybe stop using it? Stop drinking the kool-aid, get over your sunk cost fallacy and start thinking about what your end user experience should be, and work backwards from there, making decisions that guarantee you hit it. Don't choose the language or tool first and leave yourself constrained to only what is possible in it.
- eviks 2y ago
  The sunk cost fallacy in this case would've prevented the switch from native. And what's worse is they've thought about user experience, "just" set the bar for it too low
JimDabell 2y ago
> The quality standards are so low… Every so often they write an article talking about how great their several-years-long effort to switch to React Native is going, and every time I read it and come away with an even more negative opinion of React Native. https://news.ycombinator.com/item?id=34263896 https://news.ycombinator.com/item?id=34263896 https://www.reddit.com/r/swift/comments/1bxogd1/have_you_considered_moving_to_react_native_or/kyhfz9t/ https://www.reddit.com/r/swift/comments/1bxogd1/have_you_con...

calvinmorrison 2y ago

Personally I miss the old QT interface with plugins capabilities

prophesi 2y ago

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/ https://docs.expo.dev/workflow/continuous-native-generation/ [1] https://docs.expo.dev/config-plugins/introduction/ https://docs.expo.dev/config-plugins/introduction/

gunian 2y ago
What are your thoughts on Flutter vs Expo vs React Native for someone that wants to build a native app for fun?
- EddieRingle 2y ago
  None of those will get you a "native" app, but they might get you most of the way to a cross-platform app.
  - gunian 2y ago
    fair point but coin toss it is what I'm getting they are all equally good/bad?
    - 2y ago

methods21 2y ago

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.

te_chris 2y ago
https://skip.tools/ https://skip.tools/ Swift can be! Saw this the other day and looks interesting
- OccamsMirror 2y ago
  Looks interesting! Thanks for the link. Not sure I agree with this though: > first-class development environment (Xcode)
- bsaul 2y ago
  skip is definitely what i'll be developing my next app with. I just wish swift had a better story for their wasm target.
nyantaro1 2y ago
I have not dived deep into it, but that seems to be the purpose of kotlin multiplatform https://www.jetbrains.com/kotlin-multiplatform/ https://www.jetbrains.com/kotlin-multiplatform/
wiseowise 2y ago
World of subpar development experience. Truly amazing! Shitty native toolchains that constantly need to be updated (looking at you, Xcode), dumpster fire IDEs (both Android Studio, still don’t understand how Google managed to butcher IntelliJ like that, and Xcode), half completed libraries that are either deprecated or in alpha and, for some reason, in need of constant changes. Compile times in double digits for large projects. Stay up to date with shitty Gradle if you want to have semi sane development experience on Android (maybe they’ll finally roll out declarative version this year, but they said they’re still committed to original DSLs, so good luck to poor sob who will encounter mix of Groovy and Kotlin DSL). Wonderful world of single vendor languages where only interests of vendor dictate how language evolves (just how much resources and time were wasted on horrible KMP, because JetBrains wants to grab mobile market fully). Let’s gooo!

justinko 2y ago

Two words: Hotwire Native

grounder 2y ago
I'll look this up later tonight. Is Hotwire using the same approach as Capacitor / Ionic?

hsavit1 2y ago

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.

sgarland 2y ago
And yet somehow, devs dealt with this tragedy for decades before us, cranking out software that was 100x smaller and 100x faster. Weird.
- wiseowise 2y ago
  In what imaginary world you’re living, where basic Android app or iOS app are 100x smaller and 100x faster than RN?
  - sgarland 2y ago
    I was referring to PC programs, long before the term DX had become a thing.
eviks 2y ago
How did they manage to achieve the literally impossible thing for many years before this transition? > I literally cannot allow for my brain to rot waiting for minutes waiting for Xcode to compile for a simple border radius change. You can literally think about/edit other things while your simple border radius is being updated. No rot involved
- hsavit1 2y ago
  this is an unserious reply. and if you are serious then you're likely not a frontend developer. often you want to test if a certain kind of hack fix works. your mind becomes glued to thinking about "does that fix it?" - hence why it's not easy to branch into a new line of thought then just come back to the change you pushed minutes ago. You're pretty much suggesting that the developer context changes into another thing for anywhere between 1 and 4 minutes and then context switches back to see if the build worked. The task that you'd be context switching into for 1-4 minutes will be interrupted by another thing and you'll likely make no progress doing it

morelish 2y ago

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.

sirjaz 2y ago

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

lvl155 2y ago

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.

nitwit005 2y ago

> 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.

mcsniff 2y ago

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 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.

danpalmer 2y ago
It's constantly surprising to me that this one aspect of software appearance is a hill that the industry has collectively decided to die on. We can't agree to use colours that are unambiguous for colourblind folks, we can't agree to use sufficient contrast in our UIs, we can't agree to use big enough touch targets, most companies are truly awful at accessibility... and yet everyone wants dark mode, and most companies implement it. How much time have we lost as an industry making interfaces harder to read?
- consumer451 2y ago
  Dark mode is an accessibility feature for myself, and many others I would imagine. Calling it dark mode might not be ideal though. We should probably call it something like system theme awareness, or anything that doesn’t make the reader to think “gee, that’s not the theme I like.” Prefers-color-scheme exists. It’s not that hard. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
- wiseowise 2y ago
  Before installing Noir on iOS, I always appreciated opening HN, or any website without dark mode, and feeling my eyes melting even on lowest brightness setting. Great and easy to read! Thanks for keeping my eyes I check!

assimpleaspossi 2y ago

>>React is legacy technology https://infrequently.org/2024/11/if-not-react-then-what/#fn-why-not-1 https://infrequently.org/2024/11/if-not-react-then-what/#fn-...

iammrpayments 2y ago
Thanks, I’ve been thinking about ditching react in favor of Svelte for a long time now, and this post cites enough reasons to justify it
- wg0 2y ago
  I started with Svelte but ecosystem that React has is giant. Plus React Compiler is already being used in Instagram and Facebook so within this year, the virtual dom diffing would be a thing of past.
  - iammrpayments 2y ago
    The virtual dom is just part of the performance problem, the biggest problem in my opinion is the huge complexity that React adds, they solved part of it with useReducer and useSyncExternalStore, but I don’t think it will eventually be solved.

griomnib 2y ago

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.

neilv 2y ago

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)?

Signez 2y ago
Bluesky. They use Expo on top of React Native, use React Native for Web (with a desktop and mobile), and for mobile native apps. Let's note that because the clients are fully open-source and on GitHub, people from Expo and React Native are helping the little team behind the clients improve performance over time: it's not their final form!
nwienert 2y ago
Uniswap does this successfully. They share quite a lot of code between web and native, and their apps are open source. I made Tamagui, the library they use for sharing UI code, which goes much further than RNW in making this possible.

echelon 2y ago

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

jsheard 2y ago
That's Shopify Balance, which also has a /. logo for some reason. No relation to Slashdot.
- echelon 2y ago
  Ah, thanks! It's wild that they picked the same logo and the same color!
  - deleted 2y ago
    [deleted]
  - jsheard 2y ago
    Oh it's meant to be a balance board / seesaw. Duh.

qazxcvbnm 2y ago

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.

byroot 2y ago
There’s no policy. The person or team owning an open source repo does what they want. Some are very closely watched, some were mostly just meant as extraction and not really expecting outside contributions.

xyst 2y ago

> 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}

grandinj 2y ago

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.

wg0 2y ago

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.

dep_b 2y ago

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.

faizmokh 2y ago
> Google gives Android developers much more guidance in best practices and patterns that help developers avoid issues around architecture, injection, state and threading Honestly I love this. I wish Apple put some effort into this in their documentations.

adityapurwa 2y ago

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.

eviks 2y ago

> 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

rationalfaith 2y ago

[dead]

sumedh 2y ago

Which tools do they use to measure performance?

Woodi 2y ago

Nice someone from new Web circless officially confirmed that multi-langual infra is a must. And that qualified workforce is valuable too! I think "qualified" as in "works here some time and know company code base" :)

deleted 2y ago

[deleted]