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.