
Building all of our new mobile apps using React Native - arbhassan
https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify
======
newfeatureok
Honestly I think the future of mobile will just be... mobile websites.

What's missing until regular websites have parity with mobile apps in
functionality?

\- Accelerometer and all sensor support (some of these are already supported
on various browsers on various OSes)

\- Background support

\- Bluetooth

\- WiFi

\- Better notifications

\- etc.

Sure there will always be a need for native, but 99% of apps don't need any of
that stuff, really. Though I suppose both Apple and Google have an inherent
interest to gatekeep.

Looking at my own most used apps:

\- Messenger

\- Mail

\- White Noise

\- Teams

\- Google Maps

Literally all of them could be implemented as responsive pages with acceptable
performance. There are a small number of companies that don't bother with
mobile apps, Craigslist being the most notable of them until a few months ago.
Part of the issue though is that the app stores give you a lot of visibility
and to get that visibility you need to be in the app store. Sure you can use a
web view, but in some ways that's even worse than just a responsive website
because now you have to deal with the abstraction of your site that is a
WebView. Not to mention the temptation to try for "best of both worlds".

~~~
divbzero
Ten years ago Facebook fought this battle and lost. [1] [2] [3]

[1]: [https://www.facebook.com/notes/facebook-engineering/using-
ht...](https://www.facebook.com/notes/facebook-engineering/using-
html5-today/438532093919) "Using HTML5 Today"

[2]:
[https://appleinsider.com/articles/12/09/11/facebook_admits_h...](https://appleinsider.com/articles/12/09/11/facebook_admits_html5_not_competitive_with_cocoa_touch)
"Facebook admits HTML5 not competitive with Cocoa Touch"

[3]: [https://techcrunch.com/2012/12/13/facebook-android-
faster/](https://techcrunch.com/2012/12/13/facebook-android-faster/) "Facebook
Speeds Up Android App By Ditching HTML5 And Rebuilding It Natively Just Like
The iOS Version"

I have always rooted for mobile web apps, but the lack of feature parity and
distribution challenge (“Add to Home Screen”) puts them at a constant
disadvantage and companies who control mobile OS’s have little incentive to
change this.

~~~
koheripbal
It strikes me that, more than anything, it is the lack of an efficient "Add to
Home Screen" flow, that has doomed mobile websites.

...and it's intentional. By having an app store, mobile OS distributors know
that they have control over a massive revenue stream.

~~~
bostik
A good part of it is their absolutely _massive_ 30% cut. The only reason they
get away with it is that when Apple's app store first came out, most of the
online casual applications were games. Hosted by a few gargantuan aggregators
( _cough_ newgrounds _cough_ ) who charged 70%+ of the revenue for their ...
service.

Against a backdrop of above-criminal-rates extortion, 30% must have looked
like a bargain.

To put these numbers in context, very good agents get 15%.

~~~
scarface74
Most of the money being made on the App Store is for in app consumables from
pay to win games. You’ll have to forgive me for not shedding a tear for them.
I hope Apple Arcade takes a huge chunk of their revenue.

It’s not indy developers trying to make a living.

The other types of apps that use to make Apple a lot of money are streaming
services. But most of those are now not allowing you to do in app purchases.

I’m looking through all of my apps, and I only have two or three that I
actually paid money via in app purchases and those were to turn off ads.

All of the rest I had to buy subscriptions on the app makers websites or buy
content in the case of Amazon for Kindle books.

~~~
bsaul
As a developer of a pro app in a niche market trying to make a living on the
app store, i can tell you those 30% are what prevents me from working full
time on my app.

~~~
krrrh
There are thousands of desktop app developers that never got out of the hobby
stage because they couldn’t get past the costs of processing payments,
managing refunds, managing download servers, implementing licensing
frameworks, implementing a smooth upgrade process, search engine optimization,
establishing enough trust with users that they are confident they aren’t
installing malware infected software, marketing, push notification
infrastructure, and probably a few other things I’m not thinking of.

It’s probable that 30% is too much to pay for help with all of that, but
people too often act like Apple’s just taxing them and providing no
commensurate value at all.

~~~
gorgoiler
Part of what makes it so galling is because Apple has those competencies in
spades anyway (SREs, designers, datacenters, bizdev.)

Another aspect is that the App Store feels like a value-add for the actual
marketed products — iPhones and iPads — and not something you are ever
explicitly buying. It doesn’t show up on the receipt. People talk about buying
a new iPhone, or getting then latest iPad. No one ever goes to the Apple store
to buy the lates _access to the App Store_.

As such, Apple’s cut feels like it’s everything from cheeky to an abuse of
their “monopoly” in the _providers of iOS devices_ marketplace.

~~~
OJFord
> Part of what makes it so galling is because Apple has those competencies in
> spades anyway (SREs, designers, datacenters, bizdev.)

But what do you mean 'anyway'? If Apple suddenly said 'you know what, App
Store is EoL, do your own distribution' (because of legal or whatever reason)
surely there would be a spade or two of those competencies that were
consequently redundant?

I don't imagine they're hiring people to work on say Apple Maps; who
subsequently say 'cor, good thing I'm here, someone should take a look at that
unstaffed app store project'!

------
ppeetteerr
I'm surprised no one is mentioning this:

"At the beginning of 2019, we did a 6-week experiment on our flagship Point of
Sale (POS) app to see if it would be a good candidate for a rewrite in React
Native. We learned a lot, including that our retail merchants expect almost 2x
the responsiveness in our POS due to the muscle memory of using our app while
also talking to customers.

In order to best serve our retail merchants and learn about React Native in a
physical retail setting, we decided to build out the new POS natively for iOS
and use React Native for Android."

So it's okay to build Android and less important apps using RN, but their
flagship iOS POSS is off limits?

~~~
Despegar
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.

~~~
chrisco255
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.

~~~
zapzupnz
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".

~~~
chrisco255
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.

~~~
ericlewis
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.

------
anon9001
Shopify is right to use React Native.

I build an app with React Native Web and we produce Android/iOS/web from the
same code base with 3 developers.

No, it's not perfect. Yes, JS can be awkward and confusing. Yes, a truly
native app built by expert platform-specific developers would be better.

But I'm able to ship this product with less than half the team size I would
need for native development. JavaScript developers are cheap to hire, and they
don't need to know any objc/swift/java/kotlin to build the product.

Our product is consistent, because it's the same code across platforms. The
business people paying us to build the app are thrilled at how quickly we can
turn around features.

We've been shipping this way for 2 years and I would strongly recommend it to
everyone.

Also, before people jump in with "But RN is slow and bloated!", it's actually
not. The performance is just as good as truly native and the binary is small.
The real downside is having the app not feel native, but only developers seem
to notice. Pragmatically, most apps are so bad that if your Android app has an
iOS look-and-feel nobody seems to care.

~~~
wdb
Don't know last time I tried React Native and wanted to use some cool feature
of iOS. I either had to write my own RN plugin in Swift/ObjC or wait for
someone else to do it.

~~~
npo9
You say that like writing plugins is hard or undesirable.

~~~
freehunter
That's what I don't understand when people criticize frameworks like React
Native... "I didn't like that I had to build 15% of the app in native code, so
I ditched RN and now have to write 100% of the app in native code, but twice
and in two different languages"?

~~~
tilolebo
React Native isn't the only abstraction out there. You could use Flutter,
Ionic or similar.

Or do they have the same issue?

~~~
anon9001
They all have the same issues, but RN has the largest community.

~~~
davidwparker
Flutter has a larger number of "star" on Github. It also has more issues and
more pull requests. React Native has 3x more followers on Reddit. So I guess
it depends on your definition of community.

~~~
s_y_n_t_a_x
Flutter is only in beta for desktop and web. And it's emulated UI, not true
native UI.

RN is ready now and today for all platforms, including Window via react-
native-windows.

Microsoft is choosing React, I wouldn't go w/ Flutter.

Why would you choose a Google only language and framework... unless you like
rewriting code when it dies.

Also, w/ React you can use TypeScript or JS, you don't have to learn a new
language.

From my perspective, it looks like Google pays a lot of money for these tech
articles and stars, it's not a really good way to look at things. There's
always a Flutter campaign going on.

~~~
greatjack613
As much as I hate that google kills stuff often, the above comment is missing
the fact that facebook also kills stuff often, they just never had any
adoption in the first place so you don't notice

~~~
s_y_n_t_a_x
But React is more open source and flexible. Microsoft has embraced React and
RN via their react-native-windows project, they are currently rewriting it
from C# to C++, so it must be important.

They use it for Skype and other products.

Google isn't built on Flutter, not the important parts. Facebook has been
building their stuff w/ React. They have over 10,000 components, I doubt
they'll abandon it.

Even if they do, React is much more flexible and open, it doesn't have a
compiler or language tied to it either. If Google drops Flutter, you're
fucked.

------
wvenable
I don't understand why so many large companies use platform abstractions. At a
certain size you're big enough to have an iOS team that develops natively in
Swift/ObjC and an Android team developing natively in Kotlin or Java.
Developing directly for the platform, with expertise in that platform, is a
proven long term bet. Screwing around with platform abstractions seems much
riskier.

The situation is a lot different if you're a small organization (or
individual) and just don't have the resources for platform specific experts.

~~~
Androider
Headcount is the biggest expense in almost all companies. Larger companies
also have larger and more complex apps, so while a small company may have a
small iOS development team, large companies have massive iOS development
teams. Massive team * number of platforms = serious money.

You also get into all kinds of platform and feature parity issues. "Why can't
we do X on Android but only on iOS?", "Well because they're two different
teams, with different PMs, developers and release schedules. And please don't
ask about the web team, who are in <different city>".

Using abstractions you can have one massive "core" team, and several smaller
platform expert teams. On the face of it, it makes sense.

~~~
wvenable
But developer headcount doesn't scale to the size of the installed base.
Whether you have hundred-thousand users or a million users, you don't need a
larger development team. Once you have a reasonable-sized team that can make
the app, you don't need any more developers, no matter how successful your app
is.

Having different teams for different platforms might result in a slightly
larger headcount my point is that risk isn't worth that meager benefit if you
can afford it. You're still going to need platform-specific knowledge, and
then the abstraction knowledge, and you're still deploying to multiple
platforms!

You also don't need to let the technology choices drive the team structure.
You can share a huge number of resources between iOS and Android including
planning, management, assets, etc. Sure you're building two different apps but
you don't need to keep those teams in different cities.

~~~
Androider
But the question was why large companies use platform abstractions. Because
they are large in headcount, by definition. Because the apps are already
large. Because they _have_ massive platform specific teams, and they would
like not to. Because the teams are geographically spread out, for a myriad of
reasons.

The large companies are what they are, and you cannot apply the same type of
thinking to their problems as if you were designing the organization from
scratch. There's problems they have, and the team structure they would like to
have, and based on that the technology choice to favor abstraction makes
sense.

~~~
wvenable
Yes, many large companies seek technological solutions to political problems.
I've worked for dysfunctional organizations; they want technology to provide
the decisions bottom-up because, for whatever reason, nobody wants to make any
hard calls. These projects fail because you simply can't have success that
way.

If this is a political and organizational problem, then this choice of
technology is entirely not about the pros and cons that have probably been
debated to death in this topic. I agree. I think you've added some really good
insight in this conversation. But I think that solution is dumb.

It's especially dumb for a software company because software is their core
competency. That's where they should be spending their resources on. They
should be minimizing costs but not at the cost of their core product.

~~~
Androider
I wouldn't class this as political problems. Is Facebook having a gazillion
developers on their app a political problem, or necessary given what they want
it to do? How is replicating that for each platform a good solution, in any
sense (political or technical)?

Tech companies core competencies are the service or product that they provide.
Making it N times for N platforms is a hurdle that doesn't improve on the
core, it's a cost of the fragmented market. I'm arguing that it makes perfect
sense both technically and politically to focus your vast majority of
developers on your core, and only having specialized platform teams were
necessary as a cost of doing business. How is developers re-implementing every
UI screen and feature across iOS and Android helping Shopify customers sell
more merch?

~~~
wvenable
> Is Facebook having a gazillion developers on their app a political problem,
> or necessary given what they want it to do?

Yes. How is it not a political problem? It's not a technological one.

> How is replicating that for each platform a good solution, in any sense
> (political or technical)?

It doesn't change anything politically but technologically platform
abstractions are never 100%. You always need an expert for each platform
_anyway_ and by targeting the abstraction rather than the platform you're just
targeting a crappier experience for your end users and often your developers
as well. React Native is not without it's issues.

So what's the benefit? You're not saving expertise. Even sharing code isn't
that important -- once decisions have been made, features planned out in
detail, server APIs created, the actual platform specific code is a pretty
small part overall. You still have to test on each platform individually. Fix
platform specific bugs even in non-platform specific code. And you're not
creating a dependency on a 3rd party that you don't control.

> How is developers re-implementing every UI screen and feature across iOS and
> Android helping Shopify customers sell more merch?

How is it not? I mean the argument here is that there is a huge savings to
justify the risk but I don't think that's true.

------
mleonhard
> The first is a tooling team that helps with engineering setup, integration
> and deployment. The second is a foundations team that focuses on SDKs, code
> reuse and open source.

They have a whole team to set up tooling for React Native. I wasted many days
trying to do this work on my own.

They also have a whole team for evaluating 3rd-party libraries that provide
functionality missing from React Native, such as letting the user hide the
keyboard on iOS. I wasted weeks on this and finally gave up on React Native
and switched to Flutter.

I think React Native needs some attention from user-focused PMs and engineers
before it is ready for adoption by small teams.

~~~
tr33house
How has flutter compared?

~~~
s_y_n_t_a_x
It emulates the UI, so the fake is noticeable, and it will be hard for them to
maintain perfect 1:1.

RN on the other hand bridges the native UI w/ your code via a JS bridge. The
downside is the bridge can be a bottleneck so you have to be careful how much
you congest it. The result is being able to expose every native functionality
and abstract it anyway you want using React extensions.

Flutter plans to target desktop and web, but RN is ready for this today.

Flutter requires you to learn Dart, a Google only language. RN you can use JS
or TypeScript.

Are you really going to trust that Flutter & Dart are around tomorrow w/
Google's record? Why oh why would you build your project with something that
risky.

~~~
artsr
Don't know why you're being downvoted. These all are perfectly reasonable
concerns. I've seen many GUI frameworks fail because of a mix of these
reasons.

~~~
s_y_n_t_a_x
Either Google or someone else w/ a vengeance follows me around and downvotes
me haha.

------
secondo
Arguably the biggest concern with React Native is that it is controlled by a
single entity, Facebook, and that they are not one of the leading mobile
platforms who from a business perspective have strong incentives to ensure the
future of their respective app eco systems.

Facebook's incentives with React Native are somewhat unclear. This is a big,
yet often unspoken, reason companies are vary of depending on React Native for
their mobile stacks. With more large companies such as Microsoft, and now
Shopify getting behind React Native those incentives will have to please a
larger group and should become much more aligned with mobile developer
communities at large - and not just Facebook's desires.

If Shopify manages to play an active role in the development of React Native
and expand the project beyond the sole control of Facebook then React Native
will become a much more viable option for companies who for political reasons
have refrained from using the technology.

~~~
malloreon
>>> Facebook's incentives with React Native are somewhat unclear

I always figured this conversation happened:

1: "We have all these engineers who write javascript but users are switching
to native apps. what do we do?"

2: "We could retrain them all."

1: "That would be expensive and time consuming."

2: "We could fire them all."

1: "Also expensive and time consuming."

2: "Wait, what if we made it so you could write native apps in javascript?"

~~~
zarmin
1: "Great idea. Which version of Electron should we use?"

------
yagodragon
The web and its ecosystem are huge. The browser is essentially the new OS and
no matter how complex and quirky js, react and the rest of the tools are,
we're gonna stick with them for a long time. Big technological advances like
PWA's, WASM and rendering engines like servo and webrender are only gonna
shorten the gap between native and web UI experiences. Look at what happened
to the desktop. Native UI development became a niche and even apps like
photoshop are now just websites(figma) or electron apps. This is eventually
gonna happen to mobile development as well. There will be no need to create
native apps for most cases and no need to use those centralized app stores to
"install" apps on your device.

That being said the web is not quite there yet and that's why solutions like
react-native and flutter exist. I don't believe that react-native is the
future. Many people have explained in great detail why the idea and the
execution behind RN are just flawed and why it makes development hard and
complex. Heck, it doesn't even eliminate the need for native developers.
React-native is just a transitional tech we'll use until the web and PWA's
become good enough for 95% of the cases. The future of RN is the Web.

On the other hand, flutter and dart seem to solve all of the problems we have
with UI development. It's an amazing tech that combines all the best ideas
from QT, flash, java swing, delphi and react-redux in one project that is
completely free and open source. It's what we've always dreamed existed in the
UI world. The development experience is great and designers seem to love it as
well. Despite its advantages, flutter is still a huge bet and i can't see a
world where everybody writes in Dart.

If I had to make a guess, I'm still betting on the web in the long run and
hope flutter captures a small market share among frustrated mobile/web devs
and designers. I just can't see react-native anywhere in between.

------
sandGorgon
I think one of the coolest things that Shopify is doing is this:

 _We’re sponsoring Software Mansion and Krzysztof Magiera (co-founder of React
Native for Android) in their open source efforts around React Native._

and

 _We are working with Discord to accelerate the open sourcing of FastList for
React Native (a library which only renders list items that are in the
viewport) and optimizing for Android._

Basically RecyclerView for React Native.

~~~
LeoNatan25
Without synchronous view layout, it's not really possible to have a truly
recycling view without many warts. We've (Wix) been hacking at this for years,
and it's not possible. You either block the UI or view flash for the user if
fast enough scrolling is performed.

Facebook engineering promised synchronous layout will come at some point,
which will open the door to that.

~~~
sandGorgon
What about Flipkart's
[https://github.com/Flipkart/recyclerlistview](https://github.com/Flipkart/recyclerlistview)
?

~~~
LeoNatan25
No web-only solution will give you a fully satisfactory result. It's just not
possible. If you scroll fast enough, you will see either flickering or empty
zones.

~~~
sandGorgon
there are demos -
[https://github.com/Flipkart/recyclerlistview#demo](https://github.com/Flipkart/recyclerlistview#demo)

------
ameixaseca
React Native sounds like a mistimed bet now. Maybe 3-4 years ago, but at this
time? There are a number of better alternatives.

I spent some time working on a RN project, and even though the whole idea of
declarative interface, state update, etc is interesting, it is not exclusive
of RN - and there is the whole rest of the story: RN libraries are a mess and
usually buggy, there is virtually very little compatibility between native and
web, and.. have anyone ever tried updating a RN codebase?

I remember we had to recreate the full project and copy the files manually
because everything was broken beyond any hope, this after spending a full week
trying to fix the build.

For Shopify seem that even a PWA could fit, and would be much more compatible,
reliable, etc.

By the way, one of their justification is "in-house know-how", which I heard
so many times before... This is usually how you justify crappy decisions by
using inferior technology and then spending 2x the effort to try to fix it. I
hope it doesn't happen with them, but it does like like that's the way they
are heading to.

~~~
Androider
It's interesting how differently you can look at things. I would consider the
best time to start a React Native project to be sometime next year, and after
1.0 ideally.

It's exactly when you jump on the bleeding edge that you end up with cuts and
bruises. For every new shiny thing you'll be trading your current known
problems for a set of unknowns and the inability to even Google-search for the
solution. Let the tinkerers do the bleeding, and only once they've buffed the
sharp parts can you as a company like Shopify start to bet on it.

It seems module and library handling was just revamped in React Native (not a
user myself yet, perhaps next year), so thank you for your sacrifice.
Developers picking up RN today will hopefully have a smoother experience.

------
hugey010
I thought the cool thing to do was declare React Native dead for your org, not
the new hotness?!?

I try to re-evaluate my opinion of the mobile ecosystem monthly, and would
love to know how people agree / disagree with my rankings:

1\. Just make a web page

2\. Native iOS & Android

3\. Flutter

4\. Some ordering of remaining cross-platform tools depending on requirements.
(React Native, Vue Native, Xamarin, Ionic, Titanium, PhoneGap, Kony...)

~~~
pjmlp
I have a different order:

1\. Just make a web page (specially since many apps are just pretty CRUD ones)

1.1 For certain devices WebGL/WebAssembly can eventually also be an option

2\. Native iOS & Android

3\. Native iOS & Android with server side driven code for the business logic
(maybe even UI layouts)

4\. Native iOS & Android for the views with C++ for business logic

5\. Your point .4 regarding cross-platform tools

I don't have high hopes for Flutter, with Chrome and Android teams also
pushing for their own solutions, and its dependency on Dart.

~~~
jamil7
Apollo Server and it's associated iOS and Android clients can make your 3rd
option really easy to pull off as it generates your CRUD logic and model code.

~~~
jdmg94
if only they could figure out their caching...

------
irjustin
I'm always scared of these headlines for companies who aren't greenfield.

Shopify is a perfect case for RN. Write once deploy both platforms. The issue
that gets glossed over is for existing apps that have to do the data and
abstraction layer on top of native codes. It starts to become prohibitively
expensive to maintain the native, RN, and data layers unless you're willing to
rewrite the native side.

Airbnb fell into this problem[0] and so did my old company.

I love RN for what it is and can do, but big companies that hop on and then
are forced to hop off because of internal politics makes it a difficult case
for RN because then it becomes "look, RN didn't work out for Airbnb or
Shopify..."

I hope for the best of luck and success to the RN engineers.

[0] [https://medium.com/airbnb-engineering/react-native-at-
airbnb...](https://medium.com/airbnb-engineering/react-native-at-
airbnb-f95aa460be1c)

------
sergiotapia
We're moving away from react native at Papa. Too brittle, too cumborsome to
iterate with, feels slow and every build required a prayer and small sacrifice
to Cthulhu.

We're using Ionic 4 now with capacitor, the dev workflow is much better,
literally testing on the browser with autoreloads when code changes. Couldn't
be simpler. So far I like it a lot. We're using React so it's just like
writing a SPA, only Ionic has a ton of UI elements out of the box like tab
navigation.

------
TheMagicHorsey
I wonder if Shopify did their homework and looked at Flutter. Flutter seems to
meet their objectives more than React Native does.

And as an added bonus, Flutter is easier to reason about, has edit and
continue, and is more performant.

Perhaps the use of Dart instead of Javascript was a deal killer though?

~~~
Androider
It would be pants-on-head insane for a company like Shopify to go all-in on
Flutter. Is Flutter going to be around 10 years from now? Can Shopify support
Flutter on their own if nobody else is using it 10 years from now? I don't
mean that technically the license would allow them to, but can they in
practice field the manpower and skills to do so across all the platforms they
need.

~~~
SlowRobotAhead
I don’t know much about RN or Flutter; but why is it “insane” that flutter
cant exist in 10 years but RN will still be king?

Why can’t RN die within 10 years? Because it’s been around since 2013 vs 2017?
Because you like one more than the other?

I have concerns about Google’s commitment to Dart/Flutter, but I’m not sure
one scenario is pants on head insane and the other just fact.

~~~
Androider
React Native could very well fall out of favor in the next 10 years, but the
amount of companies using it today means there is a sufficient base to share
the maintenance burden with, of which Shopify could potentially carry a large
amount because of the significant overlap with the rest of their tech stack.
If Google becomes disinterested in Dart, could Shopify step up and maintain
it? Seems unlikely, and why on Earth would they want to, it's nowhere close to
the rest of their competencies?

If for one technology you can extrapolate from today out to the next several
years at least, and the other's path is effectively entirely opaque and at the
whim of another party, it's a company-killer level risk to bet on the latter.
Put it this way, if Google drops Dart/Flutter tomorrow, Google will be just
fine as they have very little skin in the game so to speak. Technical reasons
one way or another are completely overshadowed by the business risks, as the
landscape is today (which will change over the years, but Shopify is making
their decision today).

~~~
SlowRobotAhead
Not to be TOO snarky but... I'm sure there are a whole bunch of Angular 1.0
people who said the same thing.

I'm not convinced it's a worse idea to guess lottery numbers than to guess
what will be successful languages. To that point however, React isn't a
language (or a framework) it's a library.

I would say Google has more to lose by dropping Dart and Flutter as a language
and frame work than Facebook has/had by dropping React.

------
hrpnk
Shopify is associated with e-commerce shops. It would be much bigger news if
this would be about an app for core e-commerce journeys, but Spotify builds
Apps mostly for the merchants or in-store use cases where customers physically
are already paying for a product. Performance matters less in such use cases
as merchants or customers are already locked-in in the purchase flow and a
drop out would be more costly for them (no sale). This is in no way comparable
to AirBnb use cases.

The use cases they migrated to React Native are rather simple - a list of
orders, which customers will choose to use in order to get the status of their
order - the customer's need is very high and optimization here does not bring
much business value (conversions). The POS use case is stronger due to the
expected responsiveness that is required, though it can degrade slowly over
time and will not be noticeable (boiling frog) like in phones.

~~~
jiofih
So what? A customer facing e-commerce app is nothing but search, a list of
results, filtering, a product page, photo gallery and checkout forms. RN has
no trouble hitting full native performance all around (I’ve watched multiple
apps built in this space).

------
KaoruAoiShiho
Can anyone from Shopify directly address the points brought up in the Airbnb
posts.

~~~
Androider
Shopify CEO expressed his thoughts on the matter quite succinctly
[https://twitter.com/tobi/status/1222551057798090752](https://twitter.com/tobi/status/1222551057798090752)

~~~
dmamills
The Shopify CEO is going to be pretty disappointed when he finds out all of
those diamonds are actually just npm audit fixes, dramatically out of date
packages, and strange platform specific behavior regardless of the "write
once, run everywhere" tagline.

------
wdb
I am always wondering what the difference is between writing three differents
targets, iOS, Android and Web using RN (even Flutter is a better choice imho).

Basically you want to share the business logic between them. You still need to
spend time to write UIs for iOS and Android which following interaction
paradigms of the platform.

Personally, I can't stand iOS apps that look like Android.

Currently, I am happily working on a project where I write all the business
logic in Swift and share between the web app (WebAssembly) and the iOS and
Android app. The only bit that I customise is the UI part. I quite enjoy this
approach.

(I have to admit for me writing native mobile app in JavaScript/TypeScript
feels wrong. Guess, I don't like that language enough)

------
chadlavi
the example react native code they give in this image would error out:
[https://cdn.shopify.com/s/files/1/0779/4361/files/ReactJSvsR...](https://cdn.shopify.com/s/files/1/0779/4361/files/ReactJSvsReactNative.jpg)

Text has to be in a <Text>

~~~
harrisonjackson
You cannot see the imports.

import {Text as View} from 'react-native';

All good!

~~~
chadlavi
this is truly evil

------
Nextgrid
Airbnb said the same back in the day. Guess what happened then?
[https://medium.com/airbnb-engineering/sunsetting-react-
nativ...](https://medium.com/airbnb-engineering/sunsetting-react-
native-1868ba28e30a)

~~~
mambodog
it's almost like different companies make different tradeoffs based on
different organisational needs and priorities

------
sandGorgon
Anyone know where React Native stands in modern development - especially when
compared to Flutter and the upcoming Compose.

All the native frameworks are also React inspired.

I personally love the work done by Airbnb for its Android MvRx framework.
Again, React inspired

~~~
jamil7
React and it's model are great. React Native on the other hand is leaky, heavy
and you'll spend a bunch of time fiddling with packages, upgrading them,
tracking down weird linking issues and ultimately writing some Objective-C /
Java code to debug / glue / fix whatever native API you're dealing with. Thats
only from my experience though. I would much rather the Compose / SwiftUI
direction.

~~~
gnusty_gnurc
This is exactly my experience too. It’s an absolute nightmare juggling three
package managers at once.

------
arbhassan
Meanwhile Shopify's CEO. [1]

[1][https://mobile.twitter.com/tobi/status/1222551057798090752](https://mobile.twitter.com/tobi/status/1222551057798090752)

~~~
sixstringtheory
Oof, not classy. I think every developer has had the experience where you
think you're so close to the finish, just one more thing... and then hours,
days, weeks have gone by. How can he be so sure they're going to strike it
big?

This is a pictographic sunk cost fallacy.

~~~
amikazmi
I read it as "they didn't continue long enough to get to the benefits, as we
did", i.e, they already reached the diamonds.

------
22byebye
<< Flutter vs React Native: A detailed Comparison 1\. Performance Mapping down
the performance is the best way to find the ideal framework for mobile app
development. Flutter is ahead when it comes to performance among other
frameworks is due to Dart. Dart code is compiled to native machine code. And
also the JavaScript layer is helpful when integrating with native components
and eliminates the JavaScript bridge.

React native offers exceptional performance for developers while developing an
application in a native environment. But developers sometimes face issues
while running the hybrid application architecture. On the other hand, Flutter
allows developers to reuse the existing code. Flutter is in the leads in
performance in comparison to React Native which uses JavaScript Bridge. >>

Source: [https://dev.to/agiratech/flutter-vs-react-native-what-to-
cho...](https://dev.to/agiratech/flutter-vs-react-native-what-to-choose-
in-2020-49ej)

------
garrettlarson
> As a contrast, none of the Top 10 most valuable Y Combinator companies use
> Java; largely considered the battle tested enterprise language.

I’m not sure what this is based on, but Airbnb uses Java pretty extensively.

------
BharathMG12
We did multiple experiments on server driven UI for our mobile apps.

1) Using native app - Sending layouts in JSON and using Flipkart Proteus
library in Android to render them. This only enables appearance changes and
not behaviors. So we really didn't server driven LOGIC.

2) Using Flutter - Wrote the wrappers for Flutter widgets. Those wrappers
basically just converts JSON to Flutter widgets at run time. And also enabled
actions to be server driven. The complete app was made server driven using
this approach. The only problem is, too much of abstraction in the client made
the code base very messy and hard to reason.

3) Using React native - The biggest selling point for using react native is,
codepush feature. We didn't have to write dumb client wrappers which expects
JSON from server. We can just write normal JS code and deliver it to client
devices without making app update. This enables really rapid experimentation
for product features. We are currently developing this.

------
dana321
I'll just leave this here.

[https://devrant.com/rants/320156/i-hate-react-js-with-a-
fuck...](https://devrant.com/rants/320156/i-hate-react-js-with-a-fucking-
passion-it-sounds-great-on-paper-but-once-your-pr)

------
burnJS
I guess I'm old, but I can't believe that many people shop on their phones.
You have limited screen space and your ability to input data efficiently is
limited. It just seems like a really poor medium for researching a purchase.
Guess I'm a dinosaur.

~~~
TulliusCicero
I shop on my phone, mostly Amazon. Probably not for serious/expensive
purchases, but there's tons of things that don't qualify for that.

I buy a lot of kids' books, for example, I just look at the cover and
description, read some reviews, and pull the trigger. Lots of little
electronics too, like cables/adapters.

------
hota_mazi
And in a couple of years, "Why we are moving away from React Native at
Shopify".

Not slamming React Native but the sensationalistic headline. Anyone with a bit
of experience in software should know better than making this kind of silly
proclamation about the future of your software stack.

~~~
sschueller
I have not seen one good app for android that has been written in react
native. Can anyone show me one that doesn't suck in performance?

~~~
chrisco255
Instagram.

~~~
deminature
Instagram has very limited parts of the application written in RN, like 'Edit
Profile'. [1]

The vast majority of the app is implemented natively.

[1] [https://instagram-engineering.com/react-native-at-
instagram-...](https://instagram-engineering.com/react-native-at-instagram-
dd828a9a90c7#.3h4wir4zr)

~~~
chrisco255
That article is 3 years old, but it mentions "Photos Of view", "Post Promote",
"Save Posts", "Checkpoints", "Comment Moderation", "Lead Gen Ads", "Push
Notification Settings", and "SMS Captcha Checkpoint". At any rate, I'm curious
to see how this has evolved over the past 3 years and I remain impressed with
their seamless integration of RN and native.

------
mellosouls
This is an interesting read and may be the full story, and a completely
justified strategy.

But at the risk of sounding cynical, I'd be interested in any political
motivations - if he's a new VP, it wouldn't have been unheard of for
unnecessary swashbuckling Transformation Projects to be kicked off under the
new regime for no obvious reason.

Complete conjecture, I have no inside knowledge, just have seen this happen
time and time again.

~~~
brailsafe
It happens all the time. At a large corporate place I was working frontend at,
our dpmt manager spent almost no time with the teams and all time concerned
with outout metrics. When his boss looked to be retiring and the prospect came
up to get his job, he started a new year by—seemingly with no knowledge of how
things were working—by shuffling all the teams based on how he thought people
should be organized. He then kicked off two or three major tight deadline high
budget projects with those new teams, and proceeded to take a vacation.
Needless to say there was a lot of turnover, I got terminated, projects
failed, and he got his promotion somehow.

~~~
mellosouls
Yep. I'm more than a little sceptical these days when these big projects are
announced - especially with new managers.

------
topherPedersen
As a solo/indie developer I love React-Native. Attempting to develop for
Android and iOS at the same time is absolutely daunting. Maybe someone out
there can do it, but it was simply too much for my brain to handle. But with
React-Native I don't have to worry about any of that. I just write code and it
doesn't matter what device people happen to be using.

------
xyby
Is there a reason that the web is not a target of react native?

It seems somewhat insane to have a cross platform approach and leave out the
biggest platform of all, the web.

Or - looking at it the other way round - what approaches are there to take a
working pwa website and turn it into an app? What advantages over such an
approach can react native bring to the table?

~~~
yesimahuman
The Ionic team recently released React support so you can build a PWA using
React and target iOS, Android, web, and electron. Uses Capacitor under the
hood for full native access. It’s been getting a lot of usage since the
release: [https://ionicframework.com/blog/announcing-ionic-
react/](https://ionicframework.com/blog/announcing-ionic-react/)

~~~
WorldMaker
Also you can use Capacitor with any PWA-style web application without using
any of the rest of the Ionic Framework.
[https://capacitor.ionicframework.com/](https://capacitor.ionicframework.com/)

It's currently the best maintained successor to PhoneGap/Cordova.

------
awinter-py
low quality of tooling in mobile has been a reality forever and the vendors
are not only unwilling to change, they've doubled down on poo-flavored
buildsystems that are impossible for the community to fix

this stuff is life or death, and also _impossible_ without giving up on
native:

> React Native on both iOS and Android and shares 95% of the same code

> less crashes on iOS than our native iOS app

> an Android version launched

> team composed of mobile + non-mobile developers.

( _impossible_ on native because of the multi-day process required to build an
ios app for the first time)

> The team also came up with this cool way to instantly test work-in-progress
> pull requests. You simply scan a QR code from an automated Github comment on
> your phone and the JavaScript bundle is updated in your app

code updating is illegal on the app store, but it's hard to kick out shopify.
this is a shot across the bow

~~~
tannedNerd
"(impossible on native because of the multi-day process required to build an
ios app for the first time)"

What??? how is it multiple days to build an app for the first time? It takes
minutes and if you are being pedantic by including App Store review it tends
to be under 24 hours for new apps and under 6 hours for app updates now. Plus
you can distribute to your own team instantly through TestFlight.

~~~
awinter-py
installing the right version of xcode & getting required libraries -- my
experience may have been particularly bad because of the ios 13 / swift 5.1
release, but the fact that these tool versions are linked to the xcode version
is the root cause here

~~~
kerbs
Devils Advocate:

Fiddling with React Native tooling on day 0 is just as terrible. I may argue
it's worse.

------
deltron3030
Strange that they didn't mention hiring as a reason, it's maybe even the main
one. React is for the frontend what PHP was for backends in the 2000s, that's
what most frontend devs know. Svelte would be a better fitting comparison to
Rails in 2004.

------
apl002
All I can is, as a RN Developer, I love it. I love being able to use 1
language for both app platforms. The RN community is amazing. Many of the
comments here talking about outdated packages were likely burned by RNs early
days when it was <0.40. RN has come along way since then. Its been a while
since I ran into an issue updating packages or couldn't find a lib for
something I needed. There is also great resources when you want to handroll
something yourself.

Migrating an existing native stack to RN might not be the answer, but anyone
looking to get their startup off the group should consider RN. Its fast
development and converting a React web dev is super easy.

~~~
tannedNerd
And I as a mobile native developer for both android and iOS on the other hand
now know to skip talking with Shopify for future jobs as I hate RN and the
performance hits and non standard UI it introduces. So we both win!

~~~
tekstar
The sad thing is, all* their tier 1 mobile apps are still ios/android native
and are not going to be rewritten, so they still need native devs. But after
this blog post native devs will be a lot harder for them to find and hire.

* except for POS for Android which apparently has been rewritten, but not yet released, in RN.

------
fredgrott
Let's see directly couple UI front end to OS updates...yeah that will really
speed up cross mobile platform development won't it?

Or one could decouple completely which is Flutter's main mission as a front
end framework

Sounds like some CTO-type in over their head

------
ChrisMarshallNY
I used to be a cross-platform framework skeptic _(Disclaimer: I have written a
LOT of cross-platform, low-level code over my career)_.

I am less of a skeptic, nowadays. I think that it makes good business sense
for most connected apps. Also, the quality and stability of the frameworks has
increased.

It really stinks to spend two years training your team on a framework, only to
have said framework suddenly float to the top of the tank, belly-up. React
seems to have settled in for a long stay. It's kicked its shoes off, and
grabbed the remote.

That said, it won't affect me. I tend to write stuff that controls devices, so
my code needs to be pretty "bare bones" native.

------
nojvek
I’m a bit bullish on ReactNative. Well on UI controlled by JavaScript that
work a consistently across different platforms.

I acknowledge Flutter from Google is making rounds but Dart simply doesn’t
have the ecosystem and reach that Javascript does.

Standard web html always seems to be quite laggy in mobile browsers. Basic
things are quirky like the location bar is conditionally visible when
scrolling up but not scrolling down. This changes the viewport.

Web rendering doesn’t seem to be as efficient and rich as native UI.

------
jaimex2
15 years in the industry has taught me to always have an exit strategy.

React is the cool thing now but it wont be in 5 years. Make sure you can
decouple and reuse your APIs with whatever comes next.

And always remember that a native app will always give the best experience.
Cross-platform tools aren't perfect and sometimes the cost of 'write once
debug everywhere' is higher than 'write everywhere' especially if you suddenly
need to do something niche.

~~~
tebbers
I don't know about that. React was the cool thing 5 years ago, and 5 years
later it's still the cool thing judging by how many jobs are out there for
React and React Native developers.

------
linusjs
There is really no technical reason why mobile can't be predominantly web-
based now. Electron applications like vscode and figma show that you can make
great software without any native code. Combine this with the fact that newer
mobile phones are extremely fast, it just doesn't make any sense from a
technical perspective why we need to use native all that often anymore.

------
ronlobo
Curious to hear more about their deep dive into Native, Flutter and React
Native as possible technology choices.

Hopefully, React Native is not a nosedive ;)

~~~
k__
Flutter and React-Native are different directions, I think.

For higly customized UIs (think Ableton Live, Photoshop, Excel, etc.), I'd say
use Flutter, because of the non-native rendering, it will look the same
everywhere. Otherwise use React-Native.

~~~
oakesm9
Exactly this. They are very different systems.

Flutter renders onto a "canvas" and has a completely custom implementation of
"native-like" views for each platform. They need to reimplement everything
about platform views from scratch.

React Native lets the native OS render actual native views, but lays them out
and controls their properties using Javascript. You get the native behaviours
"for free", but you do sometimes end up in the lowest common denominator
position.

~~~
k__
Yes. The common denominator isn't as low as one might expect. I'd guess at
least 90% of all apps could be easily done with React-Native.

~~~
SlowRobotAhead
Sure. But what if the entire world doesn’t want to learn JavaScript? What if
you don’t already know HTML, CSS, and JS? RN makes ZERO sense at that point.

As a C developer, man, Flutter looks pretty damn logical!

~~~
k__
[https://mobile.twitter.com/LinguaBrowse/status/1220695261246...](https://mobile.twitter.com/LinguaBrowse/status/1220695261246382080)

~~~
SlowRobotAhead
I don't know if you read your own link or not, but he's first off complaining
about a community plugin and not an official one.

There is some truth that overlapping isn't well supported in Flutter
CURRENTLY, but I can think of things that were well supported in RN 4 years
ago either.

I can't think of a single reason I would want an overlay EXCEPT an alert, and
even then, I don't think he's right.

------
OzzyB
Shopify should stick to making ecommerce sites and leave the mobile
engineering evangelical space to those who's businesses are dependent on
mobile and have the necessary experience.

In short, the future isn't React Native, unless you have a time machine that
will allow you to go back and rewrite it.

~~~
Hates_
So even though they develop apps that have millions of downloads or that
businesses rely on for their in-store point of sales, you don't consider
Shopify qualified to speak on mobile development?

~~~
OzzyB
No, I don't consider an established tech company with "millions of downloads
that businesses rely on" choosing a webstack devkit for their mobile
development serious.

------
Andrex
Why was the title changed? It differs from the original article's, which I
believed was the guideline.

------
jammygit
Why do they begin justifying by talking about 70% of buyers using mobile?
Completely off topic

~~~
SlowRobotAhead
Isn’t that them starting by declaring that mobile is really important to them
so they didn’t take this choice lightly?

------
The_rationalist
Why not ionic react? [https://ionicframework.com/blog/announcing-ionic-
react/](https://ionicframework.com/blog/announcing-ionic-react/)

~~~
aikah
> Why not ionic react? [https://ionicframework.com/blog/announcing-ionic-
> react/](https://ionicframework.com/blog/announcing-ionic-react/)

React Native uses the Native Components of the platform for UI. Thus Native.
Ionic React is basically a web app, this is Ionic with React instead of
Angular.

So basically React Native == use native GUI components.

Ionic React = uses HTML/CSS in a webview embedded in a Native App, just like
Phone Gap/ Cordova, Ionic is just a framework on top of HTML/CSS, React Native
is not.

~~~
The_rationalist
Most react native apps have a custom UX but needs native plugin access. This
is the point of ionic react.

~~~
aikah
> Most react native apps have a custom UX but needs native plugin access. This
> is the point of ionic react.

No, most React Native apps use the Native platform UX, that's the point of
using React Native. As for plugin access, well I don't see how Ionic React
solves anything, since a plugin by definition needs to be developed in the
native language of the platform (Java or Swift).

------
tombert
I keep putting off learning React Native, largely because I don't really do a
lot with JS anymore.

I know that there exists ClojureScript bindings to React-Native...does anyone
here have any experience working with them?

------
jiofih
I’m really eager to hear how they deal with data in their RN apps. To me
that’s always the place where the most complexity and bugs lay hidden.

------
Jemm
Why emulate facebook’s app strategy? Their apps are a UX nightmare
Accessibility is horrendous as is power draw.

------
fmakunbound
Good for you Shopify, but I fully expect you’ll switch to some new hotness in
a year or two.

------
adechywakilidod
J'aime beaucoup l'application merci

------
yoshimiagava
This is amazing team for spotiteam and all users! Congrats!

------
adechywakilidod
Notification

------
ksec
I wonder if that mean Rails will be moving to React Native as well?

DHH [1] said they will reveal a major new technical direction for building web
apps.

[1]
[https://twitter.com/dhh/status/1214962255785119744](https://twitter.com/dhh/status/1214962255785119744)

------
glisom
Good luck, lol

------
bfrog
Good luck, you'll need it

------
gargs
Translation: we don’t see mobile experiences driving our growth.

~~~
ziftface
Why is that an equivalent statement?

~~~
LeoNatan25
If mobile was important enough for them, they would have invested in proper
mobile development. Clearly it is not.

------
canistr
"In order to best serve our retail merchants and learn about React Native in a
physical retail setting, we decided to build out the new POS natively for iOS
and use React Native for Android."

Unbelievable, really. The previous paragraph literally mentions the importance
of performance.

 _facepalm_

~~~
wdb
Why do they use RN for Android but not for iOS?

------
Despegar
Apple really needs to start using the stick more with respect to the inferior-
to-native cross-platform frameworks. I hope that's the strategy after SwiftUI
matures.

------
fredgrott
Hahaha ahaahah

gee what happens when Android Fuchsia hits oem devices this year? CES surprise
coming..

~~~
Androider
In the unlikely event that Fuchsia ever makes it out without being strangled
by the rest of the Android organization, or someone high-up waking up and
taking a look at it (eye of mordor style)... absolutely nothing? For the next
5-10 years at least as Android devices are slowly replaced in the marketplace
with Fuchsia through device turnover rates alone. You think Android version
upgrade stats are abysmal today? And you want to replace the whole base OS?
Good luck with that.

