
Ask HN: Companies who adopted React Native over a year ago, do you regret it? - tekstar
I&#x27;m interested in the opinion of React Native from companies who chose to build their mobile apps with React Native and have been doing so for at least a year. RN passes the first-week smell test really well. How has it held up for you in production? How has it held up for dev teams of ~10 or more? Pros and cons?<p>I run a mobile team of ~30 folks. In 2015 we experimented with RN for 3 months before deciding that it was not a good fit for us. I&#x27;m interested in stories from the alternate reality where we took the react-native path instead.<p>I&#x27;m NOT particularly interested in stories about single devs making prototypes for a weekend. React Native has a delightful experience for this use-case, but it does not directly transfer to being a good experience for a larger team with serious product goals.<p>Thanks
======
dan_manges
We have a 15-person engineering team and converted our mobile app to React
Native at the beginning of this year. We do not regret it. Our pace of
delivery is much faster with React Native than what we were able to achieve
building natively. Our app has over 100 screens, and only needing to implement
features once to have them on both platforms is nice. The feedback loop when
making code changes is much faster, especially when writing unit tests. There
are some rough edges, but the benefits far outweigh the costs for us.

Our iOS app: [https://itunes.apple.com/us/app/root-car-
insurance/id1021256...](https://itunes.apple.com/us/app/root-car-
insurance/id1021256908?mt=8)

Our Android app:
[https://play.google.com/store/apps/details?id=com.joinroot.r...](https://play.google.com/store/apps/details?id=com.joinroot.root&hl=en)

~~~
snarfy
It benefits your dev team, but does it benefit your customers?

How's the battery usage of your RN app vs a real native app? Does your app
require the latest phone hardware to run with decent performance?

~~~
GBKS
As one of the designers of this app, I was skeptical initially if there would
be restrictions on customizing common UI components, the smoothness of
animations/interactions, usability, performance, etc. You definitely have to
put in a bit of extra work (isn't that always the case with making things nice
though), but you can get very nice results (and battery usage) with RN for
sure on both Android and iOS. Personally, I think it does benefit customers to
be able to quickly roll out iterations across operating systems at a high
quality. YMMV though, what works for one team, industry and customer base
naturally doesn't automatically work for everyone. Do you maybe have
experience or data points on RN vs. native in terms of battery usage and
performance? Would love to hear any insights you can share. Thanks.

~~~
snarfy
One of the reasons I brought this up was a recent article about energy
efficiency of programming languages.[1] JavaScript is ~2x less energy
efficient than Java, so it will eat twice the battery.

[1] [https://sites.google.com/view/energy-efficiency-
languages/re...](https://sites.google.com/view/energy-efficiency-
languages/results)

~~~
b_t_s
"so it will eat twice the battery" may be nearly true on headless boxes
running CPU heavy workloads. Mobile apps are about as far from that as you can
possibly get. Sure it's probably a measurable impact, but I would expect it's
less of an impact than things like how bright the backlighting is, whether you
keep GPS usage to a minimum, how well you minimize and batch network
communication, etc, etc. CPU is a small part of a phone's power budget and
mobile apps spend a lot of time with the cpu largely idle.

------
whostolemyhat
Yes, we regret it. Our app is just a wrapper around a webview, and handles
things like in-app payments and SDK integrations like Facebook login, in a
team of ~10.

Our version of React Native is quite far behind which makes using libraries
not already in the project difficult: you have to track back through versions
to find a compatible version, which then may not be doing what you want since
it's an older version.

We're also having trouble upgrading the version of React Native due to
versions having breaking changes. I know it's technically still not v1.0, but
in reality a lot of companies are using it so having a stable version would be
nice. Since it's unstable, many libraries haven't updated to compensate so you
run into the same problem as above, tracking down precise versions of
dependencies which also still do what you want.

The build process feels pretty rickety and seems to rely on a lot of global
state - I spent a while checking how we could update dependencies, but when I
rolled back to a stable version I was unable to build even after re-installing
node modules etc. I was only able to fix it after opening Xcode, removing all
pod libraries and re-adding them; I have no idea why that worked, and there
are very few clues on Github or Stack Overflow as to what specific errors
mean. Fixing my build step took the best part of a day.

Overall, for a small app like ours, we're just spending far too long on non-
development overhead, like fixing build systems or checking dependency
versions, and will probably move to native versions at some point in the
future. It may be a pain maintaining two separate versions, but we'll have
solid integrations with payment gateways and lots of documentation and info on
Github/SO for problems.

I like React and the idea of React Native, but at the moment it just feels far
too unstable and unpolished to use. I'd like to use it in the future, but
probably not until it's had a major version release.

~~~
woah
Why are you using RN if your app is just wrapping a web view?

~~~
johnwheeler
If you have to ask questions like this, you haven’t been working in the
industry long enough.

~~~
gt_
Haven't been in the industry long enough to do what? Ask questions? It appears
you have been working in the industry too long to answer them, which is much
worse.

~~~
libria
> Haven't been in the industry long enough to do what? Ask questions?

To be jaded.

It's merely a jab at the way we tend to overcomplicate solutions to simple
problems. I think.

~~~
johnwheeler
Yes, that’s right

------
lilactown
The team I'm a part of (~14 people) started building two new Android apps and
transitioned our iOS apps to React Native a little over a year ago.

Overall, I would call it a great success; we have four apps (2 iOS and 2
Android) built from the same codebase, soon to be 5, and React Native has
allowed us to be incredibly nimble in developing the framework and features
for them.

Some things I do regret:

1\. We didn't go all in on React Native, keeping large portions of code in
native in case of performance or security needs.

This means that any given feature requires iOS, Android and React Native
development. All of us are now fluent enough in each to do the work, but the
context switching and debugging of actions moving across the bridge are a
velocity killer.

2\. We didn't realize that RN's cross-platform integrations testing story was
so poor; we thought that we'd "just use Appium, it's perfect." Nope - design
decisions made by the React Native team actually make Appium unusable for our
Android apps.

This has forced a lot of churn in our testing strategy and we still have a lot
of manual testing at this point. This is, IMO, the #1 thing that should be
focused on either by Facebook or the React Native community.

~~~
EngVagabond
I'm on the React Native team and focusing on testing. Can you elaborate on
your experience with testing and what you'd like to see?

------
erik_landerholm
Absolutely not. We went all in on it. We even developed our own open source
framework based on it called Gluestick. It's original purpose was to make it
automatically isomporphic by running the same code in the browser as on the
servers, using node.

We also built a component/style library that allows us to make responsive
designs into web and mobile apps quickly and easily. Gluestick also allows
easy creation of native apps (native/react native/web views) with 90+% code
sharing. We also added a bunch of features (regex based routing, etc) to help
with seo. We do all of this from our single framework based on react.

We had a lot of front end 'frameworks' in use and no consistency. Now we do.
It's been a lot of work, but for us totally worth it.

We also have done a bunch of optimizations to make react fast, including how
we handle webviews in a react native/native app. It's seamless. I'd like to
link a video, but proprietary work that isn't done...blah blah blah, company
secrets, blah blah blah. We will be releasing another blog post, detailing all
the native enhancements soon.

~~~
morenoh149
what's the company name?

~~~
askmike
TrueCar is the company behind Gluestick.

------
t1amat
I have been leading two React Native projects for most of 2017 with experience
using the platform since early 2016. I would definitely recommend it today.

The two pain points have been 3rd party native modules and platform upgrades
but both situations have improved greatly in the last year. Both the platform
and the major 3rd party native modules have stabilized a lot, and platform
upgrades are pretty easy via the react-native-git-upgrade tool.

I've used React Native with a number of languages: JavaScript, JavaScript +
Flow, TypeScript and ClojureScript. All of the above, and soon, if not
already, ReasonML, are viable language choices. My personal preference is
TypeScript and ClojureScript.

The projects I have worked on professionally tend to be highly company branded
with a common UI, and I am able to share ~100% of the JavaScript code-base
between them (ignoring platform entry points).

An anecdote: recently one of the applications (React Native + TypeScript) was
audited by a respected independent security consulting firm to rave reviews by
the security team. On the spectrum of risk (Info, Low, Medium, High, Critical)
the worst reported issue was a Medium that was due to the platform default
ProGuard setting that disabled binary obfuscation for development; enabling
required a 1 line config change.

~~~
htormey
This is a really solid answer. The point about ProGuard can especially bite
you if you are adding React Native to an existing application.

Also, upgrading native dependencies in React Native is a really big pain
point. The quality of Native modules also varies enormously.

An example react-native-camera:

[https://github.com/lwansbrough/react-native-
camera](https://github.com/lwansbrough/react-native-camera)

Works well on iOS but has all sorts of performance problems on Android
devices. Even newer ones.

One question I have is why did you prefer Typescript over flow? I have just
started using the latter and I would be curious to hear your thoughts on the
matter.

I'd also love to hear why ReasonML is good.

~~~
lilactown
> I'd also love to hear why ReasonML is good.

Not the OP but I've spent the last couple weeks diving into ReasonML [1]. I'll
give you the synopsis:

1\. Type system is great. Way better than Flow/TypeScript in terms of both
ergonomics (my opinion) and soundness

2\. Comes out of the box ready to build React apps. Project init is very easy
(there's reason-scripts for create-react-app and already
boilerplate/generators for React Native apps as well).

2\. Writing your own bindings for JavaScript code requires some elbow grease
and semi-advanced knowledge of both OCaml and BuckleScript; harder than adding
flow annotations or typescript definitions IMO. But once written, it's as easy
as an `npm install` for everyone else.

3\. Still lots of open questions and unfinished stories - especially around
async programming. The built-in promise bindings kind of suck right now. I
wrote bindings for Most.js [2] that I hope alleviates some of the pain for now
until they get their head on straight.

I've spoken a lot with Cheng Lou and other people working on ReasonML in the
discord channel, and they're just great - very helpful and friendly to a
beginner like me. The community is small but very good. Feel free to hop in
and ask questions and try it out!

[1] [https://reasonml.github.io/](https://reasonml.github.io/)

[2] [https://github.com/Lokeh/bs-most](https://github.com/Lokeh/bs-most)

~~~
htormey
Great answer, thank you so much for writing it. Given all of the con's, would
you advise building an app from scratch with ReasonML?

My main hesitation with stuff like this & Clojure is that the learning curve
for React Native + the JS ecosystem is already pretty steep. Do I want to add
another layer into the mix? For me personally, it would have to come with a
big return on investment to justify the cost. I feel it would have to offer
more than just an incremental improvement over flow/typescript.

An example: I'm considering synching some time into learning RxJS &
ReactiveSwift. My reasoning is that Reactive programming helps eliminate
certain types of bugs and makes it much easier to chain events together in a
complex app.

~~~
lilactown
I think if you (or your team) are not already comfortable with React and the
JS ecosystem, ReasonML probably isn't for you right now. It's still a very
leaky abstraction, with multiple layers. Often errors can occur that in order
to decipher require knowledge of both Reason/OCaml, BuckleScript (the
compiler), React and JavaScript. Adding React Native is another layer.

The ReasonML team are pretty amazing, though, and I do believe that they will
rectify these problems quickly. A lot of effort is being put into
documentation, error messages, tooling and design. The vision that they have
for the project and the way they want people to be able to develop software is
one that I admire and support. I'm putting in my own spare time to help them
out, in the small ways I can.

Right now, though, I would honestly recommend ClojureScript before Reason. I
do believe the maturity of that ecosystem really has hit the point where the
gains (REPL, data-driven development, reagent + reframe + figwheel >>> react +
redux + webpack, and CHANNELS!) outweigh the costs (unfamiliar language,
unfamiliar ecosystem, additional layer of abstraction). I've built some
internal tools using Electron + CLJS and it was great. Haven't messed around
with using it and React Native yet but I know that the renatal [1] project has
come a long way over a short period of time.

Your note about reactive programming is similar to the ReasonML vs CLJS vs JS
conversation; reactive programming is great for certain things! But it comes
at a cost; the abstraction makes certain problems harder and introduces it's
own set of bugs (lifecycle bugs/crashes and memory leaks being the biggest one
I've encountered with RxJS & RxJava), and can make your app code harder to
reason about. Is it better than using callbacks or promises and imperative
programming? Probably! Is it always? Nope! Are there other alternatives? Yes
(CHANNELS!)

TL;DR: Not worth it right now; give it 6 months :D

[1] [https://github.com/drapanjanas/re-
natal](https://github.com/drapanjanas/re-natal)

~~~
htormey
Great answer! Lots of food for thought. I'd love to hear more about any
problems you have encountered with RxJS & RxJava.

------
wiradikusuma
Especially those who have _positive_ experience, could you share your
experience with 3rd party libraries particularly in these particular areas:

    
    
      * Layout  
      * Infinite scrolling  
      * REST client  
      * Image handling (loading, displaying, caching) for popular formats  
      * Push notification (Apple's and Google's)  
      * Built-in (not server-side) SQL for storage  
      * Animation (like transitions, fading)  
      * [Added] In-app purchases
    

The reason I ask is, from my experience with non-native platforms, they look
appealing and "production ready" ("Look how quick and concise you can make
default UI using our platform!"), but once you go beyond default UI, things
get ugly.

These days, those things I listed are arguably pretty standard for modern
apps.

~~~
frostik
Layout: It's the main reason to go all in with RN. You're much faster building
these with RN then using native stuff.

Infinite Scrolling: ListViews and RN are a thing. There's a new List Type
since a few Versions - if you're following the book regarding DataStrucure
everything should work.

REST Client: RN provides basic API so nearly everything which works in Browser
works in RN too. I use Redux Sagas and fetch. Working great so far.

Image Handling: It's built on top of fresco and works great so far.

Push: Can't say mush about it, because i don't use it but should work ok.

In-App: There's a great Plugin.

Animation: Native Animations are around for some time. Should work ok, but
depends what you're planning to do.

Basically it's extremely easy to go native if necessary. But at that point you
need to implement it on every platform. Even though for usual use cases it
shouldn't be necessary. You just need to keep Track of your renderings and
make sure you use PureComponents at the right point, so there are no
unnecessary rerenders congesting the bridge and slowing everything down. But
if you do it right you will achieve performance and an feature level that is
on par with every native development in less time. And with 95% Code Share.

~~~
antoniuschan99
Push works great!

------
ashark
> I run a mobile team of ~30 folks.

That's a... big mobile team. RN's been a good move for our smaller 2-3 person
teams (2-3 devs, plus part-time designer, QA, various other roles full or part
time—call it 6 personnel) though not without trade-offs. Big wins:

1) JS devs can contribute quickly and comfortably.

2) Can still easily write native code if needed (win over other native-but-
not-native frameworks)

3) If you decouple business logic (Redux, even) and, say, REST client code,
that stuff's largely portable to an awful lot of platforms. RN's supported
platforms (including kind-of supported, like FireTV and Apple TV), plus
desktop (well, "desktop"—Electron) and (depending on what you're doing) web.

4) It actually does look pretty OK on both iOS and Android with few special
considerations (conditionally rendered sections, different views) for each.
This surprised the hell out of me.

5) Papers over a lot of stupid, badly-designed, and/or broken crap on Android,
and does a decent job of it.

These add up to a _ton_ of time saved, which manages to overcome:

1) Immature, kinda poorly managed ecosystem. If you stray from RN+Redux and
one or two other core libs, Here Be Dragons. Like, good luck ever upgrading RN
if you load up on dependencies like a typical JS project, if those
dependencies touch RN itself at all. Part of this is just JS "culture", part
of it's the relative youth of the project, and part of it's FB's choices.

2) It's Javascript. We've fixed this by using Typescript, which is great.
Makes Redux actually manageable—way less bouncing around between files,
bouncing out to documentation, more just writing code. Fewer red screens due
to typos or related dumb mistakes.

I can see, though, how it'd be challenging to divvy up work efficiently on
even a fairly large mobile app for 30 people (are they all devs?!) unless
you've got a lot more going on than just layout/CRUD/client-server, in which
case I'd think RN wouldn't change things much, as far as division of labor
goes.

~~~
vishaalk
Can you speak more about how you've integrated Typescript? As far as I've seen
it's not officially supported, so I am wary. I also use Expo

~~~
ashark
Facebook have decided they won't support it (Flow is their thing, so that
makes sense) _but_ Microsoft has stepped up with some pretty serious support,
including good docs for the process of converting a new RN project to
TypeScript:

[https://github.com/Microsoft/TypeScript-React-Native-
Starter](https://github.com/Microsoft/TypeScript-React-Native-Starter)

Not sure whether that'd play nicely with Expo without a bunch of extra work.
It _is_ quite a bit harder to convert an existing project than to start a new
one with TypeScript.

~~~
nb777
This transformer: [https://github.com/ds300/react-native-typescript-
transformer](https://github.com/ds300/react-native-typescript-transformer)
worked perfectly for me so far. You don't have to change your code at all but
just add a single file to your project and the packager will do all the rest
for you.

------
mikesurowiec
My team has been working on our app for 1.5 years now and of all the technical
choices we've made, React Native is probably our favorite. It's taken us
through the prototyping stage and all the way to production without many
issues. Granted, we're a very small engineering team of 3.

Pros

\- We haven't done performance tuning and haven't had any user complaints
about performance (it's a multi-channel chat app)

\- Most of the time, changes "just work" on both platforms

\- Javascript :D

\- Development velocity is great, especially w/ UI changes

Cons

\- Wish we had better text input control

\- You still need someone who knows about native app development on each
platform

\- Upgrading versions can cause breaking issues (this has gotten better)

\- Lesser used 3rd-party packages are often incomplete across platform, so a
fair amount of patches

\- Changes on one platform have the potential to break the other platform (so
testing can require a lot of back and forth)

edit: formatting halp

~~~
susi9999
I've tried making a chat application using Ionic and it's been tough.

The main issue is infinite scrolling by scrolling upward.

The user scrolls to the top, we make a note of the current top comment, load
the next set of results, add them to the page.

At this point, the scrollbar is still at the top, so we need to manually
scroll down to the previous top comment.

It can be a little jumpy. It certainly isn't smooth like WhatsApp etc.

Does RN have a list view that deals with this issue out of the box?

~~~
slsii
We're building a chat app in RN. Last I checked, the RN components do not
support the functionality that you mention out of the box.

We are using a fork of GiftedChat which has generally been a positive but not
stellar experience ([https://github.com/FaridSafi/react-native-gifted-
chat](https://github.com/FaridSafi/react-native-gifted-chat)). I understand
includes some fairly clever (perhaps hacky?) and extensive changes on top of
RN's components to mimic the interactions we generally expect in a chat UI.
It's been performant for the most part but is quite opinionated.

I would love to know if there's a better, more modular solution out there.

~~~
mikesurowiec
We're also using a fork of gifted chat; pretty much use it for the layout
measuring and the inverted scroll view. Hoping to move to FlatList at some
point!

------
s73ver_
A little off topic, but I really, really wish that people would stop trying to
make JavaScript be the language of everything. I have zero interest in
JavaScript, I don't believe it's a nice language to work in, and the ecosystem
is insane. However, given the way things are going, and the way jobs are
trending around me, it seems unavoidable.

~~~
todd3834
There should always be a job available for you that doesn't require writing
JavasScript. However, as a counterpoint, I have been writing ruby/javascript
for a while now and the last couple of years I agree the JavaScript has taken
over my career. I have 0 complaints, I love modern javascript, the ecosystem,
the engines, debug tools and everything between. You don't have to like it but
lots of people do and lots of high quality software is being made with
JavaScript.

~~~
ajeet_dhaliwal
Agreed with your counterpoint. I used to try to avoid JavaScript, nowadays I
wish I could use it for everything (C++, C#, and some others are still
unavoidable for some of my work). Modern JavaScript is my favorite programming
language at this time.

------
awinter-py
Builds are very complicated. It's not as simple as 'JS is your whole app'. The
package manager is getting better at injecting native code (react-native link)
but has a long way to go.

I spent a lot of time debugging RN. The instant reload feature comes with
hangups. Tracebacks don't always appear.

Navigation isn't cross-platform.

Interacting with native APIs is nightmarish. JS wasn't built for java interop.

------
archgrove
No, I don't regret it. We picked it for our startup as we wanted a cross
platform solution, that genuinely felt native (without the huge effort it
takes to make a webapp feel that smooth), and that still gave us a chance to
easily native code for certain features. Big wins:

\- With a little effort, it genuinely feels native.

\- The talent pool is much larger. We didn't hire React Native folk, just good
JS people who picked it up quickly.

\- Blending native code with JavaScript is easy.

\- There are methods to perform app updates without going through the app
store release processes of either platform (and waiting for end users to
actually download the update).

\- It moves quickly, so bugs are squashed pretty quickly, and features arrive
at a fast clip.

There have been challenges:

\- It moves quickly. Backwards compatibility is doesn't seem to be high on the
maintainers priority list, so almost every update will break _something_. We
instituted policies of never falling far behind the public release (to avoid
needing huge changes at once), and using very few external components (which
are often not kept up-to-date with RN).

\- If your use cases are outside of the maintainers, there will be problems.
The release process seems to be "Does it work for the contributors projects?
Ship it". Things like Pod based builds broke for months because they just
weren't tested.

\- The JavaScript ecosystem is still insane. Our project has ended up with one
of the most complex build processes I've worked with (and I've worked with
autotools).

My key advice would be:

\- Stick with their release cycle, and follow their processes. Don't colour
outside the lines, or you will have pain.

\- Don't include third party modules unless you have _no other choice_.

\- Test on both iOS and Android regularly (i.e. continuously). Things that
work well on one platform may be broken on the other.

Based on our outcomes, present me would happily tell past me I'm making a good
call, as I'm confident we'd otherwise never have shipped two native-feel
applications with 5 developers.

~~~
ashark
> \- The JavaScript ecosystem is still insane. Our project has ended up with
> one of the most complex build processes I've worked with (and I've worked
> with autotools).

God is that true. The JS ecosystem as a whole is actually, no BS, crazy, and
their build jenga-tower especially is insane.

With RN, though, we've only really had problems with it when using Expo.
Taking that out of our stack pretty much solved our periodic whole-day-wasting
build problems, and excising it and other tightly-coupled libs freed us to
upgrade RN from time to time, which is nice. A++++, would aggressively remove
RN-specific 3rd party libs again.

~~~
brokenbyclouds
I don't use react native for work, just for my own projects, but what you said
about expo is resonating with me. I thought it would be a clear winner but
it's much slower to do anything with it, the app is constantly crashing, etc.
Feels much less productive.

------
alloy
At Artsy, my team of long-time native developers, started using React Native
on valentine’s day 2016 in our pre-existing iOS app. Overall it has been a
net-positive for us. In short, the developer experience and ability to be
productive is much better, we now are able to leverage the product engineering
skills from devs that would previously only work on web projects, and our
initial tests in porting our React Native iOS code to Android are looking
promising.

I think there’s no binary answer to whether or not React Native is a viable
option. I can definitely imagine a bunch of situations where that would not be
the case, but in our case the app is largely just a collection of views that
show remote JSON data. Some small animations are done using the React Native
animations API, but e.g. our navigation completely relies on native APIs and
also has custom native transitions.

In short, I think that the companies that will succeed with RN are those that
have native experience and a can-do-self attitude, both to ensure proper
platform UX and deal with lower-level details such as RN bugs _and_
limitations that would prohibit the product design from being possible to
implement at all (for instance, in our case nested scrollviews); _or_ those
that are willing to sacrifice on UX and product design. (Not making any
judgements here btw.)

We’ve written a bunch about our experiences
[https://artsy.github.io/series/react-native-at-
artsy/](https://artsy.github.io/series/react-native-at-artsy/) and I recently
spoke about our specific case of integrating RN into our existing native app
at React Native EU [https://github.com/alloy/react-native-
eu](https://github.com/alloy/react-native-eu).

------
syaau
We developed a card game on React Native almost a year back. We were initially
developing the game using cordova but were taken by the performance issues. We
switched on to React Native and were very much impressed with the performance.
One year since we released the game, we are working on the next version and we
have decided to stick with React Native. The development is much faster and
easier. We very much liked the native animation support that has since been
available with React Native. The only problem we faced was with admob
integration. No regrets so far.

iOS app: [https://itunes.apple.com/us/app/marriage-card-
game/id1161818...](https://itunes.apple.com/us/app/marriage-card-
game/id1161818616?mt=8)

Android app:
[https://play.google.com/store/apps/details?id=com.bhoos.marr...](https://play.google.com/store/apps/details?id=com.bhoos.marriage)

Note: It was our very first attempt on mobile gaming. The rules for the games
are available here if anybody is interested to learn
[https://www.pagat.com/rummy/marriage.html](https://www.pagat.com/rummy/marriage.html)
The game is meant for players who already know the game rules.

------
chrisa
I'm a react native consultant, so I've seen several different projects (of all
different sizes). Overall, I've been super happy with React Native, and would
easily recommend it to anyone looking to build an Android and iOS version of
the same app.

There have been a lot of changes since 2015 - and the overall experience has
gotten quite a bit better. There are many more modules available for both
platforms (in 2015 you probably found a lot of modules only supported iOS and
not Android) - and in general the whole ecosystem is more stable.

That said: not everything is perfect. React Native moves quickly, so there are
sometimes frustrating bugs (especially in new releases) that can take a bit of
time to resolve. Also, it's not a great fit for every type of app. 3D games
are an obvious example of when you'd want to go native (or use unity).

However, after having done native iOS development and react native
development, I can say that react native is still faster (development speed).
In practice I find that I can reuse 95% of the code between iOS and Android,
so it's been a great win for the teams I've been on.

------
mbrock
In 2015 I began using React Native for a client because I was led to believe
that it would be a nice way to bring their web app to iOS and Android. After
months of alternating happiness and frustration, we cancelled the project due
to many horrible problems involving crashes, lagginess, and poor behavior. I
definitely regret that. Probably the ecosystem is more mature now, but back
then I found its advertising and hype to really stretch its actual quality.

------
anon12051
1.50 years since app development started 0.75 years since app was released

stuck with old version of rn, upgrades break app

new team members onboarding takes forever, environment is extremely tenuous

would i use again? no

~~~
djstein
>stuck with old version of rn, upgrades break app

so you have problems you need to sort out with your own codebase. this is not
unusual when using any framework. willing to bet this also stems from poor
code practices due to the lack of react 'standards' 1.5 years ago / lack of
es6+ code

>new team members onboarding takes forever, environment is extremely tenuous

in terms of onbaording, this is something that can always be improved on.
better docs. getting started docs. if you've done it once and realized what
new hires are struggling with you can reduce that in the future. the
environment isn't really that bad, if you had someone who understands
javascript ecosystem then they really only need to know how to bundle the
packages through the device specific IDE.

just seems like you've got a bad taste in your mouth for a standard everyone
else seems to have figured out.

~~~
whostolemyhat
I had similar issues taking over a project using an older version of React
Native. Upgrading is incredibly painful since there's no stable version and
libraries don't always update to match. The current release of React Native
uses a release candidate version of React, which many of our dependencies
haven't yet updated to match, so we're either stuck with an old version with
poor compatibility or have to fix dozens of third-party libraries to try to
catch up - both are not ideal, and both are caused by constant breaking change
releases.

------
m_ke
We switched to React Native for Bitesnap after developing the initial
prototype using swift. We've been using it for almost a year now and have no
regrets. It allowed us to ship our product to a much larger audience without
slowing us down.

Users seem pretty happy with the product as well, we've had no complaints
about performance aside from a barcode scanning issue on older android
devices.

[https://itunes.apple.com/us/app/bitesnap-photo-food-
journal/...](https://itunes.apple.com/us/app/bitesnap-photo-food-
journal/id1108291490?mt=8)

[https://play.google.com/store/apps/details?id=ai.bite.biteap...](https://play.google.com/store/apps/details?id=ai.bite.biteapp&hl=en)

~~~
solidr53
Nice! I tapped that version number a few times and got the dev menu... gold!!!

Does seem like non native, but performs well ;)

------
dkdkang
Our team and clients are pretty happy with the decision to adopt React Native.

I'm part of a JavaScript-only consultancy, we've now built RN apps for three
companies in the Fortune 500: a retail, healthcare, and data storage company.
Performance-wise, all three applications performed to our clients' standards.
However, we also encountered issues concerning debugging, new releases, and
other limitations.

That being said, the biggest advantage the RN has (which is why our clients
decided to take the plunge) is that it significantly decreases the development
time when you want to scale for various platforms. At the end of the day -
your decision should be based on you and your team's willingness to play with
JavaScript.

------
simonw
This is such a great concept for a thread - the replies are fascinating. I
love the focus on "larger teams who adopted it at least a year ago". Thanks
for posing such an insightful question!

------
htormey
I'm a native iOS developer who does a lot of React Native consulting. Earlier
in the year I gave a talk on the pro's and cons of React Native which you can
watch here:

[https://www.youtube.com/watch?v=cZ4zQWgajBg&t=746s](https://www.youtube.com/watch?v=cZ4zQWgajBg&t=746s)

The main reasons I got into React Native was a combination of frustration with
the state of Swift last WWDC and an opportunity to try it out with a client
who just had a React Web team.

I don't regret the decision at all. If you are thinking about using React
Native in a project here are some things to consider:

Maybe we should use React Native:

\- We know JS / React

\- We have lots of web developers but few mobile

\- Our design is brand-focused

\- We're willing to invest in RN

\- We want to get into OSS

\- We want OTA code updates

Or maybe we shouldn't:

\- We don't know JS / React

\- We already have an iOS team and an Android team

\- Our designs are heavily platform-specific

\- We don't have the time or money for an RN team / OSS

Pros:

\- Cross-platform

\- Performant, native feel (with some effort)

\- Great developer experience

\- Push updates over-the-air

\- Strong community

\- Backed by Facebook

Cons:

\- Early

\- Unstable (bugs, APIs)

\- Ecosystem not fully developed

\- Polished apps are high effort

\- You may need native code (so JS + Obj-C + Java)

If you are a fully native shop, with no JS dev's that use React, it doesn't
make all that much sense to rewrite your app using React Native.

If you have no native team, are familiar with React, then React Native makes a
lot of sense.

If you are are a company with native apps and a web team that knows React then
using React Native inside your existing app for growth, etc, makes a lot of
sense.

Going all in on React Native is a big investment and I wouldn't recommend it
for many use cases (multimedia, etc). Right now it definitely has some rough
edges (navigation, upgrading versions, etc) but it can dramatically increase
the productivity of your front end teams.

------
t_fatus
We're using it in production apps since 18 months, and even if it still
sometimes feel like it's a 'beta' (interfaces change, navigation keeps
changing too) it has become more reliable. The real struggle has more to do
with XCode and native apps in general (Expo definitely fits in the prototype
thing in my opinion).

The good (great) part comes from the fact we're a small team (4 devs) and and
thus we can do / test / debug things only once for our different platforms
(we're using Electron, with all its caveats too).

Apollo and GraphQL availability is also a great plus.

There are performance issues, and data transfer from RN to Native code and the
other way is complicated (and different on each platform).

With 30 persons working on an App you've got more than enough to have 1
version for each platform though.

------
segmondy
Haven't used it. Was considering it till I read the license rubbish. I use
ionic and I'm quite happy with it. It's not Native, but for 80% of the apps
out there it's create and there are lots of native Cordova plugins and you can
write your own if you need missing native capabilities.

~~~
rjmunro
Just delete the PATENTS file. There is nothing that says you can't do that,
and you then have a plain BSD licensed project.

~~~
ballenf
The downvotes suggest no one is taking this seriously, which is good. Because
as soon as the first React patent issues such a project would be an immediate
willful patent infringer. At least in the US or anywhere else software patents
are recognized and have been filed.

------
efficax
I don't regret adopting React Native for a big project, since I think we've
been able to prototype and iterate much more quickly than we would if writing
in Swift or Java, and it's enabled us to get webdevs up to speed on mobile
without having to teach them entirely new programming paradigms and languages.

But... RN still has huge blocking bugs like this one:
[https://github.com/facebook/react-
native/issues/14209](https://github.com/facebook/react-native/issues/14209)
that seem to pop up at random times, and not always for the same developers. I
thought yarn would solve some of these issues, but they still kill our dev
team and halt all work every once in a while. And it's annoying as heck.

------
ojr
React Native is painful to upgrade, it usually takes a developer day to
upgrade to the latest version but I'm used to this reality at this point,
XCode is not the most developer friendly platform to build on. Integrating
GraphQL (game-changer and enjoyable way to do mobile api calls), into an
existing react native app was a smooth process, GraphQL has a learning curve
but the GraphQL, React Native, Node stack seems like a viable option, there
are pros and cons to every stack. The React Native ecosystem could save you
time, companies like Wix and Microsoft are contributing good software.

------
amzpix
OP, I would like to learn more about your story as well. How did you arrive at
your decision that RN is not a good fit?

~~~
tekstar
I really don't want to rail on RN. My experience is 2 years old at this point,
and even then it was the internal decision we made based on our use-cases and
needs. Yours are likely different and maybe RN would be a silver bullet for
you.

We tried it for a few months in earnest.

There were a lot of bugs or incomplete APIs for our use-cases. Off the top of
my head, if I remember correctly - intricacies and bugs around input handling,
the JS navigator implementation didn't properly support swipe back/forward and
we could crash it with a couple well timed taps, landscape mode was non-
existent, same with master/detail view. We were able to make a few screens in
a few days, but polishing them to a shippable standard took exponentially
longer or was relatively impossible without doing more native work than what
would have been necessary to build it natively from scratch. There were also
serious perf issues, like around list views.

Our team members submitted a few PRs to the github repo and they took months
to get merged, if at all. Back then it felt like nobody was really at the
helm. I suspect this has gotten better since then.

~~~
antoniuschan99
Was RN available for Android when you were testing it?

~~~
tekstar
RN for android was publicly released during the time we were experimenting.

------
nihardongara
We are a team of 4 developers who work on iOS and Android app for Copart. iOS
- [https://itunes.apple.com/us/app/copart-app-online-salvage-
ca...](https://itunes.apple.com/us/app/copart-app-online-salvage-car-
auctions/id414275302?mt=8) Android -
[https://play.google.com/store/apps/details?id=com.copart.mem...](https://play.google.com/store/apps/details?id=com.copart.membermobile&hl=en)

RN has worked really well for in delivering functionalities to both the
platforms and even in maintaining a single code and a small team. Our app is a
real-time high-intensity auction platform which uses web-sockets to stream
data. When we were using native languages to develop app it was very tough to
maintain the same feature for both platforms. RN has helped us in tackling
this really well. I understand there are some drawbacks of RN but with proper
optimization of native code, we can achieve the results really well. I still
believe that RN Android is lagging behind RN iOS but it still does a great job
compared to other Cross-platform tech stacks.

------
pattrn
I've had a React Native based fitness tracking app live in both stores for
over a year now. If I had to do it over again, I would still choose React
Native. It's made the whole cross-platform development process incredibly
simple, and it provides excellent tooling out of the box.

Some dependencies on third party libraries made upgrades difficult, but the
core library added the functionality I needed eventually, so I no longer run
into those issues. Overall it's been pleasant to work with.

iOS app: [https://itunes.apple.com/us/app/plansible-weight-lifting-
jou...](https://itunes.apple.com/us/app/plansible-weight-lifting-
journal/id1132671774?mt=8)

Android app:
[https://play.google.com/store/apps/details?id=com.plansible_...](https://play.google.com/store/apps/details?id=com.plansible_mobile&hl=en)

------
atonse
I'd love to know this as well, as we're currently evaluating making the leap
between RN and Xamarin for our startup.

(ideal world, I favor just using the native stacks for iOS and Android but we
are short staffed)

~~~
Amokrane
Consider Flutter ([https://flutter.io/](https://flutter.io/)) as well. The
advantage over RN in terms of performances is interesting.

~~~
BoorishBears
I remember putting the Flutter demo with a simple counter on a no-name Android
device and having the Flutter app completely chug.

The hardware had a really wimpy SoC, but a native app would never chug for
something as simple as pressing a button to change a number.

It made suspect that while in phones with strong GPUs the acceleration makes
things buttery smooth, it doesn't graciously scale to poor GPUs (but someone
please do correct me if it might have been something else)

It got me worried about shipping an app and finding out it doesn't run on low
end hardware even though it doesn't do anything that would be demanding on
native

~~~
thebosz
Do you happen to remember what device that was? On my crappiest Android device
(Moto E LTE 2015), the Flutter Gallery app runs fairly smooth.

~~~
BoorishBears
It's not a "normal" device that I could really name, but it's internals are
shared with several brands of no name Android tablets you'd find at Walmart,
for example

------
austenallred
OP, I’m curious when you tried it in 2015? Of course, a lot has changed since
then, but Jan 2015 vs Dec 2015 are worlds apart as far as React Native goes.

------
jseip
If any folks on this thread have especially enjoyed working with React Native,
I'm hiring for a role completely focused on our RN app:
[https://angel.co/goaero/jobs/280128-react-native-
lead](https://angel.co/goaero/jobs/280128-react-native-lead)

------
Sikul
You might be interested in this: [https://blog.discordapp.com/using-react-
native-one-year-late...](https://blog.discordapp.com/using-react-native-one-
year-later-91fd5e949933)

We use it over at Discord.

------
ketzusaka
JavaScript is a terrible language. Please don’t ruin your app by having it
written in JS.

~~~
mlsarecmg
Lots of things have changed since es5. It's actually more than suitable for
front end. I am certain that by using react/redux and es2017 you could cut
pretty much any native codebase in half and still have it appear and behave
cleaner in the end. This is why they are porting these principles to native,
for instance in Kotlins Anko, Litho, ComponentKit, ReactXP, or react-native
itself.

JS + npm/node also has more modules and components to choose from than any
other repository combined. The crippling factor was always the browser, now
that that's out of the way, it can build applications native counterparts
could not get at given the same amount of money, time and workforce.

------
skyisblue
Having developed native android and ios apps in the past the greatest benefit
i saw immediately using react native was the use of flexbox for layouts, it's
so much simpler compared to ios' autolayout and android's xml layout.

------
pbreit
Why was it not a good fit for you? 30 devs seems like plenty to build native?

------
infinii
Nice question by OP which piqued my interest. Unfortunate to see such
polarized opinions. Based on the responses so far, I'm still up on the air on
whether RN is a good choice or not. :(

------
davelnewton
Can you explain the comment about a "larger team"? What issues do you see
being any different for RN vs any other mobile tech regarding team size?

------
gcb0
the important question, will you regret you used flutter tomorrow?

------
GeoffreyPlitt
Used it for 1.5 years now. Love it.

