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

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?

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

While the citation you provide is interesting, it doesn't inherently prove that in real-world usage, React Native apps consume twice the power of their native counterparts.

> Swift won overall in the CPU category, React-Native won the GPU category (barely), and React-Native won big time in the Memory category.

[1]: https://medium.com/the-react-native-log/comparing-the-perfor...

The JS runtime is only used to choreograph different native components. It's like a .xib or storyboard but with the ability to do logic. This code runs at user input speed so the relative performance characteristics are irrelevant.

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.

Kind of difficult to parse the adoption/ecosystem based on download trends[1] for these two

[1]: https://i.imgur.com/etEa7WT.png

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

Same app but built with React Native Navigation + redux:

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

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.

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

It's painful but possible to work around these issues using React Navigation.

I pretty much put the project down after that and started learning Swift (I already do Android).

Now I decided to go all out on iOS dev with the hope of making a career change from web.

It's actually quite easy

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.

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.

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.

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.

To be jaded.

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

Is snarkily telling someone they're not good enough helpful?

Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone.

(FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)

The answer is: it’s in our nature to make simple things difficult.

It shows more maturity if you just accept people do stupid things without trying to pry a rationale out of them IMO.

And thus avoid all the problems mentioned above.

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.

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.

The next approach we started on was using https://github.com/necolas/react-native-web. This was very exciting and very fun to work with. However, we found it difficult to optimize the web experience. Most of our traffic is on the website so we are spending a lot of time optimizing the web experience. This might not line up with other's experience but we kind of came to the conclusion that react-native-web works great for apps where the native app is the primary driver and you want to offer a web experience as a secondary experience. This became more clear when we started trying to work with our SEO team. And again when we started trying to build responsive designs with react-native-web. Doable but we ended up spending a ton of time to make the web work the way we wanted to.

Eventually we decided to go a different direction. Most of our display logic is the same or very similar between the mobile web/ios/android with a few exceptions. We found that mixing ReactNative with the webview component gave us the ability to use webviews to share the majority of the code that can be shared. When we need more native functionality we communicate with postMessage and we have access to ReactNative. Once in ReactNative if we need to go down to iOS specific or Android specific code we have the ability to do that too. We found this to be much more powerful than Cordova and the user experience is honestly amazing. This is still a work in progress but we are excited about what we've seen so far.

One of the things we swap to react-native was to do a barcode scanner. With WebRTC support in iOS11 we may not even need to do that for long.

Currently I use this functionality exclusively for platform specific branching, without any platform-specific conditional logic in my codebase whatsoever. So to give a really trivial example, you can have something like this:

In App.js (shared as-is across platforms):

  import * as element from './element'
  
  export default () => (
    <element.View>
      <element.Text>
        Hello world!
      </element.Text>
    </element.View>
  )

  export const View = 'div'
  export const Text = 'span'

  import ReactNative from 'react-native'
  
  export const View = ReactNative.View
  export const Text = ReactNative.Text

In practice, a lot of elements don't map one-to-one between web and React Native, and will require a lot more shimming to get at a reasonably close API (forms, inputs, and lists have been especially painful so far), but React's component model gives you all the tools you need to handle and smooth over those mismatches. This approach works great for utility functions that need to provide platform dependent functionality as well, so it's not just for elements.

Disclaimer: My project is still in a super early stage right now, so I'm not sure how well this approach can scale, but so far I'm enjoying the experience a lot more than I thought I would thanks to this approach, due to the lack of need for platform-specific branching logic in my code.

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.

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.

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/

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

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.

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

I don't want to start a holy war on this, as it's generally accepted that Flow's type system and inference is superior. I believe TypeScript is a generally better solution despite this, for other reasons. This is just the list I can come up with offhand:

Upsides for TypeScript:

* bigger community

* more definitions (This cannot be overstated; the gap is wide)

* great IDE tooling and support via language service

* great compiler

Downsides for Flow:

* less definitions

* smaller community

* .flowconfig is difficult to get right, and often requires hacks to pass type checking

* dodgy IDE support

* type discovery is more difficult

Could you tell me a bit more about the following points:

* more definitions (This cannot be overstated; the gap is wide)

and

* great compiler

I'd love to hear more about this and or read some good articles comparing flow to typescript.

flow can be added to an existing project

i feel that almost everyone underestimates how important this is

[1]: https://www.npmjs.com/package/babel-preset-typescript

  * 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

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

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.

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

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.

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.

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

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?

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

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.

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.

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.

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

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.

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.

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.

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.

stuck with old version of rn, upgrades break app

new team members onboarding takes forever, environment is extremely tenuous

would i use again? no

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.

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

Does seem like non native, but performs well ;)

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.

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.

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.

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.

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.

But... RN still has huge blocking bugs like this one: 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.

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.

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.

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

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

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

Most teams are committing to native development after trying Xamarin.

Even with the 30% development savings, I prefer native. It's just less hassle and more enjoyable.

It's missing some polish (notably, check 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.

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

We use it over at Discord.

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.