
React Native: A retrospective from the mobile-engineering team at Udacity - phaedryx
https://engineering.udacity.com/react-native-a-retrospective-from-the-mobile-engineering-team-at-udacity-89975d6a8102
======
iOSGuy
Seems like both AirBnB and Udacity made the mistake of not investing enough in
the tech. If you keep building out full native features while transitioning a
brownfield app to RN, you’re going to have this fragmentation problem.

I’ve converted, (with lots of help of course), a massive brownfield platform
product to RN. It took a lot of work, building the right bridging layers,
retraining the team, figuring out best practice, etc. We still have a lot of
tech debt, but it works!

Pros: Solid cross platform development, easy to teach, easy to get up and
running on Xcode/Android Studio (running and working on both in first week on
the job), easy to teach the native languages from there, real time bug fixes,
fast iteration times on new features. Cons: No 64b on Android, Android
peformance lags behind iOS, RN bugs, build process was tough to nail down, no
built in navigation support.

We’ve now solved most of the huge RN exclusive problems we had with RN we had
when we started out, so at this point I’m not going to be abandoning it
anytime soon. There are still problems, but just your average engineering
problems, same as you’d get in native development land or any other platform.
It’s been about 3 years now, with a 10+ person team now, so maybe I should
write it all up somewhere.

~~~
jmhyer123
> It’s been about 3 years now, with a 10+ person team now, so maybe I should
> write it all up somewhere.

Please do! I'm about a year into a cross-platform app build on react-native
and I'd love to hear/learn from your experience.

~~~
spencerg12
Yes, please do!

------
txmjs
I'm under the impression, in Udacity's case especially, that part of the
problem stems from asking native engineers to use a language and ecosystem
that they're not used to working with, and then trying to get them to
integrate RN code into an established, brownfield native codebase.

As a sole dev in a 3-person startup, I’ve managed to build a pretty large app
with React Native, having zero prior native experience (although, that’s not
to say that I haven’t had to learn a _lot_ about Xcode!)

~~~
blizkreeg
Can I reach out to you? My team will shortly be starting out with RN to build
our mobile app. I'd love to get some pointers and advice on what we can do to
make it as successful an experience as possible.

~~~
axemclion
If you have questions, you can ping the RN team too. I would love to help !!

------
haney
So I'll state my bias up front. I'm a pretty happy non-native react-native
developer.

After reading this write up and AirBnB's write up about RN I keep wondering if
the source of the problem is more with integration points between native
features.

Like I said, I'm not a traditional native mobile engineer, but as a single dev
I've been able to build a rather large and complicated app almost entirely in
react-native. That's not to say that I don't use mobile features, I'm using a
dozen or so libraries for native features, but the common problem that seems
to arise is "this doesn't integrate well with the rest of our native app".
IMHO if you're writing business logic in swift/java instead of javascript
you're going to have a bad time. If, however, you use/implement narrowly
scoped native libraries that are glued together with javascript it's a pretty
nice experience.

I wonder if the issues that they encounter are more a symptom of trying to
"bolt on" react-native.

~~~
danpalmer
I think there are a few other major problems, but I think many apps are
unlikely to hit them in the same way that they are unlikely to have
integration issues with native code, because they don't need much native code.

Most apps only need to be a bunch of table views and detail views, with some
forms. Line of business apps that need to be efficient (not pretty) or that
don't use many of the advanced platform features, short lived apps for
events/marketing/competitions/etc, apps for restaurants or shops, these are
all places where I think React Native fits perfectly.

However, if you want your app to have the best performance (spoiler alert, you
probably don't), you want to be at the cutting edge of platform support, or
you want to create experiences that fit on the target platform perfectly, then
I think native is the way to go. Most apps do not need this.

~~~
Cthulhu_
> However, if you want your app to have the best performance (spoiler alert,
> you probably don't)

Actually you do. An app like Facebook, Instagram, etc are used for hours a
day; having a suboptimal performance directly translates to battery drain and
a poor user experience, which costs you money.

I'm sure someone smarter than me has a nice soundbite about using the best
tool for the job. React Native is a compromise. Web technology on mobile is a
compromise.

~~~
uitgewis
It's ironic you should mention apps like Facebook and Instagram[1]. They use
React Native.

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

~~~
orbitur
But they DON'T USE React Native in the main feeds of either Instagram or
Facebook. You know, where users spend all their time and performance matters.

You linked to a post about a bunch of settings/picker screens in Insta. On the
FB side, my understanding is that only the Marketplace tab is RN, and maybe
the settings & notifications.

------
maxdo
Airbnb complains had some real issues. Udacity “problems” looks artificial.
Animation Performance on old androids - and then agreed it’s non RN issue.
Android SDK 26 playstore limits only NEW apps at first and react 0.56-RC
support it, so plenty of time (4 month to adopt). Notch support was available
before first devices hit the market. I believe here is different beast -
programming language as a religion. One of my devs was really sabotaging
processes just because he hate JS.

~~~
LandR
> One of my devs was really sabotaging processes just because he hate JS.

To be fair, JS is a mess.

Although if I was a dev and asked to write JS, I wouldn't sabotage stuff!
Probably just leave and get another job.

Seriously though, what do you mean by sabotaging stuff? What form did this
take?

~~~
sodafountan
But to be even fairer, JS has evolved into quite a nice language to work with
over the last few years and I'd hope that developers who've used it in the
past would take the time to re-evaluate it.

~~~
LandR
Has it? My last look at it was a year or so ago and it looked like a shit show
I wouldnt want to touch with a barge pole..

Web front end and JS just seems like insanity.

I don't know how anyone can use node...

What would you recommend to someone averse to js to try and change their mind?

~~~
alangpierce
> What would you recommend to someone averse to js

I guess it depends on what your concerns are:

• If you're worried about too many libraries to pick from, I'd just go with
the most popular ones. React is a pretty solid choice.

• If you're worried about config being a pain, I'd recommend going with one of
the starter tools like Create React App. Build tools are indeed a bit complex,
but hopefully that's getting better over time.

• If you're scared by lack of type safety or worried about language quirks,
I'd recommend TypeScript. (Flow is also quite good.)

In particular, TypeScript (and Flow) provides much more flexible static typing
than I've used in any other mainstream language. You get the nice navigation,
autocomplete, and static checking that you'd expect from a typed language, and
I've found that I spend much less time needing to think about how to write my
code in a way that appeases the type system.

Here's a tutorial that hits all of the points above:
[https://github.com/Microsoft/TypeScript-React-
Starter](https://github.com/Microsoft/TypeScript-React-Starter)

------
dave_sid
It’s incredible the lengths intelligent, experienced developers will go to, to
avoid learning iOS or Android development. It’s a small bump to overcome to
unshackle your project from an ever changing comfort blanket between
yourselves and the platforms, that inevitably lags behind and is ultimately a
comfort blanket that’s future is always in the hands of a third party. If your
developing iOS and android apps in JS, then you’re smart enough to get stuck
into Xcode/Swift and Android/Java, and you’ll probably never look back. Sounds
like most RN devs find themselves in the trenches often enought as it is.

~~~
chrisco255
Software development is already crazy expensive. Do you know how much it costs
to build and maintain web, iOS, and Android apps? It's ridiculous. It's not a
matter of not wanting to learn each platform. As Udemy pointed out, they ended
up with 4 devs on each platform. They also have who knows how many devs on web
and platform / backend services. Udemy is a successful product with market fit
I'm sure they're doing fine either way, but for many startups this kind of
efficiency can mean life or death. Not many can afford to burn through
$100-$200K per dev just to reinvent the wheel wiring a bunch of REST calls up.

~~~
mncolinlee
That's precisely the point. Airbnb decided they were now maintaining web, iOS,
Android, AND THEN React Native instead of only web and React Native. Their
costs went up, not down.

I've found far too often over the years that companies decide to use a hybrid
framework to save time and money and take just as long to write the app with
equally as much cost. Then no one wants to maintain the finished product. It
requires too many unlikely skill sets and trickier debugging.

React Native isn't automatically cheaper because it's a hybrid. Hybrids work
great for trivial apps that look a lot like the examples. A hybrid framework
also has to address every new niche the native solution fills or else
integrations themselves add up to a massive cost.

~~~
dave_sid
Yes I agree. Hybrid platforms always foster great productivity at the start.
In the early days it’s like “wow, we just produced two apps in no time at all
with one codebase”. But eventually the curve plateaus, and its more like “for
F __* sake, I just want to access the camera api one the phone!” I feel that
you eventually spend more time in the later stages footering with the corner
cases, than you saved in the early stages by getting it up and running
quickly. Also, when React is dead, you’ll find it much easier and cheaper to
find native developers, and more living documentation /support for native
apis.

------
kevinsd
While React Native is constantly being improved, to use it in its current
form, one has to be very aware of its under-developed parts, and more
importantly, make them aware of by designers and PMs.

Surely for any "fancy" feature one may think of doing with RN, there are
always some libraries, plugins, tutorials, solutions that exist in the vast
ecosystem trying to help. But more often than not they eventually lead into a
maintenance/integration nightmare, simply because how fast the whole mobile
industry moves and leaves things behind.

Therefore, I suppose that a wise approach is what I would call "React Native-
first design": let the whole team (PMs, designers, devs) know that anything
that is not officially supported by React Native and without caveats is off
the limit -- just try to avoid the design until it is fully supported.

~~~
blub
Well, that's certainly a novel approach.

Usually technology is used to solve business needs, but in this case the
business has to adapt to the limits of a particular technology, even while
other technologies offer the full range of features any business might need.

~~~
haney
All engineering requires trade offs, in this case you’re trading productivity
in one area vs flexibility.

~~~
filleduchaos
All engineering may require tradeoffs, but when you're so prioritizing
developer experience over the actual business that you're dropping perfectly
viable features just so you can cling to the illusion of increased
productivity, perhaps it's time to take a step back and reevaluate things.

What use is "productivity" without a performing _product_?

~~~
Jare
MVPs are mostly about that. Unless a fancy feature not supported by RN is a
necessary part of your core product, productivity takes priority.

~~~
filleduchaos
And is the app going to remain an MVP forever?

~~~
Jare
No, but the ability to produce an MVP within the limitations (time, budget,
opportunity, etc) may be what allows having an app at all.

------
voidr
> 1 iOS dev > 2 Android devs > 1 PM > 1 Designer

They didn't have a single JS/Web developer at the start.

> There was also an issue that caused a crash because one version of npm had a
> `package.lock` and the other didn’t which caused us to install incorrect
> versions of a dependency across a React Native upgrade.

This issue I would attribute to their lack of experience or knowledge of how
NPM works, not to ReactNative.

> Lastly, CI for the iOS project was a pain point as well. We now had to add
> an npm dependency layer and make sure those were being updated properly
> before continuing the install. This added nontrivial amounts of time to our
> build step.

The same way if I would add Java to my JavaScript project, my build time would
increase.

There are a lot of legitimate complaints in the article, but a lot of their
issues stem from their lack of web experience.

~~~
akura
Yeah, the team makeup is the interesting aspect for me. It seems they took an
existing mobile engineering team and had them integrate react native.

Our experience was opposite in that we had a web/js team and decided to go to
react native as a way to deal with a mobile app that we couldn't maintain well
(and couldn't justify the hiring of dedicated devs for).

React native gave us an avenue to utilise existing skills and overall we found
it pretty positive.

------
jokoon
Look, cross platform is already a lost cause as OS manufacturers will always
departs from competitor design flavors, so that it will be costlier to adapt
to other platforms, so each OS manufacturers can have loyal developers who
won't write code that work on competitor's platforms. This has been happening
for ever.

Secondly, how many time is it necessary to whine that javascript is a bad
technology, and that anything that stems from it is destined to less than
optimal ends?

JS is great but only for deployment, and it has been its best strength, but JS
cannot thrive on mobile, because mobile platform don't offer programming
flexibility. Less memory, tighter chips, less battery. Converting from one
language to another, and adapting design so it can fit is hacky.

Why does everybody is always jumping in on brand new shining ships?

------
q-base
A very good and nuanced write-up. React Native seems to get a bit of heat at
the moment, or perhaps I am just paying more attention to the content, as I
have just started building a project with it.

But nevertheless I am still sticking to it with what I have read so far.
Building from scratch with no iOS or Android experience, but some "normal"
React experience(and a lot of .Net experience) it seems like a no-brainer in
my situation.

The issues I have gathered from numerous articles seems to relate more to
existing teams with experience in iOS or Android. Or projects that have had
high growth.

Starting out from scratch those issues are not of concern. I will deal with
them if/when I get there. My main reason for using React Native is to build
something fast that can target both iOS and Android at the same time. And they
rightly also point to that as a good reason for selecting React Native in the
end of the article.

------
nebulous1
Some of the criticism is valid, such as the performance issues and the fact
that overall they didn't feel that it was worth it, the issues with the speed
of the ecosystem.

Some of it isn't valid. Build times increasing when you add RN to an existing
project is to be expected. If you want very different UX on each platform then
you'll generally have to implement it (as you would anyway).
Internationalization is always a task, he's unclear why React is being
criticized for this.

Overall my takeaway is that if you're looking for an app customized to the UX
of each platform, and that's more important to you than having devs who can
cover both platforms, then RN is not the way to go. They seem to feel that the
work involved in producing the RN features was greater than the work involved
to just do things natively twice.

~~~
chrisco255
If they're only using React Native for 3 or 4 features (as they say in the
article) I could see how adding in i18n support would be challenging as you'd
now have to maintain Java/Kotlin, ObjC/Swift, JS versions of this. But thats
just true of the whole approach in general. I think if you're using RN for
only 20% or less of your product, it probably is more trouble than it's worth.

------
thawab
Thanks, the post answered most of the questions I might have if a team used
react native and decided to switch to native code.

Would love to hear your opinion about the last post in react native blog:

[https://facebook.github.io/react-
native/blog/2018/06/14/stat...](https://facebook.github.io/react-
native/blog/2018/06/14/state-of-react-native-2018)

~~~
mncolinlee
2500 commits seems shockingly low for all of Facebook. Doesn't that seem like
there's some hardcore users and a lot of tepid users just kicking the tires?
My "pizza" team at Amazon did almost that many commits in a year on mobile
projects and we always rebased changes.

------
Mc_Big_G
These retros are surprising. I tried RN for one day and realized the massive
limitations and eventual need for native libraries and tools. It seems so
obvious.

------
TekMol

        Android apps being required to target api 26 by August 2018.
    
        The urgent need for safe area support for the iPhone X.
    

Reading about these annoyances of native development reassures me to keep
building web apps. They are so much more future proof.

~~~
pjmlp
Sure, because handling div soup and CSS across browsers is so much fun.

[https://www.youtube.com/watch?v=eVnUDTtOLE0](https://www.youtube.com/watch?v=eVnUDTtOLE0)

~~~
hesarenu
get familiar with modern web development!

~~~
pjmlp
I am painful familiar with web development!

~~~
jazoom
GP said "modern"

~~~
pjmlp
I am painful familiar with "modern" web development!

Happy for being pedantic?!

~~~
jazoom
It's not pedantry. That word was the whole point of his/her comment!

And if you're painful (sic) familiar with modern web development why are you
still creating div soup?

~~~
pjmlp
I don't know, maybe because web components still aren't a thing across all
deployment targets?

That Web designers are still playing catchup with native RAD tooling from the
90's?

That React devs so enthusiastically re-discovered how 90's UI were keeping up
to speed with slow hardware?

Or maybe because GPU acceleration requires CSS tricks with Z-Order to actually
work?

~~~
jazoom
None of that has anything to do with my question, but okay. Never mind.

------
CGamesPlay
Great read. There are obviously lots of different issues here, but the biggest
takeaway I have seems to be: Udacity wasn't building a single app that ran on
multiple platforms. They were building 2 separate apps that each ran on a
single platform, and there happened to be a lot of overlap which made React
Native look appealing.

It turned out that the overlap wasn't enough, or else the team would not have
done things like ever allow a feature into the tree that didn't work on both
platforms before merging (i.e. let the trees get out of sync). Useful to
consider before you adopt React Native in another app.

------
_alexander_
Is it the new trend to publish articles about moving from React Native? :)

~~~
meiraleal
I hope it produces a "counter attack" from RN the same way the trend about
moving from React because of its license made Facebook remove that patent
thing.

~~~
danabramov
What do you mean by a "counter attack"?

React Native usage at Facebook is growing. We know there are issues around
integrations with existing native code, and they've been the motivation behind
the ongoing large-scale changes in the internal architecture (which started in
the beginning of this year).

We posted about those changes a few weeks ago so you might be interested:
[http://facebook.github.io/react-
native/blog/2018/06/14/state...](http://facebook.github.io/react-
native/blog/2018/06/14/state-of-react-native-2018)

Once that work is done it should make integrations with existing native code
much easier. You can see that some of the post's content directly matches the
pain points listed by Airbnb and Udacity -- because we bumped into the same
problems and are working on the solutions.

------
untog
I wonder whether React Native was just a _little_ too late to arrive. As
someone with a majority JS background I could never quite get into Objective C
(I never tried that much to be fair, just hobbyist stuff) but took to Swift
immediately. There were enough rough edges around RN when I played with it
that I preferred simply working with Swift directly.

The one exception to this is cross-platform stuff. I wish Swift could compile
to be used on Android easily, but alas.

~~~
mncolinlee
There's always Kotlin, which adds a lot of the niceties of Swift when writing
Android code.

Kotlin also works on iOS through AppCode and Kotlin/Native, but that
integration is still very young. I can't promise you won't have platform
issues along the way.

------
ItsMe000001
For our use case RN has two major features missing:

\- No file system access. We use react-native-fetch-blob (to which I actively
contributed to add missing features and improve the code) which itself has
quite a few disadvantages, such as a disappearing maintainer (fortunately a
new one was found after a while, but the whole code has a few issues)

\- The only way to transport binary data across the JS-to-native bridge is
base64 encoded strings (expensive, has to be encoded and decoded on each side
of the bridge) - if you need to read (raw binary) files and send them via
websocket streams, as we do, you are screwed (I'm going to change the app
design only because of RN so that this can be done within the native code
without going through JS code)

~~~
loftyal
[https://docs.expo.io/versions/latest/sdk/filesystem](https://docs.expo.io/versions/latest/sdk/filesystem)

~~~
ItsMe000001
That's not RN but Expo on top of it.

We tried Expo and very quickly decided against it. I forgot the reasons,
somebody else did it and reported the findings and we all agreed.

Besides, why would I add an entire pretty big layer on top of still beta RN
(version number well below 1) only to get one tiny component? That only makes
sense if one wants the entirety of Expo, and this is where our tester (if we
should use it) quickly ran into numerous issues.

I understand that it's en vogue to immediately point to this or that npm
package or github repo for every problem big or small, but we don't do that.
We look at the sources of every package we include, and we look at possible
maintenance issues. Our own stuff is trouble enough, we don't need the added
problems of all those layers on top of layers of "stuff". I know it's "move
quickly and sort it out later when the business has grown" \- but we don't
want to work like that whenever we can avoid it. Because we don't have an
"exit plan", we ourselves will have to maintain the mess we create now...

------
Apocryphon
It really does seem like that a commonality between the AirBnB apps (huge
team) and the Udacity apps (much smaller team) is that both introduced React
Native to preexisting apps. If they were designed and created with RN in mind
from the ground up, the experience would be likely different. However I'm not
sure if there's such a case study for any prominent app using RN complete- not
even Facebook's apps. Instead, most of these are hybrid, between native and
RN.

------
sebringj
My issues have been related to difficult builds at times and hard to fix
performance problems but my use case demands better performance with videos in
a feed streaming as you scroll down when viewed. I would say react native is
not bad when you keep things light and simple but go native when you have
critical performance. you'll find that instagram uses rn in certain parts like
that, definitely not on their feed and on their filters or AI related filters.

------
0xfeba
I can concur with the breaking changes point. That and unmaintained libraries.
It seems after a certain size you need to devote 10% of your time to just
trying to keep libraries up to date security wise.

And then libraries get abandoned. "Your still using LibA? Switch to LibB!";
"Critical vulnerability! Upgrade LibX now! See migration guide to go from 1.2
=> 9.1" literally 30 times across our projects...

------
amelius
How does it compare to Flutter?

~~~
cmjqol
Flutter has it's own issues.

First , flutter uses an architecture similar to a game and uses it's own
rendering pipeline and Layout system, meaning integrating with anything that
exists is extremely challenging ( Chartings , Lottie etc... ) you'll be often
waiting behind the Flutter team to implement the feature inside the engine.

On top of that the SDK supports for Darts right now are non-existent, maybe
it'll change in the future , but Firebase + GCloud is pretty much all you'll
get in terms of SDK as of now.

------
stanq
Great! I'm finished React/React Native course at Udacity a couple month ago.
But now, they don't use it.

------
Fifer82
All in all is it still a terrible idea to try to build native apps with HTML?

In my experience going back to Phonegap, I have tried many evolutions of these
products over the years and all of them are terrible. Like unusable. 3fps and
unresponsive.

Is React Native a new generation, a new stable outlook, or is it simply making
React 3fps and unresponsive?

~~~
lwansbrough
React Native is native. There’s no HTML. You’re using JSX (probably) which is
basically XML in JavaScript (it’s not as bad as it sounds) to build _native_
UI. Can’t stress the native bit enough.

Where React Native differs from truly Native is that UI orchestration is
batched into chunks on the JS side and sent asynchronously to a native
receiver, which then applies those changes to the native side. This means that
currently if your JS thread gets blocked, or the main thread gets blocked,
your app will snag. Performance is a top priority for React Native and it
mostly fulfills that goal too. It’s not hard to keep your app running at
60fps.

~~~
wvenable
React native is an abstraction layer. It has all the problems of any
abstraction layer has ever had on any platform that has ever existed. The
lessons from this article (that is 15 years old) is still relevant today:

[https://www.joelonsoftware.com/2002/11/11/the-law-of-
leaky-a...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-
abstractions/)

Using the term "native" to say something is "not HTML" is sort of
disingenuous. There is just a whole different custom layer in the middle
instead.

~~~
ricardobeat
Not disingenuous at all - all the rendering code is _native_, no subtle hidden
meanings. No webviews, no custom drawing, all existing platform components -
that's as 'native' as you can get.

~~~
wvenable
By that argument, all the rendering code in my browser is also native. The
browser takes a markup language and CSS and renders this text using native
components.

React Native takes smaller markup and a subset of CSS and renders it using
native components. So how is that as native as you can get in comparison?

I agree that layer between markup and native controls is thinner in React
Native but the actual abstraction is actually very comprehensive. iOS and
Android applications are constructed quite differently from each other. And
React Native is itself different from that. It has an entirely different API
with a whole different model for how applications are made. So much so that
the platform differences are almost completely papered over. So is _that_
native?

I disagree that the idea of "native components" trumps the fact that
practically everything you do in React Native is different from the underlying
platform. Ultimately that seems like the least important detail. The
abstraction is actually what makes React Native useful but it shouldn't be
sold as "native".

------
mromanuk
IMHO, The promise of multi-platform dev is sharing code and reusing resources
(including developers) which generally comes subpar with native developing for
several reasons. Having 2 separated teams of iOS and Android, they should
aimed for native in each platform.

------
abledon

       > At other times, React Native lags behind in the adoption 
       of new platform requirements such as Android apps being 
       required to target api 26 by August 2018.
    

Just keep moving the target, good strategy to mess them up.

------
raprp
Thanks for the feedback. We've started investing heavily on RN and I was
starting to get worried seeing big companies jumping ship.

------
arisAlexis
so basically you hired more android and ios developers and they kicked out RN
while the whole purpose of it is not ti have dedicated mobile developers.
sounds like your taxi drivers would not like uber too..

------
abledon
React-Native... the new Metor.js

------
jacksmith21006
Really think Flutter will eat into a lot of React Native use.

So far really loving Flutter. The hot reload speed is just incredible. Plus
there is some unusual features.

One is widgets keep state so can go directly to where you were already at when
developing. This makes you a lot more productive and experiment a lot more.

The other is able to be somewhere in the app your are coding and just click
that page on the screen and takes you to the code behind it.

Also it does look like Flutter is the future as the native UI for Fuchsia.

~~~
spiritcat
waiting for react-flutter here

~~~
SneakerXZ
What would it do? Flutter uses same approach to UI.

~~~
spiritcat
I guess just looking over the flutter docs, I'd miss jsx too much. Also
hopefully a more stable backend to target with less differences between
platforms.

------
hecontreraso
"We removed the last traces of React Native from the apps because the only
remaining React Native feature was being sunset and we no longer had to
support it."

I didn't expect a clickbait from a serious company like yours.

