We are the team working on React Native. Ask us anything!

Have you received any feedback, positive or negative from Apple about the long-term viability of using the JavaScriptCore as a means of powering ReactNative? If so, would you be willing to share?

We answered in another question below: https://www.reddit.com/r/IAmA/comments/3wyb3m/we_are_the_team_working_on_react_native_ask_us/cxzx52o

Is Facebook's intention with ReactNative to wholly replace native mobile development as we know it today?

Yes. -Nick

Got it. Can you elaborate on your philosophy behind that thinking? (I assume there's more to it than just "we're a bunch of outstanding JavaScript devs with a ton of time on our hands." or "We dislike Obj-C, Swift and Java")

Most of the core React Native team are actually native iOS and Android developers, so it's definitely not that we prefer JavaScript over native code.

The reason we built React was to improve developer efficiency. Building and maintaining wholly separate apps for each platform is hugely inefficient in terms of manpower. And the actual native development process of write/compile/deploy/debug is also slow compared the web approach, where you can just hit refresh after making changes, with no lengthy compile or deploy step.

The reason we chose JavaScript was twofold: Firstly, we already had React JS, and it made sense to re-use that instead of starting over from scratch; and secondly, JS was the only choice if we wanted a system that worked cross platform and supported instant reload and over-the-air code updates. -Nick

If I'm understanding you correctly, React Native would allow developers to update their apps without any approval for the updated version by the app stores.

Isn't there a significant risk that developers can use the over-the-air updates to put malicious code into the app, which would have caused it to be rejected by app stores had it been present from the start?

This isn't the case. He is referring to the dev cycle of testing your own code in an emulator or on the device. Deploying to a device usually takes a while, it is much faster in react native. It has no effect on "over the air updates."

Actually that's not quite correct. Apple has stated that they are OK with developers deploying OTA (over-the-air) bug fixes and minor updates to apps in the store without resubmitting, provided that:

• The updates don't significantly change the nature of what was originally submitted for review
• The updated code is executed using the Apple-supplied JavaScriptCore VM

We don't currently provide an OTA update mechanism as part of the open source React Native framework, but the necessary hooks are in place, and there are third party OTA code deployment solutions you can use.

As for whether this would theoretically allow developers to deploy malicious updates? Yes, absolutely it would, and if developers choose to do that, Apple will no doubt take those apps of the store and apply whatever sanctions they deem appropriate. -Nick

Facebook has many more great JS developers than native platforms ones. React Native allows for easier switch to native development for people with JS background. - Konstantin

Personally I don't dislike Obj-C or Swift. (I'm an iOS dev so can't comment on Java.) I think React Native is just one of many tools available to native developers, just as Obj-C or Swift are. I definitely think that React Native lowers the learning curve for native development as it leverages technologies already familiar to web developers.

-Alex (a2)

Do you think we will see main facebook apps written in React-Native?

Answered here.

-Alex (a2)

is react native team plan to support windows phone or windows universal app in future?.

We'd certainly like to support more platforms in future, but right now we don't have any concrete plans beyond iOS and Android support. - Nick

We are working on a native bridge that will run on both Android and IOS. Community members expressed interest in supporting Windows and other platforms, that bridge may be useful to them - Konstantin

What kinds of apps do you think React Native isn't a good fit for? Where do you think it excels?

Also: what's the craziest thing you've seen somebody do with react native?

React Native is mostly an abstraction around UIKit (on iOS) and the Android view system. If you wanted to build something like an OpenGL game you would probably find that React Native wasn't a great fit, unless you were willing to take the time to build an OpenGL-based replacement for the React Native UIManager (which, FYI, I know some people have done). -Nick

gl-react-native is so cool!

-Brent

As someone with a lot of web development experience but no game development experience, my understanding of your answer is that RN is not a good fit for 3d games. How about 2d games (for example, a side scrolling platformer?)

I think this can work for 2d games, for example see Floaty Plane (you can try it on Exponent).

-Brent

Are there any plans to expand the react-native platform to desktop app development?

I can't comment on Facebook's future plans, but I did see something on GitHub that seemed promising: https://github.com/ptmt/react-native-desktop

-Alex (a2)

What kind of development tools for ReactNative is your team working on? In your opinion, what kind of development tools would be great for ReactNative developers to have ?

Currently, we just have Chrome for debugging, but I am sure we can do better.

For example, I am working on this - http://taco.tools/vscode/rn.html, and would like to add more features to it. What do you think would be good for development workflow for ReactNative ?

When React Native started, we were only 4 working on it and needed to build the entire platform from scratch so needed to get a good developer environment with very limited resources. By running the js inside of Chrome (which is a pretty awesome hack) we got the Chrome dev tools, running inside of safari we got some performance tooling...

A few months ago, Jared Forsyth reimplement the React dev tools during his internship. Most importantly the inspect feature: it lets developer very quickly figure out what component (and therefore where the code is) for something that is seen on screen.

We're working with the Nuclide team to provide a better integration with it. The big feature is using flow information to give inline error reporting, autocomplete, go to symbol, find references... All the things that you usually see in IDE for Obj-c and Java.

A lot of people are interested in helping (your project sounds awesome) but I think what's missing is a direction. I've been trying to get someone to throw a crazy Brett Victor-like demo of what we could do to inspire people to actually develop the best developer environment in the world!

One thing I'm personally excited about is to integrate with React Hot Loader. I think that it can bring another 10x improvement over the live reload.

-- Vjeux

Can you speak a little to the review process when it comes to deciding what gets merged into RN and what gets bundled into which release? How much of it is community driven vs. Facebook driven?

While an incredible platform, there have been major flaws that, even for an open-sourced project, are surprising to see with such a huge community behind it. For example: a major iOS memory leak persisted across two releases. Android still is missing major features like a WebView even though it has already been built in the form of third-party plugins.

From my perspective the major problem is that React Native originated from the internal source code and we have many dependencies from internal apps to it. Merging a pull request from github means that we need to check that code won't break any internal tests or apps.

Currently there are a few people actively working on eliminating that problem by bringing tests and code quality tools to the open source part of the project. Should be only better. - Konstantin

Very good question!

Even though we've grown a lot in the past year, the team is only around twenty people. This is ridiculously small given the amplitude of the project so we need to make some very hard prioritization decisions on a daily basis.

So far our framework was to prioritize what Facebook needed above all else. The reasoning behind this is that if we can't solve Facebook problems, no matter how much traction it receives externally, Facebook is going to stop throwing money at the project and it will be dead in 6 months.

Now, what has been interesting to see is that the needs of Facebook and the open source community are very well aligned. Most the features we are working internally help open source and things that people want in open source we also need internally.

The big difference between the two is "when". A concrete example is the navigator. We released the hacky versions we used internally which we weren't super proud of but worked. We knew we needed to have a better solution but we had no internal projects that would need it in the next 3-6 months so it didn't make sense to invest in it right now.

The other problem is that we had no idea what the community really wanted. We got more than 10 issues a day a 5 pull requests and couldn't figure out what was important or not.

For that we did two things. The first is to setup Product Pains which let people vote on what the most important issues so that we can prioritize them the same way we priotize feature requests from Facebook product teams.

The second one is to bring in people from the community as part of the core team so that we have community people as stakeholders of the projects that can help drive the direction.

I wish everything was going smoothly and all rosy but we're doing the best we can. The amount of people involved is pretty mind blowing, there's already more than 400 people that contributed to the repo.

-- Vjeux

So far our framework was to prioritize what Facebook needed above all else. The reasoning behind this is that if we can't solve Facebook problems, no matter how much traction it receives externally, Facebook is going to stop throwing money at the project and it will be dead in 6 months.

This is a very realistic fear for us. Should it be?

Also ...

• Are you truly solving "Facebook" problems with RN?
• As an insider, what is your sense of how ReactNative has been received internally by Facebook?
• What other encouragement can you provide that RN will thrive unlike other "do-it-all" native solutions that don't seem to truly take off?

This is a legit fear to have and it is truly your decision to make. If you invest heavily in React Native you will have to bet on Facebook for the forseeable future to make decisions that are favorable for your business, which is not its priority.

Also one big point to mention is that React Native is still super early and there are a ton of things that are missing or buggy. So be prepared to have a bumpy road ahead.

That said, the project is going really well internally. As you see here, Facebook is paying full time a lot of people to work on the project and quickly growing the team.

We have shipped two major apps with it: Groups, Ads Manager that are growing. There are multiple teams internally that are about to ship features with React Native and more that are starting to use it.

The big blockers recently for integrating into the main Facebook apps was startup performance but after starting a React Native Performance team, we got it to a great place where we can ship high quality features.

One of the great thing is that product teams are starting to use it without even telling us, long gone are the days where we had to spend a lot of time convincing people that it was not as crazy as it sounded and fix all the bugs that blocked them from being productive.

This is also not a simple team effort, the company is betting on the project. There's a conference organized around React, both the CTO and VP of engineering talked about React Native during their keynotes at f8 and @scale.

-- Vjeux

After our hackathon when we started React Native, I also started to question the project and try to figure out why it would not follow the faith of all the cross platform attempts.

The big difference to me is that the goal of React Native is not to solve the cross platform problem. Its objective is to be a better developer environment than the way you build iOS and Android apps.

On the product infrastructure team at Facebook we have years of experience building libraries, apis, frameworks to solve real developer and product use cases that the default platforms (whether it is web, ios, android) doesn't solve.

I tend to think that those abstractions are better than what existed before given the huge amount of people successfully using React and our related open source projects outside of Facebook.

At the beginning we had no idea if it would work out, so we spent the first three months taking on the hardest things that we knew: performance, heavy animations/gestures, newsfeed... And try to break it. It turned out to work really well under those hard constraints and continued to prove that it would work after we shipped several successful products with it.

Facebook incentives with the project are very aligned to make a good developer experience. Facebook is already investing a ton of resources building this kind of infrastructure for itself, open sourcing it doesn't costs much more. Unlike startups that have to make a living out of creating such a framework which usually implies that the developers using it need to somehow pay for it.

I can't predict the future but it looks like this crazy experiment is going to work. Even if it won't, it put developer experience and open source on the front stage of mobile development.

-- Vjeux

The general structure for React projects in general is for all styling, scripts, and templates to be encapsulated in a single file for each component. As a developer who migrated from web development to mobile, it seems foreign to keep code with mixed purposes together. To help mitigate this, we've built tools to help us separate "CSS" from "JS," and etc.

What is your argument for the single-file encapsulation that React Native favors? Does it not become difficult to manage in larger projects once templates or controllers grow?

What I found out is that most of the time, the style, markup and logic for a UI component is pretty coupled. You have many references between those three concepts and changing one requires you to change all three files at once. So bundling all three together helps you by having everything in one place.

The way I see people manage their code is that the leaf nodes tend to be pure UI components with very little logic that look like template + style. Then the higher you go in the hierarchy, the more components look like your typical controlers with no style but a lot of logic.

React component model is not perfect in any way, but what we found out over the years is that it's the least-bad way to organize our large apps and keep things from falling over.

-- Vjeux

Style themes are the major counter point to your position.

Theming is a very interesting topic and I don't know any perfect answer. The most commonly used way is to let developers override arbitrary styles. It works but is a nightmare for maintability.

I have seen many ways of doing this kind of things with React Native:

• Have a js module that holds all the color constants which you can swap using some js conditions.
• Stop using <Text> and instead use <ProductText> that listens to some global configuration/context in order to know how to render itself.
• Build high level components like <Card> that have special logic for theming.

-- Vjeux

As a well established iOS dev, I would be way more inclined / interested in contributing to https://github.com/facebook/react-native if it were written in Swift.

Is there any appetite for incorporating / eventually converting from ObjC -> Swift?

We have some limited support for writing React Native modules (plugins) in Swift already. We'd welcome pull requests that make that process simpler or more elegant.

Currently, there are significant disadvantages to use Swift in production apps, notably 1) The API is still unstable, and Apple makes major breaking changes in every release, 2) The Swift runtime doesn't ship with iOS, so it has to be embedded in every Swift application, which significantly bloats the app size.

For these reasons, we aren't using Swift in the Facebook app yet, and consequently we can't use it inside any libraries either (at least, not a non-optional dependency).

With that said, we are of course monitoring the progress of Swift with interest, and with the recent open sourcing, and hopefully stabilisation of the API, we'll be looking to adopt it as soon as it's practical to do so. -Nick

How robust/ready for production applications is RN? A friend tried it out but decided to go with Ionic because RN just didn't seem to be "there" yet, which has kept me from diving in.

We're currently using it for apps in production (Ads manager and Groups app). Things could certainly be better, such as performance, and dev experience but we're actively working on improving those. Could you be more specific about why your friend thinks the framework doesn't seem to be "there" yet? This type of feedback would help us see which direction the community needs us to focus more. - Martin B

"Robust" is a somewhat subjective term, but we're shipping production Facebook apps with it already (e.g. Groups, Ads Manager), and we know of several 3rd party apps in the App store. It's stable, and it has performs well for the use cases we've tried. -Nick

Hey guys! Awesome job so far, I've really enjoyed using React Native. I have a question regarding your deployment cycle though. With 892 issues, 185 pull requests, and a lot of things changing, it's currently difficult to tell what's actively being worked on. I noticed at one point you started using milestones on github, have you considered using those as the project/community grows? Knowing what to expect, even in the next release, is enormously helpful.

For example, I think neovim has done a fantastic job with this: https://github.com/neovim/neovim/milestones

This is a great idea, I'd really like us to publish a roadmap similar to what Relay has done.

Briefly, the core team's main focus is on performance: start up time, responsiveness, memory usage, network usage, scroll performance, etc. We've made a ton of headway on this on both platforms in the last few months and are continuing to push ahead on it.

Other main focuses are on platform parity (we know this is a huge pain point), open source support, internal clients, and developer experience/tools.

-Andy

We will publish plans quite soon - Konstantin

What is a good way to animate the unmounting of a component? I think there is no ReactTransitionGroup which provides a componentWillUnmount method.

Take a look at react-motion - it is intended to solve this exact problem. It's awesome.

-Brent

Oh also, Egghead has a few videos to get started on it, eg: https://egghead.io/lessons/react-react-motion-introduction-to-the-spring-component

And Cheng Lou (who created the library and works on Messenger at Facebook) did an awesome presentation on it at React Europe: https://www.youtube.com/watch?v=1tavDv5hXpo

-Brent

Will there be a React Native Facebook app in 2016? I mean the Facebook app. Thanks!

Not a fully React Native Facebook app, no. It doesn't make sense to reimplement all those years of native development in JS.

But we already have React Native inside the Facebook app (on iOS and Android), and using it for some features. But it's still in the experimental phase for now, we hope to ship some bigger. We hope to get more product teams at FB to use it in the main apps in 2016.

-Felix

As Felix says, it would be impractical to rewrite the whole of the Facebook app in React Native, at least in the short term. But I think it's important to emphasise that one of React Native's strengths is that it seamlessly integrates with existing native code.

We can replace individual features with React Native, or add new ones, without needing to rewrite the entire app. We can even replace individual parts of a native screen with React views, or embed new native features into a screen that was built in React.

This gives us enormous flexibility to pick and choose when and where we use React in our apps, and users should neither have to know nor care whether the screen they are looking at is powered by React or native platform code. -Nick

Hey Nick,

Is there an example for embedding a React Native component into an Objective-C view controller's view. I've done it the other way around and that is easy (see: https://www.youtube.com/watch?v=YV3p09KoYKw) When embedding an RN component into a native view, I am wondering how to make the React Native component work with AutoLayout so that it would position correctly on different screen sizes. Any example out there? Sorry, semi-noob :)

I don't think there's a published example anywhere, but it should "just work". To embed a React Native view inside a native view, create a new RCTRootView and position it the same way you would position any ordinary UIView.

React doesn't control the frame of the RCTRootView itself, it only controls the contents, so you should be able to apply Autolayout constraints to the RCTRootView and it will resize as instructed.

Note that if you have multiple RCTRootViews in your app, you should create the RCTBridge separately, and share the same bridge instance between all of your RCTRootViews. -Nick

Why do you think it isn't there already? - Konstantin

When will React-Native Android to catch up with React-Native iOS for feature parity?

I'm currently working on that. It's a moving target, but I am working through issues as they come up. I currently have a list of at least 50 items that I know of (some very specific, and others broad missing functionality) and I am sure there are more. That said, I think we will have major functionality equivalence over the next few months. You should vote on https://productpains.com/product/react-native/?tab=top for the things that affect you most and help me prioritize the work.

-dave

As soon as the iOS team slow down :-p -Nick

What have been the struggles related to performance? Games aside, are there any common classes of application for which React Native isn't/won't likely be fast enough to feel native?

Certainly - perf is one of our biggest focuses right now. The awesome thing is that we're making very fast progress and RN is getting really competitive with production-optimized native features. Most apps won't have a problem getting the perf they need from RN.

RN is still a bit slower and has some key weaknesses, however, that we are working on fixing. The clearest one can be summarized as "loading indicators" - it's not currently possible to build a nice 60-fps JS-driven loading animation while also doing expensive JS computation, like rendering expensive react components for a new navigation screen - you need to use a native loading indicator component that animates on the main thread. We're working on solving this, though, by driving animations defined with the Animated JS library in native. I'm very excited to see that land. It should help immensely with animated navigation transitions.

We are also tackling some issues around responsiveness. If you try to tap a button right after you start rendering big component (e.g. when a scroll load network response comes in) the button won't respond until the component finishes rendering. We have some ideas around incremental rendering and reconciliation that should help a bunch with this and will hopefully come soon.

-Spencer

So far we haven't had any performance issue that we couldn't get to the bar we wanted with enough efforts.

In order to improve the performance, the biggest issue we faced was the fact that it was hard to profile what was going on. We are investing in a lot of performance tooling in a self-serve way such that if you have a performance issue on your app, you can either fix it yourself if it is in product code or identify and create a repro case if it is inside of the framework and you don't have the knowledge to fix it yourself.

One of the great thing with React Native is that we control the entire stack, so we can fix it wherever the issue is.

Is there an estimate of when we can use Relay out of the box with React Native?

This is a great question! I don't know the ETA but it's on the Relay's team roadmap: https://github.com/facebook/relay/wiki/Roadmap - Martin Konicek

What is up with the Navigator component? I love the functionality, but the screen transitions on both iOS and especially Android are choppy and unacceptable. What is being done to address this?

I'm currently experimenting with several ways how we can improve this. Some of the approaches that we plan to explore are: 1) Offloading animations from JS to native (currently JS drives transition animation which means that we need to call to JS in order to calculate next frame position/opacity etc. - it's quite unfortunate as at the moment of transitioning JS is already very busy with rendering next scene) 2) Use view pooling to speedup the process of building next scene on the native side 3) Implementing requestIdleCallback and moving some of the operations that needs to be done during screen transition to be executed in the callback

-- Krzysztof

The JS navigator component is somewhat experimental. On iOS you can use NavigatorIOS instead, which is a thin wrapper for the native UINavigationController, and should have better performance. - Nick

But Facebook's official position is to not use it, right?

It is not supported by the React Native team, but if you need the performance right now and InteractionManager is not an acceptable middle-ground, then you might have to.

-Brent

Yes, but that doesn't address issues on Android. Then does that mean that a fluid navigation animation isn't possible on Android, or what approach does Facebook take?

This is possible by using the InteractionManager, see this section of the performance docs for details.

Essentially, you render only part of the scene while the transition is occurring, then once it is complete you render the rest.

The work that Krzysztof mentions in the other reply to this would make it so in many cases you would not need to use InteractionManager. The reason why it is necessary is that while the transition occurs, native needs to callback into JS on every frame and get the new animated values for the transition. If the JS thread blocks for a few frames because rendering a new scene is expensive, then the animation will appear 'choppy'. If it's a ListView in the new scene, then each frame that a new row is paged in after initial render could also be expensive and hurt performance.

What Krzysztof is working on would make it so that native would not need to callback into JS on each frame and instead execute the animation on its own, which would mean we can do anything we want in the JS thread during the transition.

--Brent

Performance has regressed over time and someone really just needs to profile it since it has run smoothly in the past. Unfortunately, I don't think that's on anyone's plate right now. We do have some docs on profiling Android performance here: https://facebook.github.io/react-native/docs/android-ui-performance.html#content if you'd like to try to help out. RN is a huge effort and we're a small team and we really depend on the community to also help with the things they're using.

Longer term, we hope to offload these kinds of animations from the JS thread altogether so that they can't be interrupted by JS work.

-Andy

How does your team feel about redux as a way to manage application state without really using, well, this.state?

What does your team find to be the best way to handle application state for a moderately complex application?

We use Relay internally in all fb apps. There's a React Native starter kit that use Redux: https://github.com/bartonhammond/snowflake. I'm not sure how much work you have to do yourself to get a disk cache. - Martin Konicek

In your team's opinion, should React Native be written using ES5 or ES6? Documentation examples seem to vary back and forth, and it isn't clear whether there is a recommendation for one over the other, or if it is just developer preference.

ES2015 and beyond. RN is backed by Babel that transpiles the code into ES5 for the JS engine to run

Are there any plans to rewrite documentation in ES2015?

I'm not aware of any but this would be an epic pull request that I would love to see. Even just changing one section would be welcome :) Or even better - a toggle between ES5/ES2015! It's really up to whoever wants to tackle it.

-Brent

Memory issues abound with the ListView: https://github.com/facebook/react-native/issues/499. Why or why not is this a concern for Facebook?

This is definitely a problem we care about, but it hasn't actually been hurting us much with our current apps so it has been lower-pri. We have some new stuff in the works where this is a much bigger problem, and we're working on a solution. I'm hopefully going to release an experimental "WindowedListView" component soon that you guys can try out and help hack on. -Spencer

This is not a concern for the current use cases we have because we tend to only display a dozen or so elements. Most of the complains about ListView are for hundreds-thousands of elements where it indeed doesn't work.

We are prototyping many different solutions for the more general use case and would love for the community to do as well.

-- Vjeux

How up to date does the embedded React version stays with respect to the main React releases?

Not enough :)

For context, we started the project more than 2 years ago and hard forked React in order to build React Native. Over the years we've done some big refactoring on both sides in order to make both converge. For example react-core is now separate from react-dom.

We're now in a better spot where we update every month or so and the updates are pretty small. We are working hard to stop using our fork such that people can use require('react') and work the same as require('react-native'), this will make it possible for all the third party plugins to work on both places without doing anything.

Right now we can't use relay on the open source version of react-native without forking it, which is a huge shame and we're working on fixing that.

-- Vjeux

relay

so as soon as react-native depends on reactjs, it will be butter to use relay in react-native right?

Yup!

-Brent

We plan to depend on React.js as npm dependency some time later. So it should be updated via npm and have a quicker update cycle - Konstantin

I'm interested in how Facebook runs integration tests with its React Native apps today.

There are some parts of my application that I would want to share between iOS and Android, like the signup flow. I know it's possible to create a React Native view and embed that within an existing native application, but how would I test something like that?

Does Facebook use existing iOS and Android testing tools (like UIAutomation, for instance) to functionally test RN apps? Or is there a separate way of doing integration testing with RN?

At Facebook we have a custom framework for UI testing based on the WebDriver protocol. I talked about the Android part of it here: https://speakerdeck.com/mkonicek/testing-apps-at-facebook-1

We use that framework for testing all fb apps, including the main apps as well as React Native apps, like the Ads Manager. Tests are written in Java on Android and Obj-C on iOS and the team that works on that framework recently built a JS-based solution too.

The UI elements are native elements that the test runner can interact with as usual. Each RN view has a special prop called testID that you can set and then use to find views in tests. We do this when testing React Native apps at fb.

That said, you can use standard tools for UI testing like Espresso on Android or Instruments on iOS. - Martin Konicek

Do you guys have any best practices around handling environment variables?

We've been using react-native-env[1] in conjunction with the multi-env xcode tutorial[2], but it was tricky to get started, and somewhat inconvenient that you can only access the environment variables asyncronously.

[1] https://github.com/joeferraro/react-native-env [2] http://www.blackdogfoundry.com/blog/migrating-ios-app-through-multiple-environments/

For data that needs to be available synchronously on the JS side, and doesn't change during the the lifetime of the app, you can export these as constants using contantsToExport(iOS). -Nick

I've recently read [via a source that I don't have time to look up at the moment] that Facebook is working on native Windows 10 apps. Are these being built with React Native? If so, is the plan to open source the Windows 10 platform implementation?

This is not built with React Native. We don't have any plans to build a Windows backend for React Native right now.

-- Vjeux

I'm not actually aware of the Windows 10 apps. We don't have an implementation of React Native for Windows and don't think we have immediate plans for it. - Martin Konicek

Not on React Native, we don't have a windows engine for that

RN for Windows can certainly be built and it would be cool if the community wanted to own that, but we have no plans internally. -Spencer

What's the best life advice you have received? What advice would you give a junior developer?

I didn't receive this as explicit advice but I'd say try to work closely with the engineers who inspire you the most so you can constantly learn, whether it's within a school, company or open source projects.

What helped me a lot was working hard to get accepted to the Google Summer of Code program during my studies (https://developers.google.com/open-source/gsoc) and later choosing companies based on how good engineers I thought they had. - Martin Konicek

Are there plans to make React Native work out of the box with RelayJS?

Yes, but I'm not aware of any timeline for that yet. -Spencer

Yes. It's a shame that it doesn't. It's probably the top element in our todo-list but it requires to cleanup a lot of our hacks so it's not super easy :(

-- Vjeux

I'm currently using React Native to develop my dissertation project at University. I am developing a system that allows unique apps to be developed, that can then fit into a skeleton app the user downloads initially. Will AppHub or CodePush allow for specific deployments, or are they more for generic app updates?

We're not behind either of those projects so we're probably not the right people to answer this. It sounds like you're trying to build a sort of generic app launcher on top of these, and I don't think they were meant for that.

-Felix

First of all I can't thank you all enough for React Native! We went from zero to publishing our Android app in about a month – for us that would be out of the question if it wasn't for RN.

Now that the app is out there comes the hard part, though, which is maintenance. I have a few questions under this bucket I'd love to hear your take:

• Is ErrorUtils.setGlobalHandler the best way to catch all errors in JS land?

• Is this error handler (or anything else in RN) ever going to handle errors swallowed by promises?

• We're having a hard time reproducing user reported bugs (be it in emulators or the devices we have access). Not stricly related to React Native, but are there any services/frameworks/tooling that you'd recommend here?

Nice, a month is super quick. Looks like Lugg has maps and camera support too? That's really cool! Feel free to send a pull request to add it to the showcase here: https://facebook.github.io/react-native/showcase.html (https://github.com/facebook/react-native/blob/master/website/src/react-native/showcase.js).

I'll let Felix answer the questions related to error handling. - Martin Konicek

Is ErrorUtils.setGlobalHandler the best way to catch all errors in JS land?

Probably yes, since it's what we use in the core. Although note that setting a different global handler will remove RN's one, so the RedBox won't work anymore (and perhaps other things that I can't think of right now).

We're having a hard time reproducing user reported bugs (be it in emulators or the devices we have access). Not stricly related to React Native, but are there any services/frameworks/tooling that you'd recommend here?

Any crash reporting library should do. JS exceptions include the JS stack trace in their detail message, which you'll have to symbolicate manually in order to find the root cause of the error.

Not sure about the promises question.

-Felix

On Promises: we do want to make sure that uncaught promise errors are visible to developers in a programmatic way so you can collect error logs in production.

The technical challenge is determining what constitutes an uncaught error. In the short term we're thinking about checking for promises without error handlers at the end of the event loop. This is the approach that Chrome takes. There's also a big discussion on how Node should treat uncaught promise errors. Once we decide that a promise's error is not going to be handled, we can surface it to developers, potentially through the global error handler as you suggested.

One of the cool things about working on React Native is that we get to share knowledge with other JS infrastructure projects. Another cool thing is that part of React Native's bridge includes implementing the event loop so we can experiment with things like checking for uncaught promise errors at the end of each tick. - James Ide

What do you think about QtQuick/QML? This technology seem to be a direct competition to React Native as it allows to create almost native looking apps on various platforms including Android, IOS, Windows RT as well as desktop platforms. Would you recommend using React Native over QtQuick/QML?

Answered here: https://www.reddit.com/r/IAmA/comments/3wyb3m/we_are_the_team_working_on_react_native_ask_us/cxzw7c5

One of the biggest things that I'm considering using React Native for is to avoid having to go through the App Store / Play Store for review and to A/B test mobile experiences better, by remotely downloading a new version of the app each time.

Is there any work from the React Native team for optimizing a use case like this? From what I hear, most Facebook apps using RN in production don't do this and just bundle up the React Native code in the app itself.

The bundler right now causes the final app size to be pretty big, and includes a lot of library code as well.

I'd like to be able to pin down a version of the core library, and then dynamically update my application code, either for A/B testing or to deploy a new feature. Would that be a feature that the RN team would look into?

We're probably not going to explicitly optimize for this, but we have been accepting pull requests from codepush / apphub AFAIK.

However, I wouldn't recommend not bundling the JS and assets and relying on downloading everything at startup.

-Felix

What is your approach towards the integration of Swift and Objective-C into RN projects going forward? Are developers going to be encouraged to swap between the JS and Native context (with an improved/expanded RN bridge API for example) or do you plan to encourage a more JS/RN centric approach?

The idea with React Native is that you shouldn't need to write any app-specific code in Objective-C or Java. That said, we fully support 3rd party native plugins, and hybrid apps (written partly in native code and partly in JS).

We have some limited support for writing modules and components in Swift, but it's not a high priority for us at the moment, so it's mostly a community-supported feature. It's fairly easy to bridge between Objective-C and Swift code though, so you can use Swift in your app by writing a thin Objective-C module to bridge to RN. -Nick

What is your release cycle?

From what I've observed, it seems like an RC goes out about every 2 weeks?

Do you have a trajectory of what a 1.0.0 release will contain and what's involved to reach that milestone?

That's correct; we aim to ship a significant point release every two weeks, which matches up (more-or-less) with our internal product release cycle.

It's too early to say when or what we can expect for the 1.0 release I'm afraid, but don't be put off by the 0.x version number - we consider RN to be production-ready, and we're taking care to avoid breaking changes to the API unless they are absolutely necessary. -Nick

I just wanted to say thanks to all of you for all you've done. I suppose I have to ask a question, so do you know what react native app has the most users/downloads currently?

It's likely the Facebook Groups App followed by the Ads Manager App for apps that have a huge amount written in React Native. The main Facebook app and Moments have a few features built with React Native with some big traffic as well.

It takes time to build a high quality and successful app and the platform is super recent, so it's not strange that non-fb apps are not yet topping the charts ;)

But, if you look at the apps in the gallery ( http://facebook.github.io/react-native/showcase.html ), they are really high quality and polished. A few got featured by Apple and Product Hunt already.

-- Vjeux

We don't track React Native apps, so there's no way for us to know. I guess you could have a look at the showcase and check which one is the most popular:

https://facebook.github.io/react-native/showcase.html

-Felix

It's a stretch, but... have you considered porting React Native to game engines such as Unity3d or Unreal? Last I checked, game ui was mostly 100% custom or involved very heavy frameworks that injected a full webkit or flash (scaleform) port.

This is something that I personally really want. But, it's unlikely going to come from Facebook, we're not building anything with Unity3d or UnrealEngine so it wouldn't make sense to spend resources doing it.

The least unlikely thing from our side is going to use React for building Oculus apps. But no one is working on it nor are there any plans to.

I hope that someone from the community is going to build that :) I already know several AAA games UIs that are built with React in a transparent webview overlaid on-top of the screen.

-- Vjeux

What's the best way to understand every-single-bit of the 'bridge' ? Is there a parity issue in terms of the bridge implementation for iOS and Android? if so how?

Someone will answer better on the parity question. What I know is that we are experimenting on a single bridge for both platforms written in C++. - Konstantin

The best way is to read the source, experiment, and try to implement modules with it. For example, I implemented requestIdleCallback recently on Android (not merged in upstream, just a proof of concept to see if it would help perf in a certain area) and in order to do that I had to get a good understanding of some aspects of the bridge on that platform that I wasn't too familiar with yet.

The bridge is different on iOS and Android because iOS ships with JavaScript Core whereas on Android we need to embed it with JNI, so there's some more C++ code on Android for this. See here for more details -- in particular OnLoad.cpp is interesting. There are other differences related to the platform and programming languages as well, but overall the general idea between the two platforms is very close.

Feel free to ping me with questions you have about the bridge, I love those kinds of questions because I always learn more.

-Brent

Tadeu wrote a fantastic in-depth article about the bridge implementation on iOS. Not sure if there's anything equivalent for Android yet: http://tadeuzagallo.com/blog/react-native-bridge/ -Nick

Is there an intention to expand React Native to support iPad and Apple Watch?

There are two limitations currently preventing React Native from running on the Apple Watch. One is that the JavaScriptCore framework is unavailable on the watchOS platform. The other is that all UI must be precompiled from storyboards. This prevents the UI from being dynamically created at runtime, which is what React Native does currently.

-Alex (a2)

It should work there already

To clarify, it should work on iPad already but you will still have to write natively for Apple Watch. There aren't any plans to support it yet, but it's possible that someone in the community might step up similar to react-native-desktop that enables you to use React Native for OSX.

-Brent

Hi, first of all thanks for your hard work! Building apps in RN has been a fantastic experience so far. Your release cycle has been very frequent; I was wondering how long you guys think you'll continue at this pace?

I'm glad it's been working well for you! We'd like to continue releasing every two weeks.

If you want to know more about how the releases work, I did a talk about this. See slides 45+ here: https://speakerdeck.com/mkonicek/under-the-hood-of-react-native - Martin Konicek

When we open sourced, we struggled to figure out when to release so we decided to sync the open source release process with Facebook release process.

For the team it was great because open source was completely transparent: whatever goes into prod to a ton of users also go to open source.

For contributors it's also great because when we merge a pull request, they know exactly when it's going to be released.

Now, for the developers this is indeed not optimal, 2 weeks is really short. We'll probably change it in the future to have more stable versions in a longer time frame. I like Ember release model very much in this regard.

No concrete plans yet but we know it's a concern.

-- Vjeux

Are there any challenges unique to dogfooding a project such as yours? Are the internal versions of your project significantly further ahead than the public branch? If so, is there any benefit to closing that gap or is it better to be able to internally experiment and explore different avenues before setting a public trajectory for the architecture.

Are the internal versions of your project significantly further ahead than the public branch?

At the core, no. We just have a bunch of extra modules & views, and app-specific JS infrastructure.

If so, is there any benefit to closing that gap

Definitely, one of our top priorities is open sourcing more of the generic modules / views that we have internally. So far open sourcing has seen huge benefits as we get bug reports and fixes from the community, so I don't think that will stop anytime soon.

We do try to make sure the stuff that we open source is stable (in terms of bugs and API) and consistent (API) and makes sense for open source. This is why sometimes it takes longer to release some things.

-Felix

There are no internal version of React Native further ahead than the public branch. We use both scripts and bots to keep in sync github repo's master with our internal repo's master. On the past we used to have a 2 weeks release cycle which was a bit painful as many things used to break when synching. Incrementally automatically synching has been working great for us. - Martin B

What is your recommendation for contributing with support for new native components? Submitting a PR to the core repository or building stand alone modules for people to plug in?

I think the best approach is to build stand alone modules and if they become very popular and polished then there can be a discussion about whether or not it should become part of core. This has a huge benefit of making it easier for you to iterate on the component without tying it to the release cycle and burdening the team with reviewing more PRs.

-Brent

Separate modules are preferred to keep the core lean and keep you moving fast! -Spencer

Hi, Can you please advise how testID is used for "end to end" testing? Does RN support "accessibilityIdentifier" that is used in UIAutomation scripts?

Hi, testID maps to accessibilityIdentifier on iOS and is set as a view tag on android

-Krzysztof

We use testID to look up Views by tag on Android using Selendroid. On iOS, this maps to accessibilityIdentifier for UIAutomation.

-Andy

Is it possible to execute JavaScript (Without UI/React) and return that to some platform code. For example inside a background service?

Platform code --> JS --> Platform code

rather than:

JS --> Platform code --> JS

React native operates on top of the native (java/Objc) to JS bridge with a concept of "native" and JS modules (modules can have methods that you may call from the "other" side of the bridge). All the UI stuff is built on top of the bridge (the main "native" module that handles generating views is called "UIManager"). It is possible to use bridge directly the only restriction is that the communication has to be asynchronous

-- Krzysztof

Yes, this is possible, though we don't have any recommended patterns for it yet. Platform -> JS code is actually how the app starts in the first place, JS -> Platform would be done via a standard native module call. This is an example of a module that implements this, but for UI: https://github.com/facebook/react-native/blob/2944c665bfd030ecbdb624d67b67f3ccd2a85623/ReactAndroid/src/main/java/com/facebook/react/uimanager/debug/DebugComponentOwnershipModule.java

-Andy

On iOS you can use RCTEventDispatcher to send arbitrary events that can be observed on the JS side. You can even use some trickery to implement synchronous callbacks this way (see the onShouldLoadStartLoadWithRequest event on RCTWebView for example). -Nick

Does React Native have any plans to support RCTWebSocketExecutor in release mode and enable the possibility of running JavaScript from remote?

Not currently. It's difficult to imagine a situation where that would provide a better user experience than downloading code in advance and running it locally.

But RCTWebSocketExecutor is open source, so there's nothing stopping you from forking it and shipping an app that uses your forked executor - it shouldn't be necessary to make any modifications to React Native itself to support that. -Nick

Do you have a recommendation for the best flux library to use with react-native, or do you have any plans to integrate a flux library with RN?

Redux!

-Brent

How do you compare react-native with native-script ?

They have fundamentally different goals.

NativeScript just provides JS bindings to native code, allowing you to write ordinary imperative-style apps using JavaScript. It gives you some of the advantages of React Native (such as live reload and OTA updates), but it doesn't provide any sort of x-platform abstraction for building UI.

React Native is much more about enabling you to use the declarative, component-based app development model provided by React JS, and providing a common abstraction between iOS and Android so that you can share code. -Nick

Why would I choose React Native over Qt? Also, can you write custom components for react native (say... some crazy clock widget), such as you would for html/js, or is this just a nice compatibility wrapper, exposing a react-like interface?

Qt FTW! Sure you can.

react Native and Qt are very different. Qt is a cross-platform widget library, built on a static, compiled language. Consequently, it has the following disadvantages compared to React Native:

• Qt widgets do not look and feel like native controls
• You can't edit code and refresh the app with recompiling
• You can't deploy over-the-air updates without going through app review

React Native apps look exactly like other native apps because we use the real native controls supplied by the platform. The use of JavaScript supports rapid development and prototyping, and is the only Apple-sanctioned way to support over-the-air code updates for iOS apps.

As for custom components, we expose the exact same native interfaces for building custom components that we use for the built-in React Native widgets. You can easily wrap native controls as plugins for use with React, or create custom components in pure JS by composing and customising the ones we supply out of the box. -Nick

Yes, that applies to Qt. What about QML/QtQuick?

I'm not familiar with QML/QtQuick. I assumed that QtQuick was based on Qt and has similar limitations, but if that's not the case then you can disregard my answer. -Nick

Is there a recommended way of wiring up analytics for RN apps? Since all the SDKs are in native code, it seems like a big obstacle, and no reliable community packages have come forward (including Google Analytics).

You could always create a native module that exports the native functions you need to JS. I'm not sure what benefits you'd have if the libraries were written in JS other than easier integration. Ideally the library would be written in c++ so that the same implementation could be used across different platforms and languages. That's the direction we're taking internally for some core libraries.

-Martin B

Other products which compete with yours (such as Titanium) have typically struggled with app-size (ie: the smallest install android .apk is still 10MB+ with V8, 3MB with Rhino) as they package Rhino or whatever runtime with every install, do you guys have any plans to work around that problem? I haven't used React in ages, but I remember an incredibly basic android app being similar when I did a comparison (I assume for the same reason). Is there any way to close the gap with the size of native apps?

Obviously worse power consumption/performance compared to native is also a factor for the same reason, again, how are ye planning to (or how have ye managed to) try and close this?

A very basic RN Android is <5MB. The native code for JSC (our JS executor) is <2MB. (Ads Manager is at ~7.3MB right now with images, etc.)

Obviously terrible power consumption compared to native is also a factor for the same reason, again, how are ye planning to (or how have ye managed to) try and close this?

Can you elaborate on this? Historically, poor power perf of apps on Android is caused by holding WakeLocks, waking up to poll location/network and activating radios, etc. We haven't seen/had reported any power consumption issues in our production RN apps.

-Andy

What are your thoughts on the PATENTS issue? As it stands, the way the clause is written into the license, many people don't feel comfortable investing any hours of development integrating stuff with react.

See https://github.com/facebook/react-native/blob/master/PATENTS. https://news.ycombinator.com/item?id=9271331. https://github.com/facebook/react/issues/3617

Lot of FUD. See this post which is more recent than that hackernews post: https://code.facebook.com/posts/1639473982937255/updating-our-open-source-patent-grant/

If the lawyers at companies like Netflix, AirBnB, Uber, etc are satisfied then it works for me.

-Brent (not a Facebook employee)

Hey guys, first of all, GOOD JOB!
My question is about the status between Android and iOS. I know Android support was added recently. What are the main "issues" or features in Android that are not supported or working in Android as good as iOS? Animations maybe?

Getting same features on both platforms is totally our priority. You can vote here: https://productpains.com/product/react-native/?tab=top

How can we help speed up the process for android?

We are migrating internal code (webview, camera, dialogs to name a few) to open source and configuring CI to run lints, unit and e2e tests on all Pull Requests.

The burndown of closed issues and Pull Requests is increasing thanks to community members.

The main effort is to bring everything useful to the community and allow members to contribute faster.

Best thing you can do is to vote on https://productpains.com/product/react-native/?tab=top and submit small PR. - Konstantin

What will be the team's priorities in the upcoming year? On a related note, on GitHub I see 898 issues and 184 open pull requests right now. Are you prioritizing bringing those numbers down?

Triaging issues and pull requests takes precious engineering time away from us, and really the amount that we get has been overwhelming. But we have some initiatives here, e.g. giving certain people in the community collaborator status so that they can close issues and merge pull requests. This has been super helpful so far, but we only started doing it very recently.

We also have a bunch of bots that make things easier. For example the CC bot that @mentions people on PRs according to the blame of the changed files.

-Felix

As for priorities, you can see them here and vote:

https://productpains.com/product/react-native/?tab=top

Can't talk about internal priorities though. But we do have two people dedicated to open-source.

-Felix

is there any thought on creating custom/individual threads for components?

Do you mean JS threads (web workers), or native threads? -Nick

On iOS each native module has its own GCD queue. As for React Components... ¯_(ツ)_/¯ Not sure what that would look like. Can you elaborate?

-Brent

Any chance part of this project entails creation of a wholly custom, unique, and thorough end-to-end tutorial for absolute beginners (with the aim of shaping them into... not absolute beginners)?

Think something like TinkerLearn, Udacity, edX, Codecademy, etc. - but with the weight of you all behind it, intended to truly broaden the audience (by developing new members).

I'm learning Python and perl for work, which belies a selfish motivation: I want to learn it for personal reasons too! So why not get paid for it? I was purposeful in my search - and I got lucky, heh. So it would be cool to see a resource tailor-made for this project, too.

Documentation and tutorials need improvement and we'll be working on that.
But I would expect something way better than what we can do to be done by the motivated people from outside of React Native team.
- Konstantin

Thanks to all of you for all you've done. Q: To know specific behaviour for specific versions (something like an API level in Android Docs), Is it possible to have the docs website have a behaviour history/docs history (affected components/deprecated api/new api/supported api) depending on react-native version?

This is a great idea. We just haven't gotten around to doing it yet. Pull requests for doc updates are always welcome. There are release notes for each release which contain much of that information though.

-dave

This is something we've had an open issue about for a while but nobody on the team has got around to it. Contributions are welcome! That said, if you want to run the website locally with any version you like checked out, just clone the repo, check out the version tag you're using, cd into website, npm install, then node server/server.js

-Brent

Sounds like a great idea for the community to implement. Currently we have a script that generates most of the docs from the code. - Konstantin

besides returning false or null in the render function, is there anyway to disable or defer the rendering of a view?

shouldComponentUpdate: function(nextProps, nextState) ?

brunobar79 has the right answer

-Brent

Can you share any RN apps your built for personal projects that you're particularly excited about?

I can't speak for everyone, but we have a crazy number of internal projects to keep up with that are a ton of fun so I haven't had any chance for personal projects yet. - Spencer

First of all this is awesome. Thanks guys. Q: Is there a best practice on how to handle production error and how to get notified when the application crash in production for our customers?

Errors in production will crash the app with an exception, so using any third party service such as crashlytics should do the job. There will be some manual steps needed to symbolicate the JS stack trace, though.

-Felix

What is your thoughts on babel 6 so far? Structurally it makes sense, but the effect is has on the package ecosystem is devastating.

https://github.com/facebook/react-native/issues/4062

Indeed this has been a pain for many developers, in particular at Exponent the lack of support for decorators made it difficult to keep up to date with master for a while. The upside is that it made us look into jscodeshift (check out this talk from cpojer) which is an incredible tool for making big changes to your code in a much more intelligent way than search/replace with regexp. Check out AstExplorer also :)

Sorry that doesn't really answer your question, hopefully someone else will chime in with their thoughts!

-Brent

How do you like the awesome Exponent (https://exponentjs.com) ?

I agree, it is awesome.

-Brent (works at Exponent)

I'm currently in my final year at university and writing an iOS application using React Native. We have to fulfil a wide range of references including books - are there any official books released about RN?

There are a couple of React Native books out there, but AFAIK no one on the team has been involved in writing them.

-Felix