Ask HN: Companies who adopted React Native over a year ago, do you regret it?

[+] dan_manges|8 years ago|reply

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

Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.r...

[+] snarfy|8 years ago|reply

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?

[+] g00gler|8 years ago|reply

How do you manage 100+ screens?

I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens.

Wix's "React Native Navigation" was too opinionated / inflexible.

[+] andrethegiant|8 years ago|reply

Do you share any of your code base with a web app?

[+] whostolemyhat|8 years ago|reply

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|8 years ago|reply

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

[+] antoniuschan99|8 years ago|reply

Sounds like Ionic is a better solution for your app.

[+] lilactown|8 years ago|reply

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|8 years ago|reply

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?

[+] gcb0|8 years ago|reply

same experience with testing on my side of the woods. but I'm not directly on that team...

[+] erik_landerholm|8 years ago|reply

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.

[+] btown|8 years ago|reply

How are you doing code sharing between web views and native? Is this an (open-source??) high-level component library that conditionally compiles to either <div>'s or <View>'s? Or did you actually find a way to render ReactDOM components within React Native inside some sort of controlled web view? The latter IMO would be a holy grail for companies trying to transition large ReactDOM codebases to native apps gradually.

[+] lewisl9029|8 years ago|reply

I've just recently started exploring React Native, so I'm curious if you have any pointers on how to implement responsive designs in a way that's compatible across web and native apps? Actually, I'd love to hear some suggestions on what to do w.r.t responsive design on React Native in general, since the solutions I've seen so far don't seem very well adopted and battle-tested. Once I settle on an approach, I should be able to just shim it out into a utility function or higher-order component like I'm doing for everything else.

[+] morenoh149|8 years ago|reply

what's the company name?

[+] t1amat|8 years ago|reply

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|8 years ago|reply

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

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.

[+] wiradikusuma|8 years ago|reply

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|8 years ago|reply

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.

[+] dean177|8 years ago|reply

From your list I have had no experience with in app purchases or client side sql.

I had a fair amount of trouble with push notifications on android (callbacks not being called etc), but those issues were eventually resolved (and had no issues with iOS).

Everything else on your list I found much simpler &a quicker than working with the native platforms

[+] ashark|8 years ago|reply

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

[+] mikesurowiec|8 years ago|reply

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|8 years ago|reply

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?

[+] rimliu|8 years ago|reply

I still cannot wrap my head around the fact that there are people willingly choosing Javascript over Swift.

[+] s73ver_|8 years ago|reply

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|8 years ago|reply

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.

[+] Rumudiez|8 years ago|reply

I have zero interest in farming, so I am not a farmer.

I don't think it's likely there will ever be a true "one language to rule them all" in the foreseeable future. Gripe as you may about a tool you don't use, it doesn't sound like you're in a field where knowing JS is mandatory knowledge.

[+] wwweston|8 years ago|reply

Of all the niches one might worry JS will/has claimed an unavoidable status.... native mobile app development doesn't seem like it should be high on the list.

Any language with as critical a mass among devs will probably see tools to help people leverage it across different environments, so JS will likely continue to move into and live in all sorts of niches. But it's quite avoidable on the server, desktop, native mobile, embedded, and it's even becoming partially avoidable on the web.

You're safe enough that you don't have to make everyone else dislike it in order to not have to touch it.

[+] unknown|8 years ago|reply

[deleted]

[+] GiantRobots|8 years ago|reply

For the native platform I feel that "make JavaScript be the language of everything" was basically forced on people if they wanted something to work on iOS because it's one of the only languages that are allowed on the platform. It is especially useful because you can do minor updates to your app to support bugfixes and faster iteration times.

[+] cnp|8 years ago|reply

You should give it another try. The modern ecosystem / DX environment is really fast and slick. I've known a number of native devs from different languages who now love the lang and what it has to offer. But you've gotta go into it with an open mind :)

[+] awinter-py|8 years ago|reply

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|8 years ago|reply

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.

[+] alloy|8 years ago|reply

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/ 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.

[+] syaau|8 years ago|reply

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

Android app: https://play.google.com/store/apps/details?id=com.bhoos.marr...

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 The game is meant for players who already know the game rules.

[+] chrisa|8 years ago|reply

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|8 years ago|reply

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|8 years ago|reply

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|8 years ago|reply

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

[+] m_ke|8 years ago|reply

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://play.google.com/store/apps/details?id=ai.bite.biteap...

[+] solidr53|8 years ago|reply

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

Does seem like non native, but performs well ;)

[+] lap42|8 years ago|reply

Great product! What navigation are you using?

[+] dkdkang|8 years ago|reply

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|8 years ago|reply

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|8 years ago|reply

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

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.

145 comments