Hacker News Reader

Comment by JimDabell | Hacker News Reader

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.

View on HN

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.

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.

"root screens" have a specific meaning and significance on mobile so I can understand the confusion, I agree that the article was not clear.

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.

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

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.

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?

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

That's what really puzzled me about 1Password's switch from native Mac to Electron.

The reason was, "we want code sharing with Windows". Okay, you've got that now… it's terrible… but you're also maintaining a SwiftUI app for iOS and iPadOS. Why not code share that with Mac?

My guess is they'd maybe prefer the majority of their investment be in cross platform technology?

But code-sharing between MacOS and iOS is also investment in cross platform technology. They're _already_ managing two code bases, why does Mac have to be on the shitty one?

This probably works if a lot of your core code is not UI or presentation (dropbox sync, snapchat video filters). My guess is the shopify app is almost all presentation and their backend handles most of the heavy lifting and writing presentation in C++ is... not ideal

You wouldn't write the presentation layer in C++.

It would be for all of your domain models, business logic and backend integration code.

You could even have Djinni generate the server side models as well.

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

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.

Irrespective of this blog post, that is probably a good take away.

Why?

Reply on news.ycombinator.com