13 ms·

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

363 points by tekstar 9y ago

I'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? 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'm interested in stories from the alternate reality where we took the react-native path instead. I'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. Thanks

amzpix 9y ago
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 9y ago
  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 9y ago
    Was RN available for Android when you were testing it?
    - tekstar 9y ago
      RN for android was publicly released during the time we were experimenting.
atonse 9y ago
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 9y ago
  Consider Flutter (https://flutter.io/ https://flutter.io/) as well. The advantage over RN in terms of performances is interesting.
  - jankins 9y ago
    Beware though: "Note: Flutter is an alpha, open-source project." It's missing some polish (notably, check accessibility) https://flutter.io/widgets/accessibility/ https://flutter.io/widgets/accessibility/ "Make your app accessible. (This is a work-in-progress.)" I haven't dug into how much is done though. It's alpha after all, but I'd be wary of choosing it for a production project at the moment.
  - BoorishBears 9y ago
    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 9y ago
      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.
pg_is_a_butt 9y ago
facebook enforced their patent clause and took over our app and enslaved us all. i guess i regret some things.
awinter-py 9y ago
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.
chrisa 9y ago
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.
m_ke 9y ago
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/id1108291490?mt=8 https://itunes.apple.com/us/app/bitesnap-photo-food-journal/... https://play.google.com/store/apps/details?id=ai.bite.biteapp&hl=en https://play.google.com/store/apps/details?id=ai.bite.biteap...
- lap42 9y ago
  Great product! What navigation are you using?
- solidr53 9y ago
  Nice! I tapped that version number a few times and got the dev menu... gold!!! Does seem like non native, but performs well ;)
erik_landerholm 9y ago
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 9y ago
  what's the company name?
  - askmike 9y ago
    TrueCar is the company behind Gluestick.
  - qqg3 9y ago
    TrueCar
  - StavrosK 9y ago
    A Google search for "Gluestick react" says the company is TrueCar.
- btown 9y ago
  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.
segmondy 9y ago
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.
- publicfig 9y ago
  I'd recommend reading this article about the licensing language that's being disputed now: https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562 https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok... The author is the same person that has an article on the front page currently arguing that the license for Graph QL DOES have issues (and is following through with Facebook through Github Issues to resolve them), so I think this position is really worth considering.
- rjmunro 9y ago
  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 9y ago
    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.
- sandGorgon 9y ago
  Same here. We were seriously considering it, until the licensing issue. In fact, we continue to use Reactjs - because it is something that we can rip out and replace if push comes to shove. But a React Native app once released will live in the wild - which means the patent exposure cannot be mitigated easily.
anon12051 9y ago
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 9y ago
  >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 9y ago
    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.
pbreit 9y ago
Why was it not a good fit for you? 30 devs seems like plenty to build native?
t_fatus 9y ago
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.
archgrove 9y ago
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 9y ago
  > - 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.
dkdkang 9y ago
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.
ashark 9y ago
> 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 9y ago
  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 9y ago
    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.
lilactown 9y ago
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.
- gcb0 9y ago
  same experience with testing on my side of the woods. but I'm not directly on that team...
- EngVagabond 9y ago
  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?
austenallred 9y ago
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.
dan_manges 9y ago
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/id1021256908?mt=8 https://itunes.apple.com/us/app/root-car-insurance/id1021256... Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.root&hl=en https://play.google.com/store/apps/details?id=com.joinroot.r...
- g00gler 9y ago
  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.
  - chrisco255 9y ago
    The best nav experience I've had with RN is React Navigation: https://reactnavigation.org/ https://reactnavigation.org/
    - g00gler 9y ago
      Looks very good, will have to try it out.
    - danpalmer 9y ago
      I've had an ok experience with React Navigator, but still feels very immature (I was unable to implement relatively straightforward animations on the parent view in a transition), and it also feels like interface builder/storyboards leaves it in the dust in terms of wiring together interfaces and getting a high-level overview of the information architecture of an app.
t1amat 9y ago
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 9y ago
  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 9y ago
    > 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
mbrock 9y ago
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.
mikesurowiec 9y ago
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 9y ago
  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 9y ago
    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.
htormey 9y ago
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.
whostolemyhat 9y ago
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 9y ago
  Why are you using RN if your app is just wrapping a web view?
  - johnwheeler 9y ago
    If you have to ask questions like this, you haven’t been working in the industry long enough.
davelnewton 9y ago
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?
simonw 9y ago
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!
gcb0 9y ago
the important question, will you regret you used flutter tomorrow?
wiradikusuma 9y ago
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 9y ago
  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 9y ago
    Push works great!
- dean177 9y ago
  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
ojr 9y ago
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.
s73ver_ 9y ago
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.
- Rumudiez 9y ago
  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.
  - s73ver_ 9y ago
    Mobile development. And as I said, it's getting there. JS is being shoehorned in everywhere, and most of the job ads I'm seeing are requesting web tech in mobile developer ads.
- deleted 9y ago
  [deleted]
- todd3834 9y ago
  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 9y ago
    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.
syaau 9y ago
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/id1161818616?mt=8 https://itunes.apple.com/us/app/marriage-card-game/id1161818... Android app: https://play.google.com/store/apps/details?id=com.bhoos.marriage 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 https://www.pagat.com/rummy/marriage.html The game is meant for players who already know the game rules.
efficax 9y ago
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.
jseip 9y ago
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
skyisblue 9y ago
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.
GeoffreyPlitt 9y ago
Used it for 1.5 years now. Love it.
infinii 9y ago
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. :(
alloy 9y ago
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.
ketzusaka 9y ago
JavaScript is a terrible language. Please don’t ruin your app by having it written in JS.
- mlsarecmg 9y ago
  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.
- rimliu 9y ago
  Actually looking at examples of the apps shown here JS does not matter. They still look like webviews. Cross-platfrom is really a misnomer, it should be no-platform. Yeah, it kind of runs on both, and alien on both too.
nihardongara 9y ago
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-car-auctions/id414275302?mt=8 https://itunes.apple.com/us/app/copart-app-online-salvage-ca... Android - https://play.google.com/store/apps/details?id=com.copart.membermobile&hl=en https://play.google.com/store/apps/details?id=com.copart.mem... 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 9y ago
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-journal/id1132671774?mt=8 https://itunes.apple.com/us/app/plansible-weight-lifting-jou... Android app: https://play.google.com/store/apps/details?id=com.plansible_mobile&hl=en https://play.google.com/store/apps/details?id=com.plansible_...
Sikul 9y ago
You might be interested in this: https://blog.discordapp.com/using-react-native-one-year-later-91fd5e949933 https://blog.discordapp.com/using-react-native-one-year-late... We use it over at Discord.

cheapsteak 9y ago

How does it compare with react-native-navigation? Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two [1]: https://i.imgur.com/etEa7WT.png https://i.imgur.com/etEa7WT.png

htormey 9y ago
I recently gave a talk at Chain React in Portland (first ever React Native only conference) where I compared these two nav stacks: https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s https://www.youtube.com/watch?v=kFyaj5HmMEY&t=1059s The situation with navigation and React Native is a bit of a mess right now. Basically all navigation stacks can be broken down into two categories, those that are native (i.e built on top of the OS's existing navigation stack) and those that are not (pure javascript, emulates what the native stack does). Examples of Native navigation stacks: -> React Native Navigation (wix) -> Native Navigation (Airbnb) Examples of Javascript navigation stacks: -> React Navigation -> React Native Router Flux -> React Router Native An example app I wrote with React Navigation + Redux: https://github.com/hgale/ReactNavigationDemo https://github.com/hgale/ReactNavigationDemo Same app but built with React Native Navigation + redux: https://github.com/hgale/ReactNativeNavigationDemo https://github.com/hgale/ReactNativeNavigationDemo The main differences are that the native nav stacks have better performance, stuff like accessibility works right out of the box and they work the same way that the underlying native system works. The main downside to using Native navigation stacks right now is that setting then up & upgrading them can be a real pain. It can also require native knowledge when things go wrong. I would recommend staying with react navigation (Javascript based nav stack) unless you absolutely need some feature from one of these native nav stacks. It's going to be a lot easier to upgrade and you won't run into issues doing over the air updates with your production apps. It's also the one that Facebook promotes in their docs: https://facebook.github.io/react-native/docs/navigation.html https://facebook.github.io/react-native/docs/navigation.html Right now both React Native Navigation and React Navigation are under heavy development. No matter which one you choose, budget for some pain in the next year when upgrading.
- danudey 9y ago
  I would think that having to learn a little about iOS/Android would be a small price to pay for decent performance and accessibility. The idea that those are only sometimes important rather than a necessity is alien to me as a software developer and as a user.
  - htormey 9y ago
    I agree, accessibility is important and in many countries required by law. However using React Native Navigation can be quite a lot of work for a shop that only has JS dev's who've never done native. Using React Native Navigation (or any native dependency) also has implications for your CI system, debugging and over the air updates. Also you can make an app that has no accessibility problems using React Navigation, you just need to be careful about scenarios where you might have a deep stack. I.e during signup or something that requires several screens on top of one another. Here is a summary of the bug: https://react-native.canny.io/feature-requests/p/navigator-breaks-android-screen-reader-accessibility https://react-native.canny.io/feature-requests/p/navigator-b... It's painful but possible to work around these issues using React Navigation.
- solidr53 9y ago
  I agree and even go one step further by saying that I'd never publish an RN app without native navigation.

htormey 9y ago
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 9y ago
  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 9y ago
    Great answer! Lots of food for thought. I'd love to hear more about any problems you have encountered with RxJS & RxJava.

muse900 9y ago

On top of that my question to the OP would be, why do they need to search around for libraries that are older than RN. In a team of 10 you can most likely create your own ones, or fork already made libraries and upgrade them to fit your purpose. One of the greatest things with RN so far for my team has been that we can actually write native components and bridge them. Yes RN is changing quite fast in general and most libraries out there might not fit your exact purpose, but I find it quite easy to integrate what I need in our app. (Team of 3, been on production for 8 months, its pretty alright so far)

whostolemyhat 9y ago
The main problem we're having is that newer versions of RN use React 16. React 16 has breaking changes, particularly the changes to PropTypes and createClass, which some of our dependencies have already fixed but others haven't. This means to upgrade RN, we need to either submit fixes for all these libs or use a version of RN which still uses React 15, both of which have their own problems, especially since React 16 is still a release candidate and not a full release. We're not creating our own libraries for a couple of reasons: firstly, this was supposed to be a quick project to see if an app is viable (but has now lasted long enough that we've run into this issue), and secondly we've already got forks of key libraries, which is taking more time away from implementing actual features since we now need to maintain them and pull in updates from the original repos. Yes we should have kept dependencies up-to-date, but constant breaking changes are just taking too much time away from development time, so it's not a good fit for our project as it stands.
- muse900 9y ago
  Imho, I think you got it wrong here. I don't think you are supposed to make a production RN app out of the bat, by just using 3rd party dependencies. RN isn't wordpress where someone can employ you and say I want this and that and then you go off install 50 plugins and thats it, your project is completed. If you are installing a lot of RN 3rd party dependencies for a production environment then you are doing it wrong. The best thing RN has to offer is being able to write React for parts and write Native code for heavy tasks. You do need to go down and write your own components natively, sure if someone has done it before and its well maintained and you tested it and works for you then fine use that library, if not then don't install it but make your own. For js components only components, then again if its very well maintained then use it, but nothing stops you for making the component that works for you. RN is a bit less work than writing a Native app, but not too far apart. It's not meant to be for webviews and for people that just want to make a complex production app using 3rd party dependencies in very little time. Its meant for dev teams that JS is their main language but do have someone that has an understanding of native code.
  - whostolemyhat 9y ago
    Cool I'll just roll my own Facebook and Stripe integrations then
    - muse900 9y ago
      it depends, on my app I don't use Stripe so can't speak for its sdk, but I do use FB. At start I was using react-native-fbsdk but found that it was very limited and when I submitted a PR and went through the NDA procedure with facebook etc, then they delayed putting my PR which was fixing an issue out. I decided it would be easier for myself to bridge facebook's sdk, and so I did which was helpful as I've added quite more features to it which the react-native-fbsdk isn't providing. That said it always depends on your usage and if it fits your purpose, but I wouldn't rely on 3rd party devs to solve my issues.