4 ms·

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 progra

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.
  - trevor-e 4y ago
    "root screens" have a specific meaning and significance on mobile so I can understand the confusion, I agree that the article was not clear.
    - hbn 4y ago
      They explained earlier in the article that root screens were larger, high-impact screens at the top level of the app. They even bolded "root screens" the first time it was used to highlight it as a key word. It seemed pretty clear to me.
      - secretsatan 4y ago
        I’m pretty sure they mean the root of navigation stacks. They have high impact as it’s the first thing a user will see and should contain all the most important features
  - hajile 4y ago
    That depends on what parts got ported. I worked on a large app where just a couple payment screens too as long as most of the rest of the app because there were so many business rules to take care of. If they prioritize the most important and complex parts of the system, they may be a lot closer to finished than the numbers would seem to indicate.
pier25 4y ago
Honestly, as much of a pita it is to maintain two native apps, is this really worse than the huge overhead that was migrating to RN?
- secretsatan 4y ago
  I’m in two minds I got so frustrated with a cross platform technology i just wrote a native app to get away from it which the company later adopted. It implemented all latest native features, was tiny in size, and code base was easy to understand. As it grows and our teams grow it does get harder, but also, if you’re using bleeding edge features, cross platform solutions can only cater to the lowest common denominator
  - mhuffman 4y ago
    I have had similar experiences on several decent sized mobile projects. The idea of a single code-base to rule them all is very seductive. The reality, when you get to UI and hardware issues, is when you begin to get frustrated. If your app doesn't need perfect hardware coverage, great hardware sub-system coverage (cameras in particular), and you have some cohesive UI design that won't irk people on seperate platforms ... then go ahead, React Native, or ionic, or flutter, or plenty of frameworks will work for you. Otherwise, I think it is better to just bite the bullet and run two separate code-bases with pretty tight project managment to keep them synced.
- threeseed 4y ago
  Also when you write an app for iOS you have most of the code to target watchOS, iPadOS, macOS, tvOS, realityOS etc. For an app like Shopify where users often want to see revenue, sales etc in different environments using React Native seems a bit short-sighted to me. I would've just use Djinni [1], kept most of the core code in C++ and then build native apps. Approach that Dropbox, Snapchat etc. took and seems to work. [1] http://djinni.xlcpp.dev http://djinni.xlcpp.dev
  - deleted 4y ago
    [deleted]

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.
- trevor-e 4y ago
  "root screens" have a specific meaning and significance on mobile so I can understand the confusion, I agree that the article was not clear.
  - hbn 4y ago
    They explained earlier in the article that root screens were larger, high-impact screens at the top level of the app. They even bolded "root screens" the first time it was used to highlight it as a key word. It seemed pretty clear to me.
    - secretsatan 4y ago
      I’m pretty sure they mean the root of navigation stacks. They have high impact as it’s the first thing a user will see and should contain all the most important features
- hajile 4y ago
  That depends on what parts got ported. I worked on a large app where just a couple payment screens too as long as most of the rest of the app because there were so many business rules to take care of. If they prioritize the most important and complex parts of the system, they may be a lot closer to finished than the numbers would seem to indicate.

pier25 4y ago

Honestly, as much of a pita it is to maintain two native apps, is this really worse than the huge overhead that was migrating to RN?

secretsatan 4y ago
I’m in two minds I got so frustrated with a cross platform technology i just wrote a native app to get away from it which the company later adopted. It implemented all latest native features, was tiny in size, and code base was easy to understand. As it grows and our teams grow it does get harder, but also, if you’re using bleeding edge features, cross platform solutions can only cater to the lowest common denominator
- mhuffman 4y ago
  I have had similar experiences on several decent sized mobile projects. The idea of a single code-base to rule them all is very seductive. The reality, when you get to UI and hardware issues, is when you begin to get frustrated. If your app doesn't need perfect hardware coverage, great hardware sub-system coverage (cameras in particular), and you have some cohesive UI design that won't irk people on seperate platforms ... then go ahead, React Native, or ionic, or flutter, or plenty of frameworks will work for you. Otherwise, I think it is better to just bite the bullet and run two separate code-bases with pretty tight project managment to keep them synced.
threeseed 4y ago
Also when you write an app for iOS you have most of the code to target watchOS, iPadOS, macOS, tvOS, realityOS etc. For an app like Shopify where users often want to see revenue, sales etc in different environments using React Native seems a bit short-sighted to me. I would've just use Djinni [1], kept most of the core code in C++ and then build native apps. Approach that Dropbox, Snapchat etc. took and seems to work. [1] http://djinni.xlcpp.dev http://djinni.xlcpp.dev
- deleted 4y ago
  [deleted]