That really just says it all doesn't it? It's basically an admission that the use of cross-platform frameworks is worse for customers/users, but they're going to ignore that to optimize for their own software engineering org.

All this says to me is that they wanted to limit their risk exposure by doing an experiment on Android while maintaining native on iOS. Why is that hard to comprehend? Their move to RN this year should underscore the success of that experiment.

The thing is, you can rephrase:

> by doing an experiment on Android while maintaining native on iOS

as:

> by throwing their Android users under the bus

It may be a cynical take but it's not an invalid one to take when the thrust of the rest of the paragraph comes down to "the native app's performance is so good, we couldn't dream of changing it".

I don't know if you read the article or not but the title is very clearly: "React Native is the Future of Mobile at Shopify". So the Android experiment was successful.

Also, ios is “easy” when it comes to doing react-native. So by doing the hard one first, they have a lot more confidence in the rest.

This is how I read it too. They can then run the RN app on iOS too (with some modifications I'm sure). Seems like a smart strategy. And that the jury is still out.

> Why is that hard to comprehend?

Probably because that's not what the article says.

Build RN app on Android, if it's successful then do a light port to iOS and decommission native team.

Seems like a fantastic experiment IMO.

I dig it. Doubt they would decommission the native team tho, since all engineers can do RN. Whether they want to... that's a whole different matter.

It doesn't necessarily have to mean that. If performance is generally good enough, then the ability to do things like add critical features, patch bugs, and refine the app much faster is much higher value for the user and Shopify.

I was writing POS applications in the 90s. And ringing up customers needs speed and responsiveness. Windows was way too slow at the time, that's why POS applications even to this day often still work in character mode, or DOS-graphics.

PS I know it's becoming less and less of an issue these days, but you get my point.

Right, but it doesn't really optimize for their engineering team either since the only reason to use something like React Native is the ability to do both platforms at once.

Is that not a tremendous optimization for the team? It probably cuts the team size in half (or, seen another way, doubles its size for free), and it unifies of a lot of the mobile and web stacks behind similar languages and tools, which in turn would allow some unification in the hiring and recruiting pipelines.

This overstates the gains by a lot.

1) Each platform still requires a good amount of special attention.

2) The React Native project introduces breaking changes far more frequently than the underlying platforms

3) Being an abstraction layer, eventually something will break, and you’ll still need someone who understands cryptic linker errors and platform specific quirks.

There are cases where it definitely makes sense, but the hidden costs need to be accounted for.

I would argue to the contrary that it’s such a large optimization that even accounting for all of that it’s still a big net win from a staffing perspective. It’s far easier to maintain a few Android experts on staff than an entire department of them.

I understand that argument, and it's seductive, and in many cases probably true. But it's advertised as a 2-3x productivity gain and that is simply not the case.

It's an optimization they aren't using, React Native is only being used for Android.

Do they not clearly intend to use it for both in the future? They didn't go back and rewrite all existing apps, and they did an experiment with Android to validate the approach.

you act like whatever something is right now is the same in the future. It's quite possible they see RN as the future for all products and easing there way into things. Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs. So no, that does not really just say it all.

> Maybe they are struggling to find Java/Kotlin devs and have a surplus of Swift devs.

Based on AirBnB's experience, now you need to find React Native devs in addition to Java devs.

I can see, if you were a billion dollar company, how you’d have an Android infra team to bridge those performance-intensive items, with the UI team doing all their work in RN.

So you can’t be a startup/small shop if you want to do this well.

I assume it's easier to find a handful of skilled Android developers rather than staffing an entire engineering org with them.

From my experience with RN, you do need to get into the native bits, but most of the development will be not native. So the number of skilled native device engineers required should be less.

I think you’re touching on something extremely important here. IME, anecdotally, not backed up by data: experienced native Android devs are getting harder and harder to find.

The ones I’ve known personally hated it so much they moved to backend or full stack jobs.

Interesting, I always thought it would be harder to hire iOS devs since the initial cost is higher - you need to buy a more expensive Apple computer and pay an yearly $99 subscription just to get started.

For that reason I thought that there would be way more Android devs. After all, a teenager with a regular computer can start developing Android apps and download the APK in a cheap Android device without paying anything.

On the other hand you mentioned _experienced_ native Android devs, while my thought applies more to junior Android devs, and maybe the two things don't correlate as well as expected.

you don't need a mac to build ios apps.

Isn't the vast majority of their POS systems iOS based? The base iPad is rather fast. Why not just target your market directly and max out performance? Meanwhile the vast majority of their Android POS systems use what, lower end Kindles and such? They know they can't get perfect experience there but they don't want a bad one where it counts. They know their market.

Really depends on their priorities and customer base. We developed a react native android app and users seem to be happy with it. Would native be smoother? Maybe..

Why couldn't they help contribute to/optimize React Native to be faster?

Because the architecture is the primary source of the performance issues.

React Native is widely used by the many-billion-dollar company that originated it, so major performance opportunities are not likely to be low-hanging fruit at this point.

There is a major re-architecture of React Native underway[1]. See Lorenzo Sciandra's excellent conference talk for an explanation of what the current limitations are in React Native and how they are planning on addressing them in the near future [2].

[1] https://github.com/react-native-community/discussions-and-pr... [2] https://www.youtube.com/watch?v=7gm0owyO8HU

I just speed read though it, So basically Everything is changed? I am not even sure if that is like a re-architecture, it is more like a a rewrite, literally every apart of the stack, all the way to Javascript Engine. All aiming for 2020 release.

At least the whole stack have many large companies'vested interest in it now so it is unlikely RN will fade out anytime soon. Will be interesting to see how all these played out in 2021/2022.

They will probably slowly introduce the changes one feature at a time in a backward-compatible way in a similar manner to how core react architectural changes are introduced (eg fiber, suspense, hooks etc).

Someone I work with on react-native just sped up large text parsing by 40% or so.