10 ms·

Migrating our largest mobile app to React Native

94 points by cpeterso 4y ago

deleted 4y ago
[deleted]
h4waii 4y ago
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.
- ageektrapped 4y ago
  Former Shopify iOS dev here. I pushed SO HARD to get dark mode to be a thing we would do. It's table stakes, IMO, in 2020 and beyond, to support it. We'd get roasted on Twitter, LinkedIn, just about everywhere. HN Comments, even. :) Got shut down at the highest level. Like, definitively. As in, please don't ask again. I don't think you'll ever see it as long as Tobi is CEO.
  - kayson 4y ago
    What was the rationale?
    - ageektrapped 4y ago
      IIRC, something about opportunity cost or maintenance burden.
      - secretsatan 4y ago
        There is virtually no maintenance burden if set up correctly, not shouting, i had to demonstrate the fact
  - nprateem 4y ago
    I'm sure it's only a vocal minority that care
    - secretsatan 4y ago
      It’s so ridiculously easy to support though, and i may be a minority, but none of our users ever complain about it being there
      - mrbombastic 4y ago
        Ehh ridiculously easy seems like a stretch. You need to adapt all of your designs for dark mode and if you haven’t thought about it in the past or you don’t have a design system that is easily adaptable in the app you are going to be updating a lot of components and screens.
        secretsatan 4y ago
        OK, yeah, you need to think about it first, but it should just be a case that all the colours in your design have alternates. It's mostly a case of differentiating between background and foreground colours. Then you put all your colours in the Assets, only ever used named colours, maybe hardcode some shortcuts, then you never think about it again. There are a couple of rare cases here and there, eg custom drawing using Core Graphics, where using cgColor won't pick up the change, you have to grab the underlying colour again and force a redraw
    - darren_ 4y ago
      I’ve seen arguments that dark mode is important for accessibility, which seems reasonable to me, and depending on the company might be a dealbreaker.
  - secretsatan 4y ago
    Ugh, i got a bit of pushback on supporting dark mode in my native app, luckily i was starting from scratch and once you show you can pretty much do it by setting up assets correctly and that you can switch modes from the quick menu to test, noone even thinks about it anymore. They were all coming from a non native mindset though
- lawgimenez 4y ago
  If anyone starts a new SwiftUI project, dark mode support is automatic.
koch 4y ago
> Making Improvements As We Go > As we port screens to RN, we also look out for opportunities to improve the UX of the app. I would be curious to hear more about how this went - in my experience trying to do two things at the same time can lead to trouble, tempting as it may be (was it the migration or the upgrade we did along the way that caused this new bug?).
- mrbombastic 4y ago
  Agreed, you are almost always better off resisting that urge and taking note of things that should be improved as you go, otherwise scope balloons out of control.
- corytheboyd 4y ago
  Having done this, it goes poorly. You create new problems as you go because somehow, to the surprise of everyone, brand new ideas are less fleshed out than vetted ideas. Shocking.
- hrpnk 4y ago
  Making technical and functional changes results in an inability to explain A/B tests that attempt to prove that the migration did not have negative effects. If you change UX as part of the migration, you're often unable to tell whether the cause was technical or functional. It's just too easy to say that it must be the technical side, but you don't have tangible data unless you actually compare the functional changes built on top of the same technical foundation. Another aspect are behavioral metrics that may change between two implementations making these difficult to compare.
meisel 4y ago
How did Shopify choose between React Native and Flutter?
- jitl 4y ago
  Flutter isn’t native, React Native is.
  - JimDabell 4y ago
    React Native isn’t native. It uses native UI components, but the application code is still just interpreted JavaScript, not a native application. https://reactnative.dev/docs/javascript-environment https://reactnative.dev/docs/javascript-environment
    - jitl 4y ago
      Yes, but you can write and integrate the platform APIs for UO components. You can’t do that in flutter.
      - kayson 4y ago
        UO components?
        jitl 4y ago
        UI, oops
      - chadrickman 4y ago
        Platform channels - https://docs.flutter.dev/development/platform-integration/platform-channels https://docs.flutter.dev/development/platform-integration/pl...
      - lawgimenez 4y ago
        Flutter compiles code to native and RN uses JavaScript as a bridge to communicate.
JimDabell 4y ago
They announced they were moving to React Native three years ago. Since then, they’ve set up a mobile enablement team, they’ve set up an internal training programme, and they’ve ported four out of three hundred screens [edit: see discussion below]. They are choosing to do it gradually because their estimate for a rewrite was three years. They are choosing not to go with the “new features in React Native” approach because their estimate for that was four to five years. They seem really happy with their “We all get shit done, ship fast, and learn” progress, but I’m sure I’m not the only one reading this article and coming away less likely to choose to migrate to React Native, right? This does not sound compelling at all.
- tsss 4y ago
  Irrespective of this blog post, that is probably a good take away.
  - sabellito 4y ago
    Why?
- trevor-e 4y ago
  Where do you see they only ported four screens? In the dashboard screenshot it clearly shows "RN Screen Count: 139/572", so they've ported 139 screens, right? The "four" figure you're referring to is the root navigation screens of the app which get a lot more traffic, hence why they prioritized those to uncover issues.
  - JimDabell 4y ago
    This is what I was referring to: > Where We Are Now > Here’s a spoiler: Today, if you open the Shopify Mobile app, all four root screens are in React Native already! If you write “where we are now: we’ve ported all four root screens”, that’s what I’m going to hear. I’m not going to look through screenshots for contradictory figures. If they have actually ported 139 screens, maybe they should have said “where we are now: we’ve ported 139 screens”? As far as I can see they don’t say anything like that at all, are you inferring from screenshots alone? Regardless, my point still stands – if you need to set up a training programme and a facilitation team and it’s going to be a multi-year effort, and after all that you proudly tell people that they can’t tell the difference between the old version and the new version… this still does not sound compelling at all, even if you have got almost a quarter of the way through the project in three years.
smith7018 4y ago
So after three years, they've ported "all four root screens" in React Native? I can't fathom how broken each of their platform's codebases must have been to require everyone to learn a whole new paradigm to start over from scratch. Further more, they are presumably causing the same code quality issues because "React Native was a completely new tech stack for [their engineers]." So the codebases were so broken that they had to rewrite them and they chose a system that most of them are learning as they go. Love it lmaoo
- hooksfordays 4y ago
  As someone who worked on the Shopify iOS and Android codebases, I would argue they weren’t all necessarily so broken. The flagship mobile app (the one primarily discussed in the article) was in good shape on iOS (and arguably better shape on Android). There was some fragmentation in architecture among teams, but overall things were reasonable and I didn’t personally find it difficult to jump into unfamiliar sections of the codebase.. Shopify’s other apps that migrated first were either much older, and therefore had much more tech debt, making the rewrite more enticing, or were much smaller in scope, making the rewrite much faster to get to feature parity. Once all the other apps had migrated or decided to migrate, it made a lot more sense to explore it in the flagship app discussed here. Some disclaimers, I’m no longer at Shopify, and while I worked in the very early iterations of the port of the flagship app, I wasn’t necessarily a vocal proponent of migrating it to RN. I enjoy RN, but I enjoyed working on the native Shopify apps.
- ageektrapped 4y ago
  The choice to port to RN wasn't technical at all. Tobi (the CEO) prefers RN philosophically. No technical argument opposed to RN--which is super easy to come up with, along several axes--would have stopped the port. It was inevitable. This is my opinion, as I watched it unfold. I'm no longer at Shopify.
  - weego 4y ago
    If he's willing to have the business fund it long term then fair enough honestly. But it seems like a weak strategy that isn't playing out well judging by the progress made over the 3 years so far.
hrpnk 4y ago
The migration tracker is nice. Highly recommended approach for any migration project, incl. data migrations. It not only helps track the progress over time, but also provides great material for status updates. It's a perfect place to redirect stakeholders who have questions on the status or to help reduce their anxiety around progress.
Grim-444 4y ago
Well I give them props for at least having a facade of a "what went wrong" section, which most RN articles leave out, although it doesn't feel like an honest analysis of the negatives of their switch. I'd like to see some actual data about what percentage of their code is written in native vs RN. In my experience you need to maintain massive amounts of native framework code on both sides to support the RN code, and to implement stuff that RN can't do or does horribly. Adding RN into the mix just basically adds one more platform to be supported, making things more complicated, rather than combining code into fewer platforms. RN teams never bother to mention how much native code is needed to support them, and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned. Also curious about other metrics such as how many developers they lost that weren't interested in becoming JS developers. Or have they stuck around because there's still so much native work that they need native developers for, to support RN.
- brundolf 4y ago
  Anecdotally we've got a RN app, and we've only got one or two native source files for each platform, which are mostly there to bridge in third-party libraries for things like analytics. Our UI and business logic are almost 100% JS and it works out really nicely for us Of course this is a mostly standard (but not small) CRUD app. We've got some custom animations/widgets here and there, but mostly it's vanilla forms, controls, views, etc. which translate easily to both platforms We also started out on RN from the beginning; it's possible that migrating to it from native code is a much bigger challenge
  - chenxi9649 4y ago
    Same for us. Certain dev environments bugs were been a big pain in the ass for us in the past. For the logic side of thing React Native has been a nice experience for us as well!
- 59nadir 4y ago
  > [...] and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned. In this case it seems like they transitioned a mostly native mobile workforce into React Native, so I don't know that the last bit makes much sense here. I agree with you that there is a general absence of information about how they still deal with the native side of everything with React Native becoming more and more important in their apps. Even just the "yet-to-be-transitioned-but-we-need-to-use-it" kind of stuff would've been more interesting to learn about and certainly "What native stuff remained in sections that were ported?" seems reasonable as well.
null_object 4y ago
Where I'm working we're porting the native apps gradually to SwiftUI on iOS and on Android using Kotlin Compose - addressing a lot of the development speed issues mentioned in the article, and shifting to a 'reactive' model while retaining truly native performance and components. Developing in SwiftUI is lightning-fast - there are a few bumps and bugs that have been extensively discussed, but it's really simple to still use UIKit components in the places that need them (which are becoming fewer all the time). For me the tone of the article is very 'positive' but the amount of time and effort seem horrendous. And now they're stuck with React. Not sure how many times these articles need to be written and then... [0] [0] https://www.twopicode.com/articles/this-is-why-we-stopped-using-react-native/ https://www.twopicode.com/articles/this-is-why-we-stopped-us...
- zyang 4y ago
  I think you made the right call here. SwiftUI had a slow start but now closing the gap on UIKit. ReactNative is a dead end.
  - nodemaker 4y ago
    As a former iOS UIKit dev I actually prefer react native to SwiftUI. If we have to do this declaratively (and I have to re-learn how to do complex layouts) lets also make it platform independent and reusable with Web. It feels like SwiftUI is being pushed down my throat and I have a strong aversion towards things like that.
    - danpalmer 4y ago
      Has sharing between the web and RN worked out for you? It seems like it hasn’t for many, or any high profile apps. Even mobile web and non-web mobile are quite different platforms, even at the UI layer. There are many different expectations, platform norms, and interaction differences that don’t work well in browsers or across platforms. I’d love to seen an example of it working well but I haven’t yet.
      - 4y ago
pen2l 4y ago
The scrolling/transitions animations are jittery in the left in the video, it’s a readily identifiable artifact of RN apps in fact, whereas the native one is incredibly smooth in all refresh transitions and scrolls. I wonder how difficult it is for RN to fix this. Just this one singular improvement in UX would be worth its weight in gold.
- helsontaveras18 4y ago
  Why is this being down voted? Upon re-watching the video, I did notice a visible stutter in scrolling the app on the left. (To be fair, I didn't notice it the first time I watched the video.)
- danielrhodes 4y ago
  This is where things get interesting in React Native. The answer is: yes you can have smooth animations. However, the animations have to be driven at the native level and not in JS. The reason for this is: React Native is on a run loop. And on each loop, new state is shared over a bus from the JS side to the native side. So if you manage the frames of an animation over this bus, it's going to be very slow. If the native side manages the animation, you don't have this overhead. The same goes for touches. If you touch something, the native side gets the event and then this goes over the bus and RN picks it up. But if RN then responds to that touch by highlighting a view, that means another message has to go back to native - lots of overhead. For that to happen without a perceptible delay you have to have these events handled on the native side. Another thing that can happen is too many things in the view change at once: you then have a traffic jam on the bus and the UI slows down or becomes unresponsive. This can happen if state changes too quickly. You can get decent performance out of React Native (especially on tables, which is otherwise a dark art in iOS), but you have to know where the bottlenecks pop up.
  - siquick 4y ago
    This is some great insight that should be highlighted in the RN docs.
- ricardobeat 4y ago
pier25 4y ago
I would love to see their test using a regular Android device, not a high end iPhone. Android has like 90%? worldwide market share and most phones are way underpowered vs even old iPhones. Picking a solution that only works well for SV users is a terrible decision.
- brundolf 4y ago
  RN uses native controls (not a webview) and JS is plenty fast for most UI logic (it's almost never the bottleneck on slow web apps), so I would not expect performance to be a problem here
  - pier25 4y ago
    RN is quite inefficient and perf issues will not be obvious if using high end devices. Which is why Meta is working on Hermes: https://engineering.fb.com/2019/07/12/android/hermes/ https://engineering.fb.com/2019/07/12/android/hermes/
    - deleted 4y ago
      [deleted]
    - actualwitch 4y ago
      Hermes is already enabled by default in rn.
      - danielrhodes 4y ago
        If you can get away with it, it's not a bad option. But it's still early days. If you run into compatibility problems or bugs with libraries being used, you could be in trouble.
    - siquick 4y ago
      That’s from almost 3 years ago. RN had changed a lot since then (and Hermes is included by default now) https://reactnative.dev/architecture/bundled-hermes https://reactnative.dev/architecture/bundled-hermes
LAC-Tech 4y ago
Question for mobile devs - how viable is to share code betweeen native android and IOS apps? IE, all the user interface is done natively, but you share business rules, and maybe even an abstract view layer with names of fields, actions etc. Would you have to write it all in C, as that's the lowest common denominator for stuff that can be used in both swift and kotlin? Or are there other alternatives?
- Vt71fcAqt7 4y ago
  Flutter[0] lets you share the whole UI and really only requires per-system changes for thing like file system management. [0]https://flutter.dev/ https://flutter.dev/
  - LAC-Tech 4y ago
    Right but say you wanted separate UIs written in the native language for that platform. Again - not a mobile dev - but my spidey senses tingle when I see "cross platform UI". Feels like it won't go well, that different platforms have different conventions, that the abstraction layer will leak like a sieve, etc.
    - Vt71fcAqt7 4y ago
      As I didn't make it clear, my response was to "Or are there other alternatives?" rather than to your main question.
- secretsatan 4y ago
  Cpp libs can mostly be used and it’s the strategy we use, the main worry is trying to avoid massive sizes with dependencies up the yazoo in some of them. I’ll speak from the swift side, it’s improving a lot, but we’re still in a bit of a transitional phase. With a swift package, you can include cpp libraries but still need an obj-c bridging layer, but afaik swift is becoming better at interoperability, but we maintain a few versions behind swift bleeding edge. Android are also able to add their own stuff to the repos to make it work. So we basically have a mobile repo that can work for ios and android, pulling in cpp binaries as submodules
fleddr 4y ago
I remember reading an article here a few months ago about a big company undoing their React Native migration, as it was a total disaster. Forgot the company name, anybody know?
- siquick 4y ago
  Airbnb probably https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
  - fleddr 4y ago
    That's it, thanks! Summary: It was a massive pain and none of the benefits materialized. Great thing to look forward to for Shopify. Let's meet here again in a year or two for the exit blog post.
    - JimDabell 4y ago
      When Shopify announced they were switching to React Native, their CEO posted this on Twitter about AirBnb giving up: https://twitter.com/tobi/status/1222551057798090752 https://twitter.com/tobi/status/1222551057798090752 There are quite a few high profile migrations that end up being reversed, it’s not just Airbnb. Some of them you hear about, like Udacity: https://engineering.udacity.com/react-native-a-retrospective-from-the-mobile-engineering-team-at-udacity-89975d6a8102 https://engineering.udacity.com/react-native-a-retrospective... Some of them you don’t. For instance, Walmart wrote a lot about their switch to React Native here: https://medium.com/walmartglobaltech/a-new-beginning-for-react-native-at-walmartlabs-online-grocery-c30b27db57d3 https://medium.com/walmartglobaltech/a-new-beginning-for-rea... …but I believe they completely reversed course and went 100% native after that.
      - fleddr 4y ago
        Thanks for the extra context. The Udacity post is especially educational.
cfuendev 4y ago
I still don't get why React Native is so exaggeratedly popular when re-writing code in huge codebases just because it's similar to the React you use in the desktop.. Or just because it's "A single codebase for both platforms". Do people not research into the topic before starting to migrate? People could work with Flutter, which is still cross-platform and outperforms RN in every way possible. It's like having a single Java or Swift codebase for both apps, because it's a well-thought out framework built for mobile natively (On a language capable of compiling to native), not a hacky workaround to have React represent phone UIs (Built on a mixture of languages).
- JimDabell 4y ago
  > I still don't get why React Native is so exaggeratedly popular when re-writing code in huge codebases just because it's similar to the React you use in the desktop. It isn’t popular. It’s talked about way more than it is actually used. 5.3% of mobile applications use React Native. 4.4% of mobile applications released in 2022 use React Native. https://appfigures.com/resources/insights/20220729?f=3 https://appfigures.com/resources/insights/20220729?f=3
rabenfrass 4y ago
In the video demo they show a glitch in the iOS screen. For a fraction of a second the Recent Products carousel has height zero and we see the cells from the carousel below (try recording with slo mo camera to see it). An obvious programming error, and yet they chose that for the demo. It doesn’t exactly inspire trust.

94 points by cpeterso 4y ago

deleted 4y ago

[deleted]

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.

ageektrapped 4y ago
Former Shopify iOS dev here. I pushed SO HARD to get dark mode to be a thing we would do. It's table stakes, IMO, in 2020 and beyond, to support it. We'd get roasted on Twitter, LinkedIn, just about everywhere. HN Comments, even. :) Got shut down at the highest level. Like, definitively. As in, please don't ask again. I don't think you'll ever see it as long as Tobi is CEO.
- kayson 4y ago
  What was the rationale?
  - ageektrapped 4y ago
    IIRC, something about opportunity cost or maintenance burden.
    - secretsatan 4y ago
      There is virtually no maintenance burden if set up correctly, not shouting, i had to demonstrate the fact
- nprateem 4y ago
  I'm sure it's only a vocal minority that care
  - secretsatan 4y ago
    It’s so ridiculously easy to support though, and i may be a minority, but none of our users ever complain about it being there
    - mrbombastic 4y ago
      Ehh ridiculously easy seems like a stretch. You need to adapt all of your designs for dark mode and if you haven’t thought about it in the past or you don’t have a design system that is easily adaptable in the app you are going to be updating a lot of components and screens.
      - secretsatan 4y ago
        OK, yeah, you need to think about it first, but it should just be a case that all the colours in your design have alternates. It's mostly a case of differentiating between background and foreground colours. Then you put all your colours in the Assets, only ever used named colours, maybe hardcode some shortcuts, then you never think about it again. There are a couple of rare cases here and there, eg custom drawing using Core Graphics, where using cgColor won't pick up the change, you have to grab the underlying colour again and force a redraw
  - darren_ 4y ago
    I’ve seen arguments that dark mode is important for accessibility, which seems reasonable to me, and depending on the company might be a dealbreaker.
- secretsatan 4y ago
  Ugh, i got a bit of pushback on supporting dark mode in my native app, luckily i was starting from scratch and once you show you can pretty much do it by setting up assets correctly and that you can switch modes from the quick menu to test, noone even thinks about it anymore. They were all coming from a non native mindset though
lawgimenez 4y ago
If anyone starts a new SwiftUI project, dark mode support is automatic.

koch 4y ago

> Making Improvements As We Go > As we port screens to RN, we also look out for opportunities to improve the UX of the app. I would be curious to hear more about how this went - in my experience trying to do two things at the same time can lead to trouble, tempting as it may be (was it the migration or the upgrade we did along the way that caused this new bug?).

mrbombastic 4y ago
Agreed, you are almost always better off resisting that urge and taking note of things that should be improved as you go, otherwise scope balloons out of control.
corytheboyd 4y ago
Having done this, it goes poorly. You create new problems as you go because somehow, to the surprise of everyone, brand new ideas are less fleshed out than vetted ideas. Shocking.
hrpnk 4y ago
Making technical and functional changes results in an inability to explain A/B tests that attempt to prove that the migration did not have negative effects. If you change UX as part of the migration, you're often unable to tell whether the cause was technical or functional. It's just too easy to say that it must be the technical side, but you don't have tangible data unless you actually compare the functional changes built on top of the same technical foundation. Another aspect are behavioral metrics that may change between two implementations making these difficult to compare.

meisel 4y ago

How did Shopify choose between React Native and Flutter?

jitl 4y ago
Flutter isn’t native, React Native is.
- JimDabell 4y ago
  React Native isn’t native. It uses native UI components, but the application code is still just interpreted JavaScript, not a native application. https://reactnative.dev/docs/javascript-environment https://reactnative.dev/docs/javascript-environment
  - jitl 4y ago
    Yes, but you can write and integrate the platform APIs for UO components. You can’t do that in flutter.
    - kayson 4y ago
      UO components?
      - jitl 4y ago
        UI, oops
    - chadrickman 4y ago
      Platform channels - https://docs.flutter.dev/development/platform-integration/platform-channels https://docs.flutter.dev/development/platform-integration/pl...
    - lawgimenez 4y ago
      Flutter compiles code to native and RN uses JavaScript as a bridge to communicate.

JimDabell 4y ago

They announced they were moving to React Native three years ago. Since then, they’ve set up a mobile enablement team, they’ve set up an internal training programme, and they’ve ported four out of three hundred screens [edit: see discussion below]. They are choosing to do it gradually because their estimate for a rewrite was three years. They are choosing not to go with the “new features in React Native” approach because their estimate for that was four to five years. They seem really happy with their “We all get shit done, ship fast, and learn” progress, but I’m sure I’m not the only one reading this article and coming away less likely to choose to migrate to React Native, right? This does not sound compelling at all.

tsss 4y ago
Irrespective of this blog post, that is probably a good take away.
- sabellito 4y ago
  Why?
trevor-e 4y ago
Where do you see they only ported four screens? In the dashboard screenshot it clearly shows "RN Screen Count: 139/572", so they've ported 139 screens, right? The "four" figure you're referring to is the root navigation screens of the app which get a lot more traffic, hence why they prioritized those to uncover issues.
- JimDabell 4y ago
  This is what I was referring to: > Where We Are Now > Here’s a spoiler: Today, if you open the Shopify Mobile app, all four root screens are in React Native already! If you write “where we are now: we’ve ported all four root screens”, that’s what I’m going to hear. I’m not going to look through screenshots for contradictory figures. If they have actually ported 139 screens, maybe they should have said “where we are now: we’ve ported 139 screens”? As far as I can see they don’t say anything like that at all, are you inferring from screenshots alone? Regardless, my point still stands – if you need to set up a training programme and a facilitation team and it’s going to be a multi-year effort, and after all that you proudly tell people that they can’t tell the difference between the old version and the new version… this still does not sound compelling at all, even if you have got almost a quarter of the way through the project in three years.

smith7018 4y ago

So after three years, they've ported "all four root screens" in React Native? I can't fathom how broken each of their platform's codebases must have been to require everyone to learn a whole new paradigm to start over from scratch. Further more, they are presumably causing the same code quality issues because "React Native was a completely new tech stack for [their engineers]." So the codebases were so broken that they had to rewrite them and they chose a system that most of them are learning as they go. Love it lmaoo

hooksfordays 4y ago
As someone who worked on the Shopify iOS and Android codebases, I would argue they weren’t all necessarily so broken. The flagship mobile app (the one primarily discussed in the article) was in good shape on iOS (and arguably better shape on Android). There was some fragmentation in architecture among teams, but overall things were reasonable and I didn’t personally find it difficult to jump into unfamiliar sections of the codebase.. Shopify’s other apps that migrated first were either much older, and therefore had much more tech debt, making the rewrite more enticing, or were much smaller in scope, making the rewrite much faster to get to feature parity. Once all the other apps had migrated or decided to migrate, it made a lot more sense to explore it in the flagship app discussed here. Some disclaimers, I’m no longer at Shopify, and while I worked in the very early iterations of the port of the flagship app, I wasn’t necessarily a vocal proponent of migrating it to RN. I enjoy RN, but I enjoyed working on the native Shopify apps.
ageektrapped 4y ago
The choice to port to RN wasn't technical at all. Tobi (the CEO) prefers RN philosophically. No technical argument opposed to RN--which is super easy to come up with, along several axes--would have stopped the port. It was inevitable. This is my opinion, as I watched it unfold. I'm no longer at Shopify.
- weego 4y ago
  If he's willing to have the business fund it long term then fair enough honestly. But it seems like a weak strategy that isn't playing out well judging by the progress made over the 3 years so far.

hrpnk 4y ago

The migration tracker is nice. Highly recommended approach for any migration project, incl. data migrations. It not only helps track the progress over time, but also provides great material for status updates. It's a perfect place to redirect stakeholders who have questions on the status or to help reduce their anxiety around progress.

Grim-444 4y ago

Well I give them props for at least having a facade of a "what went wrong" section, which most RN articles leave out, although it doesn't feel like an honest analysis of the negatives of their switch. I'd like to see some actual data about what percentage of their code is written in native vs RN. In my experience you need to maintain massive amounts of native framework code on both sides to support the RN code, and to implement stuff that RN can't do or does horribly. Adding RN into the mix just basically adds one more platform to be supported, making things more complicated, rather than combining code into fewer platforms. RN teams never bother to mention how much native code is needed to support them, and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned. Also curious about other metrics such as how many developers they lost that weren't interested in becoming JS developers. Or have they stuck around because there's still so much native work that they need native developers for, to support RN.

brundolf 4y ago
Anecdotally we've got a RN app, and we've only got one or two native source files for each platform, which are mostly there to bridge in third-party libraries for things like analytics. Our UI and business logic are almost 100% JS and it works out really nicely for us Of course this is a mostly standard (but not small) CRUD app. We've got some custom animations/widgets here and there, but mostly it's vanilla forms, controls, views, etc. which translate easily to both platforms We also started out on RN from the beginning; it's possible that migrating to it from native code is a much bigger challenge
- chenxi9649 4y ago
  Same for us. Certain dev environments bugs were been a big pain in the ass for us in the past. For the logic side of thing React Native has been a nice experience for us as well!
59nadir 4y ago
> [...] and seemingly never include native work that was done when giving metrics about how long it took to "write" a feature in RN, usually because a separate "native" team does that work, not them, so it's conveniently not mentioned. In this case it seems like they transitioned a mostly native mobile workforce into React Native, so I don't know that the last bit makes much sense here. I agree with you that there is a general absence of information about how they still deal with the native side of everything with React Native becoming more and more important in their apps. Even just the "yet-to-be-transitioned-but-we-need-to-use-it" kind of stuff would've been more interesting to learn about and certainly "What native stuff remained in sections that were ported?" seems reasonable as well.

null_object 4y ago

Where I'm working we're porting the native apps gradually to SwiftUI on iOS and on Android using Kotlin Compose - addressing a lot of the development speed issues mentioned in the article, and shifting to a 'reactive' model while retaining truly native performance and components. Developing in SwiftUI is lightning-fast - there are a few bumps and bugs that have been extensively discussed, but it's really simple to still use UIKit components in the places that need them (which are becoming fewer all the time). For me the tone of the article is very 'positive' but the amount of time and effort seem horrendous. And now they're stuck with React. Not sure how many times these articles need to be written and then... [0] [0] https://www.twopicode.com/articles/this-is-why-we-stopped-using-react-native/ https://www.twopicode.com/articles/this-is-why-we-stopped-us...

zyang 4y ago
I think you made the right call here. SwiftUI had a slow start but now closing the gap on UIKit. ReactNative is a dead end.
- nodemaker 4y ago
  As a former iOS UIKit dev I actually prefer react native to SwiftUI. If we have to do this declaratively (and I have to re-learn how to do complex layouts) lets also make it platform independent and reusable with Web. It feels like SwiftUI is being pushed down my throat and I have a strong aversion towards things like that.
  - danpalmer 4y ago
    Has sharing between the web and RN worked out for you? It seems like it hasn’t for many, or any high profile apps. Even mobile web and non-web mobile are quite different platforms, even at the UI layer. There are many different expectations, platform norms, and interaction differences that don’t work well in browsers or across platforms. I’d love to seen an example of it working well but I haven’t yet.
    - 4y ago

pen2l 4y ago

The scrolling/transitions animations are jittery in the left in the video, it’s a readily identifiable artifact of RN apps in fact, whereas the native one is incredibly smooth in all refresh transitions and scrolls. I wonder how difficult it is for RN to fix this. Just this one singular improvement in UX would be worth its weight in gold.

helsontaveras18 4y ago
Why is this being down voted? Upon re-watching the video, I did notice a visible stutter in scrolling the app on the left. (To be fair, I didn't notice it the first time I watched the video.)
danielrhodes 4y ago
This is where things get interesting in React Native. The answer is: yes you can have smooth animations. However, the animations have to be driven at the native level and not in JS. The reason for this is: React Native is on a run loop. And on each loop, new state is shared over a bus from the JS side to the native side. So if you manage the frames of an animation over this bus, it's going to be very slow. If the native side manages the animation, you don't have this overhead. The same goes for touches. If you touch something, the native side gets the event and then this goes over the bus and RN picks it up. But if RN then responds to that touch by highlighting a view, that means another message has to go back to native - lots of overhead. For that to happen without a perceptible delay you have to have these events handled on the native side. Another thing that can happen is too many things in the view change at once: you then have a traffic jam on the bus and the UI slows down or becomes unresponsive. This can happen if state changes too quickly. You can get decent performance out of React Native (especially on tables, which is otherwise a dark art in iOS), but you have to know where the bottlenecks pop up.
- siquick 4y ago
  This is some great insight that should be highlighted in the RN docs.
ricardobeat 4y ago

pier25 4y ago

I would love to see their test using a regular Android device, not a high end iPhone. Android has like 90%? worldwide market share and most phones are way underpowered vs even old iPhones. Picking a solution that only works well for SV users is a terrible decision.

brundolf 4y ago
RN uses native controls (not a webview) and JS is plenty fast for most UI logic (it's almost never the bottleneck on slow web apps), so I would not expect performance to be a problem here
- pier25 4y ago
  RN is quite inefficient and perf issues will not be obvious if using high end devices. Which is why Meta is working on Hermes: https://engineering.fb.com/2019/07/12/android/hermes/ https://engineering.fb.com/2019/07/12/android/hermes/
  - deleted 4y ago
    [deleted]
  - actualwitch 4y ago
    Hermes is already enabled by default in rn.
    - danielrhodes 4y ago
      If you can get away with it, it's not a bad option. But it's still early days. If you run into compatibility problems or bugs with libraries being used, you could be in trouble.
  - siquick 4y ago
    That’s from almost 3 years ago. RN had changed a lot since then (and Hermes is included by default now) https://reactnative.dev/architecture/bundled-hermes https://reactnative.dev/architecture/bundled-hermes

LAC-Tech 4y ago

Question for mobile devs - how viable is to share code betweeen native android and IOS apps? IE, all the user interface is done natively, but you share business rules, and maybe even an abstract view layer with names of fields, actions etc. Would you have to write it all in C, as that's the lowest common denominator for stuff that can be used in both swift and kotlin? Or are there other alternatives?

Vt71fcAqt7 4y ago
Flutter[0] lets you share the whole UI and really only requires per-system changes for thing like file system management. [0]https://flutter.dev/ https://flutter.dev/
- LAC-Tech 4y ago
  Right but say you wanted separate UIs written in the native language for that platform. Again - not a mobile dev - but my spidey senses tingle when I see "cross platform UI". Feels like it won't go well, that different platforms have different conventions, that the abstraction layer will leak like a sieve, etc.
  - Vt71fcAqt7 4y ago
    As I didn't make it clear, my response was to "Or are there other alternatives?" rather than to your main question.
secretsatan 4y ago
Cpp libs can mostly be used and it’s the strategy we use, the main worry is trying to avoid massive sizes with dependencies up the yazoo in some of them. I’ll speak from the swift side, it’s improving a lot, but we’re still in a bit of a transitional phase. With a swift package, you can include cpp libraries but still need an obj-c bridging layer, but afaik swift is becoming better at interoperability, but we maintain a few versions behind swift bleeding edge. Android are also able to add their own stuff to the repos to make it work. So we basically have a mobile repo that can work for ios and android, pulling in cpp binaries as submodules

fleddr 4y ago

I remember reading an article here a few months ago about a big company undoing their React Native migration, as it was a total disaster. Forgot the company name, anybody know?

siquick 4y ago
Airbnb probably https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
- fleddr 4y ago
  That's it, thanks! Summary: It was a massive pain and none of the benefits materialized. Great thing to look forward to for Shopify. Let's meet here again in a year or two for the exit blog post.
  - JimDabell 4y ago
    When Shopify announced they were switching to React Native, their CEO posted this on Twitter about AirBnb giving up: https://twitter.com/tobi/status/1222551057798090752 https://twitter.com/tobi/status/1222551057798090752 There are quite a few high profile migrations that end up being reversed, it’s not just Airbnb. Some of them you hear about, like Udacity: https://engineering.udacity.com/react-native-a-retrospective-from-the-mobile-engineering-team-at-udacity-89975d6a8102 https://engineering.udacity.com/react-native-a-retrospective... Some of them you don’t. For instance, Walmart wrote a lot about their switch to React Native here: https://medium.com/walmartglobaltech/a-new-beginning-for-react-native-at-walmartlabs-online-grocery-c30b27db57d3 https://medium.com/walmartglobaltech/a-new-beginning-for-rea... …but I believe they completely reversed course and went 100% native after that.
    - fleddr 4y ago
      Thanks for the extra context. The Udacity post is especially educational.

cfuendev 4y ago

I still don't get why React Native is so exaggeratedly popular when re-writing code in huge codebases just because it's similar to the React you use in the desktop.. Or just because it's "A single codebase for both platforms". Do people not research into the topic before starting to migrate? People could work with Flutter, which is still cross-platform and outperforms RN in every way possible. It's like having a single Java or Swift codebase for both apps, because it's a well-thought out framework built for mobile natively (On a language capable of compiling to native), not a hacky workaround to have React represent phone UIs (Built on a mixture of languages).

JimDabell 4y ago
> I still don't get why React Native is so exaggeratedly popular when re-writing code in huge codebases just because it's similar to the React you use in the desktop. It isn’t popular. It’s talked about way more than it is actually used. 5.3% of mobile applications use React Native. 4.4% of mobile applications released in 2022 use React Native. https://appfigures.com/resources/insights/20220729?f=3 https://appfigures.com/resources/insights/20220729?f=3

rabenfrass 4y ago

In the video demo they show a glitch in the iOS screen. For a fraction of a second the Recent Products carousel has height zero and we see the cells from the carousel below (try recording with slo mo camera to see it). An obvious programming error, and yet they chose that for the demo. It doesn’t exactly inspire trust.